概要
S3バケットでホストされた静的ウェブサイトをCloudFront経由で配信する際、セキュリティ上の理由から、CloudFront経由でのみアクセスを許可し、S3のURLを使用した直接アクセスをブロックする必要があります。
本記事では、Origin Access Control (OAC) を使用してこの要件を実現する方法を、実際の設定手順と挙動確認を通じて解説します。
CloudFrontからのみアクセスを制限する理由
セキュリティの強化
S3バケットのURLを直接公開すると、以下のようなリスクが発生します。
- 直接アクセスの可能性: ユーザーがS3のURLを直接知ることで、CloudFrontのキャッシュやセキュリティ機能をバイパスしてアクセスできる
- コスト管理の困難: CloudFront経由のアクセスと直接アクセスを区別できないため、コスト分析が困難になる
- アクセス制御の不備: CloudFrontで設定したアクセス制限(例:署名付きURL、地理的制限)が無効化される可能性がある
コスト最適化
CloudFront経由でアクセスすることで、以下のメリットがあります。
- キャッシュによる高速化: CloudFrontのエッジロケーションからコンテンツを配信することで、レイテンシーを削減
- 転送コストの削減: CloudFront経由の方がS3への直接アクセスよりも転送コストが安い場合がある
- アクセスログの一元管理: CloudFrontのアクセスログで一元管理できる
Origin Access Control (OAC) とは
OACの概要
Origin Access Control (OAC) は、CloudFrontがS3バケットにアクセスする際に使用する新しいアクセス制御方式です。OACを使用することで、CloudFront経由でのみS3バケットにアクセスできるように制限できます。
OACは、OAI(Origin Access Identity)の後継として2022年8月に導入され、現在推奨されている方式です。OACの主な特徴は以下の通りです。
- 全リージョン対応: すべてのAWSリージョンで利用可能
- SSE-KMSのサポート: KMSによる暗号化されたS3オブジェクトへのアクセスが可能
- 動的リクエストのサポート: GET、HEADだけでなく、PUT、DELETE、PATCHなどのHTTPメソッドにも対応
- バケットポリシーでの制御: サービスプリンシパルとSourceArn条件を使用してアクセスを制御
OACとOAIの違い
OACは、OAIの後継として開発されました。OAIはレガシー方式として残っていますが、新規構築ではOACの使用が推奨されています。
| 項目 | Origin Access Identity (OAI) | Origin Access Control (OAC) |
|---|---|---|
| 対応リージョン | 2022年12月以前のリージョンのみ | 全リージョン対応 |
| SSE-KMSのサポート | 非対応 | 対応 |
| 対応するHTTPメソッド | GET、HEADのみ | GET、HEAD、PUT、DELETE、PATCHなど |
| バケットポリシーのPrincipal | OAIのARN | サービスプリンシパル(cloudfront.amazonaws.com) |
| バケットポリシーの条件 | なし | SourceArn条件でディストリビューションを特定 |
| 推奨 | レガシー方式(非推奨) | 新しい方式(推奨) |
OACの設定手順
前提条件
- S3バケットが作成済み
- 静的サイト用のHTMLファイル(例:
index.html)がS3バケットに配置済み

S3バケットのプロパティに、静的Webサイトホスティングというあたかも使いそうな設定がありますが使いません。

パブリックアクセスももちろんブロックします。

CloudFrontのオリジンに直接アクセスさせないための方法を問われるような問題でこの設定が有効になっていたら選択肢から除外できるものと考えても良いでしょう。
CloudFrontディストリビューションの作成
CloudFrontコンソールからディストリビューションを作成します。

CloudFrontは一部機能に制限のある定額と、細かい調整が可能な従量課金のプランがあります。 今回は特に要件はないのでFreeを利用します。

ディストリビューションの名前を指定します。

OriginTypeでAmazonS3を選択し、Originで先ほど作成したバケットを選択します。

キャッシュやオリジンの設定は全て推奨のものを選択します。
これによって、指定しているオリジン(S3バケット)に適切なバケットポリシーが設定されます。
カスタマイズも可能で、ヘッダーの追加やキャッシュポリシーの設定を行うことができます。

WAFの設定では、BusinessPlan以上でアプリケーション層のDDoS保護が有効にできます。
monitor modeをオンにしておくと、ルールに一致するアクセスをアクセスをブロックせずにカウントだけ行います。 そうすることによって本番運用前にリクエストの影響を確認できます。今回はOFFにしています。

こちらの内容で作成します。

作成後の画面はこちら。

ディストリビューションの作成には数分かかります。
最終更新日のステータスがデプロイから日付に変われば準備完了です。
ディストリビューションドメイン名の値にアクセスすると、S3に配置したhtmlを参照できます。

S3バケットポリシーと直アクセスの確認
ディストリビューションの作成後にバケットポリシーが更新されています。

ポリシードキュメントの通り、CloudFrontで作成したディストリビューションからのGetObjectに限り許可する設定がディストリビューション作成時に付与されます。
この状態で、直接index.htmlのURLにアクセスすると想定通りブロックされていることが確認できます。

まとめ
S3バケットでホストされた静的ウェブサイトをCloudFront経由で配信する際、2026年時点ではOrigin Access Control (OAC) が推奨されています。
試験では必要な設定を回答させるといったパターンをよく見かけるため、一連の流れを頭に入れておきましょう。


