先に要点
- Amazon CloudFront は AWS の CDN(コンテンツ配信ネットワーク)。世界各地の エッジロケーション にコンテンツをキャッシュし、ユーザーから近い場所で返すことで 配信を速くする / オリジンを守る / 帯域料金を下げる の3役を兼ねるサービス。
- 典型構成は S3 / ALB / API Gateway / EC2 → CloudFront → エンドユーザー。オリジン(配信元)を直接公開せず、CloudFront だけインターネットに出す形にして、配信レイヤと防御レイヤを分離する のが定石。
- 強みは AWS リソースとの統合の深さ。Route 53 のエイリアスでサクッと向けられる、ACM の無料 TLS 証明書が使える、WAF をひとつ前段に差せる、S3 オリジンを 「OAC」 で隠せる、など 「AWS の中で完結する設計が組みやすい」。
- 料金は ① 下りデータ転送料金 + ② リクエスト課金 の2軸。「S3 → CloudFront 間の転送が無料」 「CloudFront からの下りは S3 直接配信より単価が安い」 という特性があり、配信規模が大きくなるほど CloudFront を挟んだ方が安くなる ことが多い。
- 判断軸は 静的アセットを多く配信するか」 「海外からのアクセスがあるか」 「オリジンを直接インターネット公開したくないか」 `AWS 内で完結させたいか。「国内向け・小規模・動的中心」 なら CloudFront 抜きでも回るが、上記のどれかに当てはまるなら入れた方が運用が楽になる。
「AWS で Web サービスを立てると、なぜか必ず CloudFront を挟む例ばかり出てくる」 「Cloudflare とどっちでもいいんじゃないの?」 「S3 をそのまま公開するのとは何が違うの?」 ── CloudFront は名前のわりに、「どこからどこまで担当するサービスなのか」 が分かりにくい AWS の代表格です。
ざっくり言うと、CloudFront は 配信の前段に立って、速度・防御・料金の3つを同時に面倒見るレイヤ です。「CDN」 という言葉だけだと 「画像とか CSS を速くするやつ」 で止まりがちですが、オリジンを守る」 「攻撃を止める」 `料金を下げる まで含めて理解すると、なぜ AWS の構成例で必ず出てくるのかが腑に落ちます。
この記事では、CloudFront の 仕組み・料金・他 CDN との違い・実装の入り口 を、「初めて触る人が AWS の構成図を読めるようになる」 ことを目標に整理します。料金の詳細は CloudFront の料金が何で決まるか の記事に分けてあるので、「数字で詰める」 段階ではそちらも併せて読んでください。
CloudFront の役割 — 「CDN だけ」 で済まない理由
CloudFront のドキュメントでは 「CDN サービス」 と書かれていますが、実務で使うと 4つの役割 を兼ねている、と捉えるのが正確です。
① 配信を速くする
世界 600+ のエッジロケーションにコンテンツをキャッシュし、ユーザーから一番近いエッジで返す。「東京のサーバから米国ユーザーに毎回直接返す」 より大幅に速くなる。サイト表示速度は SEO とコンバージョンの両方に効く重要な指標。
② オリジン(配信元)を隠す
S3 を直接公開せず、「OAC(Origin Access Control)」 経由で CloudFront だけがアクセスできる構成にできる。インターネットに直接さらすサーバを減らす のはセキュリティ設計の基本で、CloudFront はそのレイヤを担当する。
「CloudFront = ただの配信高速化」 と思って導入すると、「②〜④の価値を捨てている」 ことになります。AWS の構成図で前段に CloudFront が立っている理由は、4つを束ねて担当しているから です。
仕組み — エッジロケーションとオリジン
CloudFront の動きは、リクエストを 「エッジ → オリジン → エッジ → ユーザー」 と流れる二段構成で考えると分かりやすいです。
「画像や CSS だけのもの」 と誤解されがちですが、動的 API でも CloudFront 経由は有効 です。「キャッシュ無し + WAF + TLS + ログ」 だけで挟むだけでも、防御とドメイン管理のメリットが取れます。
CloudFront でよく使うコンポーネント
CloudFront の中で、まず押さえるべき概念を表で整理します。AWS コンソール上の用語と実務での意味を対応させると、設定画面で迷いにくくなります。
| 用語 | 意味 | 実務で押さえるポイント |
|---|---|---|
| ディストリビューション | CloudFront の設定単位。1つのドメイン(または複数)を束ねる箱 | 本番・ステージング・開発で分けるのが基本。1つにまとめてキャッシュ事故を起こさない |
| オリジン | 配信元(S3 バケット、ALB、API Gateway、独自オリジンなど) | パスごとにオリジンを分けられる(「/api/* は ALB、/* は S3」 のように) |
| ビヘイビア | パスごとに 「キャッシュポリシー / オリジン / WAF / TLS / 圧縮」 を切り替える設定 | API は 「キャッシュなし」、画像は 「1年キャッシュ」 のように分ける |
| キャッシュポリシー | 何をキャッシュキーに含めるか(クエリ文字列、ヘッダ、Cookie)を定義 | 入れすぎるとヒット率が下がる。「必要なものだけキーに入れる」 が基本 |
| OAC(Origin Access Control) | S3 オリジンに対して 「CloudFront だけアクセス可」 にする仕組み | 「S3 をパブリック公開しない」 ための標準。旧 OAI から OAC に切り替わった |
| 署名付き URL / 署名付き Cookie | 有効期限付きで 「この URL を知ってる人だけ」 配信を許可する仕組み | 動画配信、有料コンテンツ、社内資料の限定共有で使う |
| CloudFront Functions / Lambda@Edge | エッジ側で軽い処理(認証ヘッダの追加、リダイレクト、A/B テスト)を走らせる | Functions は超軽量・低料金、Lambda@Edge はフル Node / Python が動く |
最初は ディストリビューション + オリジン + ビヘイビア の3つさえ押さえれば動かせます。OAC や署名付き URL は 「必要になってから」 で問題ありません。
典型構成: S3 + CloudFront
CloudFront のいちばん多い使い方が、S3 を直接公開せず、CloudFront 経由でだけ読めるようにする 構成です。
悪い例: S3 を直接パブリック公開
「 S3 バケットのブロックパブリックアクセスを解除して、誰でも読める設定にする」。誤って機密ファイルを置いた瞬間に世界に公開される 事故が定期的に発生する典型パターン。IAM の権限ミスとも組み合わさりやすい。
正しい例: S3 はプライベート、CloudFront + OAC で配信
S3 はパブリックアクセスをブロックしたままにし、OAC を持った CloudFront からだけ読める 設定にする。バケットポリシーで 「CloudFront の特定ディストリビューション」 のみ許可。S3 を直接 URL 叩いても 403 が返るので、誤公開リスクが激減する。
「S3 単体でも publicAccess を有効にすれば配信できる」 のは確かですが、セキュリティ・速度・料金の3面で CloudFront を挟んだ方が有利 です。「まず CloudFront を挟む」 を AWS の作法として覚えておくと、構成図を書くときに迷いません。
他 CDN との違い
「Cloudflare / Fastly / Akamai / Google Cloud CDN との違いは?」 もよく聞かれる比較です。
| CDN | 強み | 弱み / 注意点 | 向いている場面 |
|---|---|---|---|
| Amazon CloudFront | AWS リソース統合、料金透明性、運用学習コストが AWS と共通 | 世界の最速 CDN ではない、無料枠は控えめ | AWS で完結したい場合、社内システム、企業 Web |
| Cloudflare | 無料プランが厚い、世界配信が速い、WAF/Bot対策が強い | AWS リソースとの統合は別途設定が必要、独自のエコシステム | 個人ブログ、グローバル配信、コスト重視 |
| Fastly | パージ(キャッシュ消去)が即時、VCL でカスタム可能 | 料金が高め、設定の難易度がやや高い | 大手メディア、即時更新を求められるコンテンツ |
| Akamai | 業界最古参、エンタープライズ向け機能とサポート | 料金が高い、小規模には過剰 | 大企業、政府、配信品質に SLA が要るケース |
| Google Cloud CDN | GCP リソースとの統合、Google Front End の安定性 | AWS / Azure メインだと運用が分散する | GCP で完結させたいプロジェクト |
選び方を一言で言うと、「 どのクラウドにオリジンがあるか」 で素直に揃える のが運用上いちばん楽です。「オリジンが AWS なら CloudFront」 「GCP なら Cloud CDN」 が標準。逆に Cloudflare をどこのクラウドでも前段に被せる パターンも、コスト最適化と DDoS 対策の文脈で増えています。
料金の考え方
CloudFront の料金は、シンプルに 下りデータ転送 + リクエスト数 の2軸で決まります。
① 下りデータ転送料金
CloudFront からユーザーへ流れるデータ量に課金。地域(クラス)ごとに単価が違う(日本・米国・欧州は安い、南米・中東・インド・オセアニアは高い)。「Price Class 100/200/All」 で配信地域を限定すれば、高単価地域を切ってコストを抑えられる。
② リクエスト課金
HTTP / HTTPS リクエスト数で課金。「画像が大量に並ぶ Web」 ではリクエスト数も無視できない。Cache-Control / TTL を長めにしてヒット率を上げる ことで、リクエストもオリジン側の負荷も同時に減る。
無料枠
毎月 1TB の下り転送 + 1,000万リクエスト が永続無料(2026年5月時点)。「個人サイトや小規模 SaaS なら、ほぼ無料枠内で運用できる」 ことが多い。
数字で詰める段階では、CloudFront の料金が何で決まるか と CDN が必ずしも帯域コストを下げない理由 を併読してください。
CloudFront を使うべき場面 / 使わなくていい場面
「CloudFront は常に入れた方がいい」 が正解ではありません。判断軸 を整理します。
「AWS の本番 Web ならほぼ常に入れる」 が現実ですが、「小さな検証サイト」 や 「Cloudflare で済む規模」 まで CloudFront を挟むと、設定と料金の管理が逆に手間になります。
CloudFront の落とし穴
最後に、初めて触る人がハマりやすい点を整理しておきます。
キャッシュが効きすぎて更新が見えない
「 画像を差し替えたのに古いまま」 が定番事故。ファイル名をハッシュ付きに変える(「app.abc123.js」) のが王道。どうしても同じ URL で更新したいときは 「Invalidation(キャッシュ削除)」 を発行する。Invalidation は月 1,000 パスまで無料、それ以降は有料。
キャッシュキーにヘッダを入れすぎてヒット率激減
「 クエリ文字列を全部キーに含める」 「User-Agent を含める」 と、同じコンテンツでもキャッシュキーがバラバラ になりヒット率が下がる。「必要なものだけキーに含める」 を意識する。
S3 オリジンの公開設定ミス
「 OAC を作ったのに、S3 のブロックパブリックアクセスや IAM ポリシーが古くて 403」 が頻発。CloudFront → S3 の経路を一気通貫で確認する 癖を付ける。エラーは ` CloudFront のレスポンスヘッダ(「x-amz-cf-*」)」 から原因を辿る。
DDoS / 画像最適化の請求暴発
「 リクエスト課金と転送課金」 が悪意あるアクセスで一気に伸びる事故が現実にある。AWS Budgets でアラート」 「Shield Standard を意識する」 `WAF で Rate Limit を入れる の3点を設定しておくと、夜中に請求が暴発する事故を防げる。Vercel の高額請求 と同じ構造の問題。
Amazon CloudFront に関するよくある質問
Q. Cloudflare と CloudFront のどっちを選べばいいですか?
A. オリジンが AWS なら CloudFront、それ以外 or コスト最優先なら Cloudflare が基本の分かれ目です。CloudFront は AWS リソース統合の深さ(OAC、ACM、Route 53、WAF、CloudWatch との連動)で勝ち、Cloudflare は 無料プランの厚さと世界配信の速さ で勝ちます。両方併用するパターン(「Cloudflare をさらに前段に被せる」)も実在しますが、運用が複雑になるので最初は単独利用がおすすめ。
Q. S3 を直接公開する場合と何が違うんですか?
A. 大きく違うのは ① 速度 ② セキュリティ ③ 料金 ④ ドメイン/HTTPS の4点 です。S3 直接公開は 「世界中から S3 のリージョンへ毎回問い合わせ」 になるため遅く、「独自ドメイン + HTTPS」 を付けるのも一手間。CloudFront を挟むだけで、世界配信 + OAC でオリジン秘匿 + 帯域単価ダウン + ACM 証明書で HTTPS が一気に揃います。
Q. 無料枠だけでどこまで使えますか?
A. 月 1TB の下り転送 + 1,000万リクエスト が永続無料(2026年5月時点)。小〜中規模の個人サイト、技術ブログ、検証 SaaS なら ほぼ無料枠内で運用できる ことが多いです。「AWS WAF を有効にする」 「Lambda@Edge を使う」 場合は別途課金が発生するので、「CloudFront 単体の無料枠と、付随サービスの料金は別」 と理解してください。
Q. キャッシュは何分くらいに設定するのが良いですか?
A. リソースの種類で分ける が答えです。ハッシュ付きファイル名の JS/CSS/画像は 「1年(31536000秒)」 のような長期キャッシュで OK、HTML は 「数分〜数時間」、API レスポンスは 「キャッシュしない or 数秒」、エラーレスポンスは 「数十秒」 がよく使われる目安です。「一律 1日」 のような設定は更新事故の元になりやすいので避けましょう。
Q. CloudFront のログはどう見ればいいですか?
A. 標準ログを S3 に出して Athena でクエリ が王道です。CloudWatch Logs に流す 「リアルタイムログ」 も使えますが、料金がやや高め。「どの URL に何件アクセスが来ているか」 「どこの国からか」 「キャッシュヒット率はどうか」 を見るなら標準ログで十分。HTTP ステータスコード ごとの集計が、運用改善の起点になります。
Q. CloudFront Functions と Lambda@Edge はどう使い分けますか?
A. 軽い処理(リダイレクト、ヘッダ追加、URL 書き換え)は Functions、フル Node / Python のロジックが要るときは Lambda@Edge が基本の分け方です。Functions は 料金が約 1/6、レイテンシも約 1/10 と圧倒的に軽量ですが、できることは限定的。「まず Functions で書けないか試す → ダメなら Lambda@Edge」 の順で考えると無駄が出ません。
Q. CloudFront を入れたら遅くなることはありますか?
A. 設定次第ではある が正直なところです。「キャッシュキーが過剰でほぼ全リクエストがオリジンに行く」 「Lambda@Edge で重い処理を毎回走らせる」 「Price Class All で遠方のエッジまで使うが、ヒット率が低い」 のような設定だと、「直接配信のほうが速かった」 という事故が起きます。キャッシュヒット率 80% 以上 を最初の目標にすると、CloudFront のメリットを取り損ねずに済みます。
まとめ
Amazon CloudFront は、「CDN」 という言葉が示す配信高速化以上に、AWS の前段でセキュリティ・料金・配信を束ねるレイヤ として設計されたサービスです。
「まず CloudFront を挟む」 を AWS の作法として覚え、「いつ挟まないか」 の判断軸を持っておくと、「構成図を読めるエンジニア」 として動きやすくなります。料金の詳細や、「CDN を入れたのに帯域料金が下がらない」 ような実務トラブルは、CloudFront の料金が何で決まるか と CDN が帯域コストを下げない理由 も併せて読むと、現場での判断が一段精度高くなります。
参考リンク
- AWS: Amazon CloudFront
- AWS Docs: Amazon CloudFront Developer Guide
- AWS: CloudFront Pricing
- AWS: Origin Access Control (OAC)
- AWS: CloudFront Functions vs Lambda@Edge