SAA-001
あるWebアプリケーションがAmazon S3に保存された静的ファイルをCloudFront経由で配信しています。S3バケットを直接公開せず、CloudFrontからのアクセスだけを許可したい場合、最も適した構成はどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：C. CloudFront Origin Access Controlを使い、S3バケットポリシーでCloudFront DistributionからのGetObjectのみ許可する
解説
S3を直接公開せずCloudFront経由に限定するには、CloudFront Origin Access Controlを使用し、S3バケットポリシーで特定のCloudFront Distributionからのアクセスだけを許可する構成が適しています。
選択肢ごとの解説
A. S3バケットのBlock Public Accessを無効化し、バケットポリシーで全ユーザーにGetObjectを許可する
バケットを公開するため、S3直接公開を避ける要件に反します。
B. S3オブジェクトごとにパブリック読み取りACLを設定する
オブジェクトACLで公開する方式は、最小公開の設計に反します。
C. CloudFront Origin Access Controlを使い、S3バケットポリシーでCloudFront DistributionからのGetObjectのみ許可する
正解です。OACによりS3を非公開のままCloudFront経由で安全に配信できます。
D. S3静的Webサイトホスティングを有効化し、CloudFrontのオリジンにWebサイトエンドポイントを設定する
S3静的WebサイトエンドポイントはOACと組み合わせられず、バケット公開が必要になりやすいです。
実務での使いどころ
CloudFront Origin Access Control（OAC）は、S3 バケットを公開せずに CloudFront 経由でのみ配信を許可するための仕組みである。S3 バケットの Block Public Access を有効のまま保ち、バケットポリシーで「特定の CloudFront Distribution からの GetObject だけを許可する」記述を行うことで、S3 直接アクセスを構造的に遮断できる。署名付き URL や署名付き Cookie と組み合わせれば、CloudFront 層で更にアクセス制御を重ねることもできる。OAC は旧来の Origin Access Identity（OAI）の後継として位置付けられており、新規構築では OAC が推奨される。 設計上の注意点として、S3 静的 Web サイトホスティングのエンドポイントは OAC と組み合わせられない点がある。Web サイトエンドポイントは HTTP 公開を前提としているため、OAC で守る要件がある場合は REST API エンドポイント（バケット FQDN）をオリジンに指定する必要がある。また、CloudFront の Behaviors で Viewer Protocol Policy を Redirect HTTP to HTTPS にし、ACM 証明書（us-east-1 で発行）を紐付けて HTTPS 配信を強制するのが標準構成となる。 SAA-C03 では「S3 を非公開のまま CloudFront 経由で配信したい」「最小公開の原則を守りたい」という文脈で OAC が正解として頻出する。誤答は Block Public Access の無効化、オブジェクト ACL の公開設定、S3 Web サイトエンドポイント利用など、バケットを公開してしまう方向の選択肢が並ぶ。OAI と OAC の違い（OAC はより新しく、SSE-KMS や SigV4 リージョン署名にも対応）も問われやすい。