あるメディア企業がAPI GatewayのREST APIを使って動画メタデータのCRUD APIを公開している。フロントエンドはCloudFrontを介して別ドメイン（cdn.example.com）から配信されており、ブラウザがAPI（api.example.com）に直接フェッチを行う。本番環境でブラウザのデベロッパーツールに「No 'Access-Control-Allow-Origin' header is present」エラーが表示されている。最小限の設定変更でこのCORSエラーを解消するための対応として最も適切なものはどれか。
- A. API GatewayとフロントエンドのドメインをRoute 53で同一ホストゾーンに統合してCORSを回避する
- B. Lambda統合のレスポンスにAccess-Control-Allow-Originヘッダーを手動で追加するコードを記述する
- C. API GatewayコンソールでCORSを有効化し、Access-Control-Allow-Originヘッダーにフロントエンドのオリジンを設定する
- D. CloudFrontディストリビューションのオリジンアクセスコントロール（OAC）を設定してAPI Gatewayへのアクセスを許可する
解答と解説を見る
正解: C
CORSエラーはブラウザが異なるオリジン（ドメイン）へのリクエスト時にOPTIONSプリフライトリクエストを送り、サーバーがAccess-Control-Allow-Originヘッダーを返さない場合に発生する。API GatewayにはCORSを有効化するビルトイン機能があり、コンソールから許可オリジン・メソッド・ヘッダーを設定するだけでOPTIONSリクエストへの応答とCORSレスポンスヘッダーの付与を自動化できる。これが最小の設定変更で対処できる方法である。選択肢DのOACはS3やプライベートオリジンへのCloudFrontアクセス制御に使うものであり、CORSの問題解決とは無関係である。選択肢BのLambdaコードへのヘッダー追加は機能するが、プロキシ統合の場合はGETなどのシンプルリクエストには対応できても、OPTIONSプリフライトの処理をAPI Gateway側で別途設定する必要があり、コード変更を伴うため「最小限の変更」とは言えない。選択肢AのRoute 53統合はDNS設定であり、ブラウザはドメイン名ではなくオリジン（スキーム+ホスト+ポート）でCORSを判定するため、問題の根本解決にならない。
📚 関連サービスの解説: Amazon API Gateway