AWS 実践コース・全体像

CloudFront + S3
なぜこの2つを組み合わせるのか

S3は原本を守る倉庫、CloudFrontは世界に開いた配信窓口です。OAC・キャッシュ・独自ドメインまでを一本のリクエスト経路として理解すると、設定項目の意味がつながります。

TL;DR

S3は非公開のままにし、CloudFrontだけに読み取りを許可する。
エッジキャッシュが高速化し、S3へのアクセスを減らす。
独自ドメインはACM・CloudFront・Route 53の3点で完成する。

01全体像 — S3は倉庫、CloudFrontは受付

ブラウザから原本まで、公開範囲を一方向の経路に絞る。

ブラウザ、Route 53、CloudFront、OAC、非公開S3を結ぶ全体構成図 — 公開入口はCloudFrontだけ。S3はOAC経由の要求だけを受け付ける。

講座で作るのは、画像などの静的ファイルを安全かつ高速に配信する基盤です。利用者は独自ドメインへアクセスし、DNSがCloudFrontへ案内します。CloudFrontはキャッシュを確認し、必要な時だけS3から原本を取得します。

覚え方：S3は原本を置く「倉庫」、CloudFrontはHTTPS・キャッシュ・アクセス制御を担当する「公開受付」。

部品	この構成での役割	外部公開
S3	画像などの原本を保存	しない
CloudFront	配信入口・キャッシュ・HTTPS	する
Route 53	独自ドメインをCloudFrontへ案内	DNSとして公開
ACM	HTTPS証明書を発行・管理	証明書をCloudFrontへ関連付け

02キャッシュ — 近い場所から返す

毎回S3へ取りに行かず、エッジにあるコピーを再利用する。

CloudFrontのキャッシュヒットとキャッシュミスの分岐図 — ヒットならエッジで完結。ミスした時だけS3へアクセスする。

最初の要求ではエッジにファイルがなく、CloudFrontがS3へ取得しに行きます。その後の要求は、キャッシュが有効な間は利用者に近いエッジから返せます。

状態	CloudFrontの動き	S3への要求
Cache Hit	エッジのコピーを返す	なし
Cache Miss	S3から取得し、キャッシュして返す	あり
期限切れ・無効化後	オリジンへ再確認または再取得	あり得る

更新時の注意：ファイルを同じキーで上書きしても、古いキャッシュが残ることがあります。実運用ではファイル名にバージョンやハッシュを含める設計が扱いやすいです。

03OAC — CloudFrontだけが倉庫へ入れる鍵

CloudFrontの署名とS3バケットポリシーが対になって、信頼境界を作る。

OAC署名をS3バケットポリシーが検証する信頼境界の図 — OACを関連付け、S3側でも対象DistributionだけにGetObjectを許可する。

OAC（Origin Access Control）は、CloudFrontがS3へ送る要求に署名する仕組みです。ただしOACを作るだけでは不十分で、S3バケットポリシーにもCloudFrontサービスと対象Distribution ARNからの GetObject を許可します。

{
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::<bucket>/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::<account>:distribution/<id>"
    }
  }
}

2つで1組：OACは「誰が来たかを署名する側」、バケットポリシーは「その相手を入れてよいか判定する側」。両方そろって初めて通ります。

04独自ドメイン — 3つの設定を一本につなぐ

証明書、配信先名、DNSのどれか1つでも欠けるとHTTPSアクセスは完成しない。

ACM証明書、CloudFront代替ドメイン、Route 53 Aエイリアスの関係図 — CloudFront用証明書はus-east-1。Route 53のA（エイリアス）はDistributionを指す。

場所	設定するもの	意味
ACM / us-east-1	対象ドメインの証明書	HTTPSで名義を証明
CloudFront	代替ドメイン名 + ACM証明書	そのホスト名を受け付ける
Route 53	Aレコード・エイリアスON・CloudFront宛	利用者をCloudFrontへ案内

「Aレコード編集ってどこ？」の答え：Route 53の対象ホストゾーンで「レコードを作成」。レコードタイプをA、エイリアスをON、ルーティング先をCloudFrontディストリビューションにします。通常のAレコードへIPアドレスを書く操作ではありません。

CloudFrontはグローバルサービスですが、関連付けるACM証明書は米国東部（バージニア北部）us-east-1 に作成します。

05設定単位 — Distribution・Origin・Behavior

似た言葉を、全体・取得先・パス別ルールの3階層で整理する。

単位	答える質問	この講座での例
Distribution	どの配信基盤全体か？	独自ドメイン、証明書、ログなど
Origin	原本をどこから取るか？	非公開S3バケット
Behavior	どのURLパスをどう扱うか？	キャッシュポリシー、HTTPS強制、許可メソッド

たとえるなら：Distribution＝店全体、Origin＝仕入先、Behavior＝商品棚ごとの販売ルール。

06確認と403の切り分け

権限だけを疑わず、経路ごとに一段ずつ確認する。

S3に目的のオブジェクトキーが正確に存在するか確認する。
CloudFrontドメイン + /object-key で取得できるか確認する。
独自ドメインで取得できるか確認する。
S3直URLでは取得できないことを確認する。
失敗時はOAC関連付け、バケットポリシーのDistribution ARN、KMS利用時の権限、CloudFrontの反映状態を確認する。

403 ≠ 権限だけ：S3オリジンでは、存在しないオブジェクトも403として見える場合があります。権限を直し続ける前に、パス・大文字小文字・アップロード先を確認してください。

Browser
  ↓ https://sm.stg.cloud-pratica.com/<object-key>
Route 53 A (Alias)
  ↓
CloudFront ── cache hit → 200
  ↓ cache miss / signed origin request
OAC → private S3 → object exists? → 200 / 403

結論

CloudFrontは単なる高速化装置ではなく、非公開S3の前に置く公開境界でもある。
OAC、バケットポリシー、ACM、Route 53は別々の設定画面でも、1本のリクエスト経路を完成させる部品。
確認はCloudFrontドメイン → 独自ドメイン → S3直アクセス拒否の順で、配信・DNS/TLS・非公開化を分けて見る。