SAA対策
S3とCloudFront OACで安全に静的サイトを配信する設計
S3を直接公開せずCloudFront OAC経由で配信する構成を、SAAとポートフォリオ観点で解説します。
静的サイトをAWSで公開するなら、S3 + CloudFrontは基本構成です。ただし、S3バケットを直接公開する設計は避けます。
結論
S3は非公開にし、CloudFront OACを使ってCloudFrontからのみS3オブジェクトを取得できるようにします。ユーザーはCloudFront経由でHTTPSアクセスします。
なぜS3を直接公開しないのか
S3バケットをパブリック公開すると、意図しないファイル公開やアクセス制御ミスにつながります。静的サイトの配信であっても、S3を直接公開するのではなくCloudFrontを入口にする方が安全です。S3側ではBlock Public Accessを有効にし、公開アクセスを許容する設定を作らないことが出発点です。Amazon S3 Block Public Accessの動作も確認しておきましょう。
OACとは
OACはOrigin Access Controlの略です。CloudFrontがS3オリジンにアクセスするための仕組みです。CloudFrontはS3へのリクエストに署名し、S3バケットポリシーではCloudFrontサービスプリンシパルと対象Distributionに限定したアクセスを許可します。利用者がS3のURLへ直接アクセスしても、バケットを公開していなければオブジェクトを取得できません。CloudFrontでOACを使用してS3オリジンへのアクセスを制限する方法は、ポリシーの条件を確認する際の正本です。
構成の流れ
- ユーザーが独自ドメインまたはCloudFrontドメインへアクセスする
- CloudFrontがリクエストを受ける
- キャッシュがあればCloudFrontから返す
- キャッシュがなければCloudFrontがS3から取得する
- S3はCloudFrontからのアクセスだけ許可する
この境界により、配信、TLS終端、キャッシュはCloudFrontで扱い、オブジェクト保存とCloudFrontからの限定アクセスはS3で扱えます。CloudFrontの設定だけでなく、S3バケットポリシーとBlock Public Accessの両方が意図どおりかを確認します。
HTTPSと独自ドメインを含む配信設計
本番の公開サイトでは、独自ドメインをCloudFront Distributionへ向け、CloudFrontでHTTPSを必須にする構成が一般的です。証明書、DNS、CloudFrontの代替ドメイン名は同じ配信経路の設定として確認します。ここで重要なのは、HTTPからHTTPSへの誘導や正規のドメインを一貫させることであり、S3を公開する理由にはなりません。
キャッシュ更新はデプロイ手順に組み込む
CloudFrontはキャッシュを返すため、S3へ新しいファイルを配置した直後に、すべての利用者がすぐ新しい内容を見るとは限りません。ファイル名を変更して配信する方法と、必要なパスにInvalidationを実行する方法を、デプロイ手順として選択します。
Invalidationの対象範囲や頻度は、配信するファイル構成と更新頻度に合わせて決めます。無条件に広いパスを無効化するのではなく、キャッシュ戦略と運用コストを両方確認します。現在の制限や料金は変更される可能性があるため、導入・運用時点で公式情報を確認してください。
OAC、OAI、パブリックバケットの違い
新しいCloudFront + S3の設計では、OACを用いてCloudFrontからの署名付きアクセスに絞る構成を検討します。過去の構成で使われるOAIと混同せず、既存環境の方式を確認して移行可否を判断します。
一方、S3バケットをパブリックにしてCloudFrontから読む構成では、CloudFront以外の経路も許してしまいます。キャッシュ配信のためにCloudFrontを入れるだけでは、オリジンの公開範囲は狭まりません。OACとバケットポリシーまで設定して初めて、配信経路をCloudFrontへ限定できます。
バケットポリシーで守る境界
OACを作成するだけでは、S3バケットへのアクセス許可は変わりません。バケットポリシーでCloudFrontサービスプリンシパルを許可し、その許可を対象のDistributionに絞る必要があります。逆に、広いPrincipalに読み取りを許可する文が残っていれば、OACを設定していてもオリジンを直接読める可能性があります。
確認時は「CloudFrontからは取得できるか」と「CloudFrontを経由しないリクエストは拒否されるか」の両方を見ます。前者だけでは公開境界の検証になりません。S3にはアプリケーションのビルド成果物以外を置かない、デプロイ用の権限と閲覧用の権限を分ける、といった運用もバケットポリシーの設計を単純にします。
Block Public Accessは、誤って公開ポリシーやACLを設定する経路を抑えるための保護です。OACの許可はCloudFrontからの限定アクセスとして設計し、パブリック許可を例外として追加しない形にします。アクセス拒否が起きたときにBlock Public Accessを先に無効化するのではなく、Distribution、OAC、バケットポリシーの条件が対応しているかを調査します。
オリジンとビューアーの責務を分ける
CloudFrontには利用者からのリクエストを受けるビューアー側と、S3オリジンからコンテンツを取得する側があります。HTTPSへのリダイレクト、独自ドメイン、キャッシュキー、レスポンスヘッダーのような公開配信の設定はCloudFront側で扱います。S3はオブジェクトの保存先であり、CloudFrontからの取得だけを許可する役割に絞ります。
この分離を理解すると、S3の静的ウェブサイトエンドポイントを公開オリジンとして使う場合と、非公開のS3バケットをRESTエンドポイントとしてCloudFrontへ接続する場合の違いも整理できます。OACによるアクセス制限を要件に含む設問では、CloudFrontからS3へ署名付きで取得できる経路を選びます。単にS3でHTMLを返せるというだけでは、オリジンを非公開にする要件を満たしません。
デプロイ後に確認すること
デプロイはファイルをS3へ配置して終わりではありません。CloudFront経由で新しいページ、CSS、JavaScriptが期待どおりに取得できるかを確認します。新しいビルドでは内容が変わる一方でファイル名が同じ場合、キャッシュが残って古い画面と新しい画面が混在することがあります。変更内容に応じてキャッシュ無効化の対象を決め、実施履歴を残します。
HTMLのように更新を早く反映したいファイルと、ハッシュ付きの静的アセットのように長くキャッシュしたいファイルでは、適したキャッシュ方針が異なります。全ファイルを毎回無効化する運用は理解しやすいものの、更新頻度や配信規模によっては不要な操作になります。フレームワークの出力形式とデプロイ方式を確認し、必要な経路だけを更新する設計にします。
また、403や404のようなエラーが出たときは、まずCloudFrontのオリジン設定、OACの関連付け、バケットポリシー、オブジェクトキーを順に確認します。S3をパブリックにして一時的に表示だけ通す対応は、問題の原因を隠し、公開範囲を広げるため避けます。
SAAの設問で選ぶ構成
問題文に「静的コンテンツを低レイテンシーで配信」「S3オリジンを直接公開しない」「HTTPSで独自ドメインを使う」とあれば、CloudFrontを入口にし、S3の公開アクセスを遮断したうえでOACを使う構成が有力です。アクセスをCloudFrontに限定する条件では、OACと対象Distributionを条件にしたバケットポリシーまで含めて選びます。
一方、「オブジェクトを一時的に特定の利用者へ渡す」ことが主目的なら、署名付きURLや署名付きCookieなど別のアクセス制御を比較する必要があります。CloudFrontとS3を組み合わせる設問でも、キャッシュ、オリジン保護、個別利用者の認可は別の要件です。問題文のどの経路を守るべきかを読み分けます。
CloudFront入門ではCDNのキャッシュやエッジ配信の基本を学びます。このページでは、その前提の上で、S3を非公開に保ちながらCloudFrontへだけ取得を許可する設計判断を扱います。役割を分けて読むと、試験でも実装でも構成の選択理由を説明しやすくなります。
変更管理で避けたいこと
バケットポリシーやCloudFrontの設定は、画面表示だけを確認すると見落としがちです。設定変更前後で、公開アクセスが許可されていないこと、意図したDistributionだけがオリジンを取得できること、HTTPSの配信経路が維持されていることを確認します。設定を手作業で変更する場合も、変更内容とロールバック手順を残しておくと、障害時に安全な状態へ戻しやすくなります。
開発環境で表示を急ぐためにS3を一時公開し、その設定を本番へ持ち込むことは避けます。検証用の環境を分け、同じく非公開オリジンとCloudFront経由で確認する方が、本番との差分を減らせます。最小権限と配信経路の限定は、公開後に後付けするのではなく、デプロイ設計の条件として扱います。
設計レビューの確認項目
レビューでは、CloudFrontのオリジンが意図したS3バケットを向いているか、OACがそのオリジンに関連付いているか、バケットポリシーの許可条件が対象Distributionに限定されているかを確認します。加えて、Block Public Accessが公開要件のないバケットで有効か、不要なオブジェクトやデプロイ用の情報を配信対象に置いていないかも確認します。
これらを項目化すると、担当者が変わっても「表示できるので問題ない」という確認で終わりません。利用者の入口、CloudFrontからオリジンへの経路、S3の公開境界という順に確認し、各層で許可範囲が広がっていないことを検証します。
SAAで問われるポイント
- S3静的サイト配信では、S3の公開範囲とCloudFrontの配信経路を分けて考える
- S3は直接公開せず、OACとバケットポリシーでCloudFrontからのアクセスに限定する
- CloudFrontでHTTPS配信とキャッシュを扱う
- 独自ドメインではACM証明書をCloudFrontに紐づける
- キャッシュ更新では、ファイル名設計またはInvalidationを運用手順に組み込む
よくある設計ミスと注意点
- S3バケットを公開したまま、CloudFrontを経由すれば安全だと考える。
- OACだけを作成し、S3バケットポリシーで対象Distributionを許可していない。
- Block Public Accessを解除して、意図しない公開を許容する。
- デプロイ後のキャッシュ更新を考慮せず、古いファイルが配信された原因を調査できない。
このプロジェクトでの役割
このサイトではNext.jsの静的出力をS3へ配置し、CloudFrontで配信します。GitHub ActionsでS3 syncを実行し、デプロイ後にCloudFront Invalidationを実行します。
これにより、低コスト、HTTPS配信、S3非公開、CI/CDをまとめてポートフォリオとして説明できます。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。