S3とCloudFrontを使った静的サイトでCloudFrontからのみアクセスする方法

目次

概要

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など
バケットポリシーのPrincipalOAIのARNサービスプリンシパル(cloudfront.amazonaws.com)
バケットポリシーの条件なしSourceArn条件でディストリビューションを特定
推奨レガシー方式(非推奨)新しい方式(推奨)

OACの設定手順

前提条件

  • S3バケットが作成済み
  • 静的サイト用のHTMLファイル(例:index.html)がS3バケットに配置済み

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

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

CloudFrontのオリジンに直接アクセスさせないための方法を問われるような問題でこの設定が有効になっていたら選択肢から除外できるものと考えても良いでしょう。

CloudFrontディストリビューションの作成

CloudFrontコンソールからディストリビューションを作成します。

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

注意

ディストリビューションの削除は定額プランに加入している状態では削除することができません(無効にすることは可能)。ここで選択する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) が推奨されています。

試験では必要な設定を回答させるといったパターンをよく見かけるため、一連の流れを頭に入れておきましょう。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

株式会社Luxy(https://luxy-inc.com)の代表取締役.

2018年〜インフラエンジニアとしてキャリアをスタートし、オンプレミスのネットワーク・サーバ環境で3年半、クラウド環境で4年半の8年間エンジニアとして従事。
2021年に佐藤氏の創業した会社を引き継ぎ、代表に就任。

目次