S3 にサイトを置けるようになった。ALB の後ろに EC2 も並べられた。ところが設計の話になると、先輩が「前に CloudFront を置いて、S3 は OAC で閉じて」と当たり前のように言い、どこに何が足されたのかがつかめない。CDN という言葉は知っていても、キャッシュがどこにあり、いつ古くなり、誰が証明書を持つのかまでは説明できない。そんな段階の人に向けて、この記事は Amazon CloudFront を「エッジ・オリジン・キャッシュ」の3つの言葉から組み立て直します。
この記事の結論
- Amazon CloudFront は、世界各地のエッジロケーションにコンテンツのコピーを置き、利用者に近い場所から返す AWS の CDN です。
- 元のデータを持つ場所をオリジンと呼び、S3 バケットや ALB などをオリジンにできます。
- エッジがコピーを返すか、オリジンに取りに行くかは、キャッシュキーと TTL で決まり、急ぎで消したいときは無効化を使います。
- S3 をオリジンにするときは、バケットを公開せず、OAC とバケットポリシーで CloudFront からの読み取りだけを許可します。
- 利用者側の HTTPS に使う ACM の証明書と、CloudFront に付ける AWS WAF のウェブ ACL は、どちらも米国東部（バージニア北部）で作ります。
Amazon CloudFront とは何をするサービスか
たとえるなら、CloudFront は「本店の商品を全国の近所の店に置いておく配送網」です。お客さんは遠い本店まで行かず、近くの店で受け取れます。店に無い商品だけ、店が本店から取り寄せて棚に並べます。次に同じ商品を求めた人には、棚からすぐ渡せます。
正確な言葉に戻すと、CloudFront は CDN（コンテンツ配信ネットワーク）です。利用者のリクエストは、利用者に近いエッジロケーションに届きます。エッジにコピー（キャッシュ）があればそこから返し、無ければオリジン（元のデータを持つ S3 や ALB など）に取りに行き、受け取ったものを返しつつエッジに残します。
EDGE FIRSTリクエストの通り道
リクエストは近いエッジで折り返し、無いときだけオリジンへ行く
-
利用者
CloudFront のドメイン名を開く
-
エッジ
DNS で近い拠点に案内される
-
キャッシュ
キーが一致し TTL 内なら即返す
-
オリジン
無いときだけ S3・ALB から取る
-
エッジに残す
次の人には手元のコピーで返す
CloudFront を前に置くと、3つのことが同時に起きます。
- 利用者から見て速くなる。 遠いリージョンのオリジンまで往復せず、近いエッジで折り返せるからです。
- オリジンの負荷が下がる。 同じ画像を何万人が求めても、オリジンに届くのはキャッシュが切れたときの分だけです。
- 入口が1つにまとまる。 HTTPS、独自ドメイン、AWS WAF による防御を、オリジンごとではなく CloudFront でまとめて持てます。
CloudFront の設定の単位はディストリビューションです。1つのディストリビューションに「どのオリジンから取るか」「どのパスをどう扱うか（キャッシュの振る舞い）」「どのドメイン名と証明書で受けるか」を書きます。配信するのは画像や CSS のような静的なものだけではなく、API のような動的な応答も通せます。ただし動的な応答はキャッシュしない設定にするのが普通で、その場合の効き目は「近いエッジで受ける」ことと「入口をまとめる」ことになります。
エッジロケーションとオリジンとは
CloudFront の話は、ほぼすべてが「エッジ側の話」か「オリジン側の話」に分かれます。先にこの2つを分けておくと、設定項目の意味が読めるようになります。
エッジロケーション — 利用者に近い受付
エッジロケーションは、AWS が世界各地に置いている配信の拠点です。リージョンや AZ とは別の、配信のための拠点だと考えてください。利用者が CloudFront のドメイン名を引くと、DNS の仕組みで近いエッジに案内されます。エッジとオリジンの間には、より大きなキャッシュを持つリージョン別のエッジキャッシュも挟まり、エッジで外れたリクエストがすべてオリジンまで届かないようにしています。
READ ALSO — 未経験向け・段1 入口
リージョンと AZ の仕組み｜「どこに置くか」で、速さ・止まりにくさ・料金の何が変わるか
オリジン — 本物のデータを持つ場所
オリジンは「キャッシュが無いときに取りに行く先」です。代表的なものを並べます。
| オリジンの種類 | よくある用途 | 押さえること |
|---|---|---|
| S3 バケット | 静的サイト、画像・動画・ダウンロードファイル | バケットは公開せず、OAC で CloudFront からだけ読ませる |
| ALB（Application Load Balancer） | EC2 やコンテナで動くアプリ、API | ALB に直接来る通信を止める工夫が要る（セキュリティグループで CloudFront のアドレス範囲だけを許可する等） |
| その他の HTTP サーバー（カスタムオリジン） | EC2 のウェブサーバー、AWS の外のサーバー | HTTP か HTTPS で CloudFront から届く場所であればよい |
1つのディストリビューションに複数のオリジンを登録し、パスで振り分けることもできます。たとえば /images/* は S3、/api/* は ALB、という形です。さらに2つのオリジンをオリジングループにまとめると、1つ目が決めておいたエラーを返したときに2つ目へ切り替えられます。別リージョンの S3 にコピーを置いて、配信を止めないための構成です。
READ ALSO — 学習中向け・段2 構成
Elastic Load Balancing とは何か｜ALB・NLB・GWLB の違いとヘルスチェック、複数 AZ
キャッシュはどう決まるのか（キャッシュポリシーと TTL）
CloudFront を使い始めた人が最初につまずくのは「更新したのに古いまま出る」と「キャッシュが効かずオリジンが混む」の2つです。どちらも、キャッシュのルールを知ると理由が分かります。
キャッシュキー — 「同じもの」とみなす条件
エッジは、届いたリクエストが手元のコピーと「同じもの」かをキャッシュキーで判定します。既定ではドメイン名と URL のパスがキーになり、そこにクエリ文字列・ヘッダー・Cookie のどれを含めるかをキャッシュポリシーで決めます。
キーに入れる値が多いほど、同じ URL でもコピーが細かく分かれ、当たりにくくなります。たとえば Cookie をすべてキーに入れると、利用者ごとに別のコピーになり、ほとんどキャッシュが効きません。キーには「応答の中身を変える値」だけを入れる、というのが考え方の軸です。オリジンに渡す必要はあってもキーには入れたくない値は、オリジンリクエストポリシーの側で渡します。AWS はよく使う組み合わせを「マネージドポリシー」として用意しているので、まずはそこから選ぶと迷いが減ります。
TTL — コピーをいつまで信じるか
コピーを「まだ新しい」と信じる時間が TTL です。キャッシュポリシーには最小・既定・最大の3つの TTL があり、オリジンが返す Cache-Control や Expires のヘッダーと組み合わせて決まります。
| 設定 | 役割 | 効くとき |
|---|---|---|
| 最小 TTL | 最低でもこの時間はキャッシュする | 0 より大きいと、オリジンが no-cache などを返してもこの時間はキャッシュする |
| 既定 TTL | オリジンが何も言わないときの期限 | オリジンが Cache-Control も Expires も返さないとき。既定値は 86,400 秒（1日） |
| 最大 TTL | オリジンの指示の上限 | オリジンがヘッダーで長い期限を返したとき、この値で頭打ちにする |
HTTP の Cache-Control の意味は、前提の記事で触れた HTTP の仕組みそのものです。CloudFront はそれを尊重しつつ、ポリシーで上下の枠をはめる、と読むと整理がつきます。
無効化とバージョンつきのファイル名
TTL が切れる前に、どうしても今すぐ新しい中身を出したいときは無効化（インバリデーション）を作ります。指定したパスのコピーをエッジから消し、次のリクエストでオリジンに取りに行かせる操作です。件数によっては料金がかかるので、公式の料金ページで確認してください。
日常的に中身を入れ替えるファイル（CSS や JavaScript など）は、main.v2.css のようにファイル名にバージョンを入れて、参照する側の HTML を書き換える方法もあります。名前が変われば別のキャッシュキーになるので、無効化を待たずに新しい中身が出ます。AWS のドキュメントも、頻繁に更新するファイルにはこの方法を勧めています。
CHECK 1ここまでの確認
CloudFront がオリジンに問い合わせずにエッジから応答できるのは、どんなときですか?
答えと解説
答え: 2. キャッシュキーが一致するコピーがエッジにあり、TTL の期限内のとき
エッジが持っているコピーを返せるのは、キャッシュキーが一致し、まだ期限（TTL）内のときだけです。「キャッシュはどう決まるのか」の章を読み直してください。
S3 をオリジンにするときの OAC とは
CloudFront を前に置いても、S3 のバケットそのものが公開されていれば、利用者は CloudFront を迂回して S3 の URL を直接開けてしまいます。これでは AWS WAF もキャッシュも素通りです。そこで使うのがオリジンアクセスコントロール（OAC）です。
CLOSE THE BACK DOORS3 の門
S3 は公開せず、OAC で署名した CloudFront だけを通す
バケットポリシー
- OACこのディストリビューション 読み取りを許可署名つきで S3 に読みに来る
- 直接S3 の URL を直接開く 拒否CloudFront を迂回したアクセス
- 別ほかのディストリビューション 拒否ポリシーで指定していない
OAC の仕組みは2つの部品でできています。
- CloudFront 側: OAC を設定したディストリビューションは、S3 へのリクエストに署名を付けて送ります。
- S3 側: バケットポリシーで「CloudFront のサービスからで、かつこのディストリビューションからのリクエストだけ読み取りを許可する」と書きます。バケットのパブリックアクセスは閉じたままにします。
片方だけでは門は閉じません。OAC だけ設定してバケットが公開されていれば直接開けますし、バケットポリシーだけ書いても CloudFront が署名しなければ読めません。
以前はオリジンアクセスアイデンティティ（OAI）という仕組みが使われていました。AWS は現在 OAC を勧めていて、理由として、OAC がすべてのリージョンの S3 バケット、KMS のキーを使うサーバー側の暗号化（SSE-KMS）、S3 への PUT や DELETE のような動的なリクエストに対応している点を挙げています。古い構成で OAI を見かけたら、OAC への移行手順が公式に用意されています。
ALB をオリジンにする場合は、OAC ではなく、ALB のセキュリティグループで CloudFront のオリジン向けのアドレス範囲（AWS が管理するプレフィックスリスト）だけを許可する、といった方法で直接のアクセスを絞ります。「オリジンに直接来る道を閉じる」という目的は同じで、閉じ方がオリジンの種類で変わる、と覚えてください。
READ ALSO — 学習中向け・段1 入口
S3 とは何か｜バケットとオブジェクト・ストレージクラス・公開設定を「ディスクではない置き場」で理解する
CHECK 2ここまでの確認
S3 のバケットを公開せず、CloudFront を通したときだけ中身を読ませるには、何を組み合わせますか?
答えと解説
答え: 2. OAC を設定し、バケットポリシーでそのディストリビューションからの読み取りだけを許可する
OAC は CloudFront が署名つきで S3 にリクエストする仕組みで、バケットポリシーで「このディストリビューションからだけ」を許可して初めて門が閉じます。「S3 をオリジンにするときの OAC とは」の章を見てください。
HTTPS の証明書と AWS WAF はどこに付くのか
CloudFront を通る通信には、区間が2つあります。利用者と CloudFront の間（ビューワー側）と、CloudFront とオリジンの間（オリジン側）です。HTTPS もこの区間ごとに考えます。
利用者側の HTTPS と証明書
ビューワー側では、HTTP で来たリクエストを HTTPS にリダイレクトするか、HTTPS だけを受けるかを、キャッシュの振る舞いごとに決められます。d111111abcdef8.cloudfront.net のような CloudFront の既定のドメイン名なら CloudFront の証明書がそのまま使えますが、www.example.com のような独自ドメインで受けるなら、そのドメインの証明書が要ります。
ここで押さえる事実が1つあります。利用者と CloudFront の間の HTTPS に AWS Certificate Manager（ACM）の証明書を使うときは、米国東部（バージニア北部）リージョン（us-east-1）で発行かインポートした証明書を使うことです。東京リージョンなど、ほかのリージョンの ACM で作った証明書は CloudFront の利用者側には使えません。一方、オリジンが ELB のロードバランサーで、CloudFront とオリジンの間を HTTPS にする場合の証明書は、ロードバランサーのあるリージョンで用意します。
| 区間 | 何を決めるか | 証明書の置き場所 |
|---|---|---|
| 利用者 ↔ CloudFront | HTTP を HTTPS に寄せるか、独自ドメインで受けるか | 独自ドメインなら ACM の us-east-1 |
| CloudFront ↔ オリジン | オリジンまで HTTPS で行くか | オリジン側（ELB ならそのリージョンの ACM） |
AWS WAF はエッジで止める
AWS WAF のウェブ ACL は CloudFront のディストリビューションに関連付けられます。そうすると、SQL インジェクションのような攻撃や特定の送信元からのリクエストを、オリジンに届く前にエッジで止められます。CloudFront 用のウェブ ACL は「グローバル（CloudFront）」として作り、これは米国東部（バージニア北部）で作るのと同じ扱いです。ALB 用に東京で作ったウェブ ACL を CloudFront に付けることはできません。
証明書も WAF も「CloudFront は特定のリージョンに属さないので、グローバルなものは us-east-1 に置く」と覚えると、迷いが減ります。
CHECK 3ここまでの確認
利用者と CloudFront の間の HTTPS に ACM の証明書を使うとき、証明書はどのリージョンで発行（またはインポート）しますか?
答えと解説
答え: 1. 米国東部（バージニア北部）リージョン
CloudFront の利用者側の証明書は us-east-1 で発行・インポートしたものを使います。オリジンが ELB のときの、CloudFront とオリジンの間の証明書は別の話です。「HTTPS の証明書と AWS WAF」の章を読み直してください。
CloudFront でよくある誤解はどれか
最後に、学習中によく混ざる理解を実態に置き換えておきます。
MYTH AND FACTよくある誤解
CloudFront の誤解は、キャッシュ・門・リージョンの3つで解ける
よくある誤解
実態
よくある誤解: S3 を更新すればすぐ反映される
実態: TTL が切れるか、無効化するまで古いコピーが返る
よくある誤解: 配信するには S3 を公開する
実態: 公開せず OAC で CloudFront からだけ読ませる
よくある誤解: 証明書と WAF は東京で作る
実態: CloudFront 用はどちらも us-east-1 で作る
よくある誤解: 前に置けば何でも速くなる
実態: 効くのはキャッシュできる応答と、近いエッジで受ける分
CloudFront でやってはいけない3つ
- S3 のバケットを公開したまま CloudFront を前に置き、直接のアクセスを残す
- Cookie やヘッダーを何でもキャッシュキーに入れ、キャッシュがほとんど当たらない状態で使い続ける
- 更新のたびに全パスを無効化する運用を続け、ファイル名のバージョンやTTLの設計を後回しにする
似たサービスとの境目も押さえておきます。AWS Global Accelerator も「利用者に近い入口から AWS のネットワークに乗せる」サービスですが、コンテンツをキャッシュしません。HTTP のコンテンツを配り、キャッシュでオリジンの負荷を下げたいなら CloudFront、TCP や UDP のアプリを固定の IP アドレスで受けて経路を速くしたいなら Global Accelerator、と分かれます。
独自ドメインで CloudFront を使う最後の1ピースは DNS です。www.example.com をディストリビューションに向ける設定は Route 53 のエイリアスレコードで行えるので、次は Route 53 の「とは」に進んでください。
READ ALSO — 学習中向け・段2 構成
Amazon Route 53 とは何か｜ホストゾーン・レコード・ルーティングポリシーを「名前の案内係」で理解する
参照ソース
- What is Amazon CloudFront?（Amazon CloudFront 開発者ガイド） — CDN・エッジロケーション・オリジンの定義（2026年9月時点）
- Understand cache policies（Amazon CloudFront 開発者ガイド） — キャッシュキーとキャッシュポリシー、最小・既定・最大 TTL の意味（2026年9月時点）
- Manage how long content stays in the cache (expiration)（Amazon CloudFront 開発者ガイド） — TTL と Cache-Control・Expires の関係、既定 TTL の既定値（2026年9月時点）
- Invalidate files to remove content（Amazon CloudFront 開発者ガイド） — 無効化とバージョンつきのファイル名（2026年9月時点）
- Restrict access to an Amazon S3 origin（Amazon CloudFront 開発者ガイド） — OAC の仕組みと、OAI より OAC を勧める理由（2026年9月時点）
- Optimize high availability with CloudFront origin failover（Amazon CloudFront 開発者ガイド） — オリジングループによるフェイルオーバー（2026年9月時点）
- Requirements for using SSL/TLS certificates with CloudFront（Amazon CloudFront 開発者ガイド） — ACM の証明書を us-east-1 で用意すること、オリジンが ELB のときの例外（2026年9月時点）
- Resources that you can protect with AWS WAF（AWS WAF 開発者ガイド） — CloudFront 用のウェブ ACL を us-east-1（グローバル）で作ること（2026年9月時点）
