2026.07.21 インフラ

Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説

Amazon CloudFrontは、世界中のエッジロケーションからコンテンツを配信するAWSのCDN（コンテンツ配信ネットワーク）です。この記事では、エッジとリージョナルエッジキャッシュの2層キャッシュ、ディストリビューション・オリジン・TTLといった配信の仕組みを一次情報で整理します。さらに、CloudFront FunctionsとLambda@Edgeの使い分け、OACやWAFによる保護、従量課金に加わった料金プラン（Free／Pro／Business／Premium）とPrice Classでのコスト設計、そしてCloudFrontを採用すべき条件と見送るべき場面の判断基準まで、実装者が構成設計で迷う論点を具体的な数値で示します。

目次

まとめ：Amazon CloudFrontの仕組み・料金と採用判断の要点

Amazon CloudFrontは、S3やELB、EC2上のWebサーバーといったオリジンのコンテンツを、世界700規模のエッジロケーションにキャッシュして利用者の近くから配信するCDNです。ディストリビューションという単位で配信設定を作り、その設定が全エッジへ展開されます。エッジにキャッシュがあれば即座に返し、なければリージョナルエッジキャッシュを経てオリジンから取得するため、オリジンへのアクセスとレイテンシの両方を抑えられます。

料金はデータ転送量とリクエスト数に応じた従量課金が基本で、2024〜2025年には月額の料金プラン（Free・Pro・Business・Premium）も加わりました。静的資産の配信や、S3の非公開バケットを安全に公開する用途、動的サイトの高速化に向く一方、拠点間のTCP/UDP高速化が目的ならGlobal Accelerator、単純な社内向け少量配信なら過剰になる場面もあります。判断に迷う実装者は、後半の採用条件と見送り条件を自社のワークロードに当てはめてください。

Amazon CloudFrontの仕組みとCDNとしてのコンテンツ配信フロー

CloudFrontを設計へ落とし込むには、キャッシュがどこに置かれ、ミス時にどう遡ってオリジンへ届くのかを一体で押さえます。ここを曖昧にすると、更新が反映されない構成や、オリジンに負荷が集中する構成を作り込みやすくなります。

エッジロケーションとリージョナルエッジキャッシュによる2層キャッシュ

CloudFrontのキャッシュは2層構造です。1層目は利用者に最も近いエッジロケーション（PoP）で、AWSは2026年時点で世界700規模のPoPを公表しています。2層目はエッジとオリジンの中間に立つリージョナルエッジキャッシュで、複数エッジからのミスを集約してオリジンへのアクセスを減らす中間層です。利用者のリクエストはまず最寄りのエッジに届き、そこにオブジェクトがあれば即返却、なければリージョナルエッジキャッシュ、それでもなければオリジンへと遡ります。この2段構えが、初回アクセスの集中時でもオリジンへ直接届くリクエストを大きく絞ります。

ディストリビューション・オリジン・TTLで決まる配信構成の勘所

配信の起点はディストリビューションで、どのオリジンから何を配るかをここで定義します。オリジンに指定できるのはS3バケット、ELB（ALB/NLB）、EC2やオンプレのカスタムHTTPサーバー、API Gateway、MediaPackageなどです。キャッシュの保持期間はTTLで制御し、既定では各オブジェクトが24時間エッジに留まります。最小は0秒で上限はなく、オリジンが返すCache-Controlヘッダやディストリビューション側の設定で個別に調整できます。頻繁に変わるHTMLはTTLを短く、更新の少ない画像やCSS/JSは長く。この振り分けがキャッシュ設計の初手です。

CDNの一般概念の中でのAmazon CloudFrontの位置づけ

CloudFrontはCDNというカテゴリのAWS実装で、キャッシュやエッジ配信という考え方自体はCDN全般に共通します。CDNの仕組みやキャッシュ制御の一般論、他社サービスとの選び方はCDNとは何かを実装目線で整理した記事にまとめています。CloudFront固有の強みは、S3・ELB・API GatewayといったAWSサービスとの統合の深さと、オリジンからCloudFrontへの転送が無料になる点です。AWS上でシステムを組むなら、外部CDNを挟むより配信までAWS内で完結させたほうが構成も課金も見通しやすくなります。CloudFrontはクラウドネイティブの構成技術を整理した記事でいう配信・エッジの層に当たり、コンピューティングやストレージの前段に置く部品です。

CloudFrontのエッジ機能とセキュリティ・他サービス連携

CloudFrontは単なるキャッシュ配信にとどまらず、エッジでコードを実行し、配信経路そのものを保護する機能を備えます。ここを押さえると、オリジンの負荷を上げずにリダイレクトや認証、改ざん対策まで手前で処理できます。

CloudFront FunctionsとLambda@Edgeの機能差と使い分け

エッジでの処理には2つの選択肢があります。CloudFront Functionsは軽量なJavaScriptをビューアーリクエスト／レスポンスの2点で実行する仕組みで、実行時間はサブミリ秒、単価が安く、URLの書き換えやヘッダ付与、簡単なA/B振り分けに向く軽量オプションです。Lambda@Edgeはより本格的な関数実行環境で、Node.jsやPythonが動き、ビューアーとオリジンの両側リクエスト／レスポンスという4つのトリガー全てに対応します。オリジンへの問い合わせを伴う認証や、外部APIを呼ぶ動的生成はLambda@Edge、単純で高頻度な文字列処理はCloudFront Functions、という切り分けが実務的です。

観点 CloudFront Functions Lambda@Edge
言語 JavaScript（専用ランタイム） Node.js・Python
トリガー ビューアーreq/resの2点 ビューアー・オリジンの4点
実行時間 サブミリ秒級 数十ミリ秒〜秒
向く処理 URL書換・ヘッダ操作・振分け 認証・動的生成・外部API連携

OAC・署名付きURL・AWS WAFで固めるコンテンツ保護

S3バケットを非公開のままCloudFront経由でのみ配信するには、OAC（Origin Access Control）を使います。OACは旧来のOAI（Origin Access Identity）を置き換えた方式で、バケットを直接公開せずCloudFrontからのアクセスだけを許可する仕組みです。会員向けコンテンツや期限付きダウンロードには署名付きURL・署名付きCookieで到達範囲を制御し、SQLインジェクションやボットなどのアプリ層攻撃にはAWS WAFを、L3/L4のDDoSにはShieldを前段に組みます。VPC内のプライベートなオリジンへ直接つなぐVPCオリジンの構成は、CloudFront VPC Originsの仕組みを解説した記事で詳しく追えます。

API GatewayやGlobal Acceleratorとの連携と役割の違い

CloudFrontはAPI GatewayやLambdaと組み合わせると、静的資産だけでなく動的なAPIレスポンスまでエッジでキャッシュ・配信できます。この連携パターンはCloudFrontとAPI Gateway、Lambdaの連携を解説した記事で構成例を確認できます。混同しやすいのがGlobal Acceleratorで、こちらはHTTPコンテンツのキャッシュではなく、TCP/UDPを含む通信をAWSのバックボーンへ引き込んでレイテンシと可用性を上げるサービスです。キャッシュで効くWeb配信はCloudFront、ゲームやIoTなど非HTTPの拠点間高速化はGlobal Accelerator、という役割の違いはGlobal Acceleratorの概要を解説した記事で切り分けられます。

Amazon CloudFrontの料金体系とデータ転送コストの設計

CloudFrontのコストは、同じ配信でも課金モデルとキャッシュ設計の巧拙で大きく変わります。稼働パターンを読み、無駄なオリジンアクセスを削るのがコスト設計の起点です。

従量課金と月額料金プラン（Free・Pro・Business・Premium）

基本はデータ転送量（GB単位・地域別）とリクエスト数に応じた従量課金です。AWSオリジン（S3・ELB・API Gateway）からCloudFrontへの転送は無料で、課金対象はCloudFrontからビューアーへのアウトバウンド転送とリクエスト数に絞られます。2024〜2025年には、これに月額の料金プランが加わりました。Freeは月額0ドルで100GB転送・100万リクエスト・S3ストレージ5GB、Proは15ドルで50TB・1,000万リクエスト、Businessは200ドルで1億2,500万リクエストにカスタムキャッシュルールやVPC内プライベートオリジン、アップタイムSLAが付き、Premiumは1,000ドルで5億リクエストと高度なボット対策まで含みます。全プランにCDN・常時DDoS保護・Route 53 DNS・TLS証明書・サーバーレスエッジ実行が共通で付属します。

プラン 月額 リクエスト/月 データ転送/月 付帯
Free 0 USD 100万 100 GB DDoS保護・TLS・DNS
Pro 15 USD 1,000万 50 TB 上記＋S3 50GB
Business 200 USD 1億2,500万 50 TB カスタムキャッシュ・VPCオリジン・SLA
Premium 1,000 USD 5億 50 TB 上記＋高度ボット対策

Price Classとキャッシュ設計で配信コストを抑える実務

データ転送単価は配信地域によって差があり、Price Classで使用するエッジ地域を絞ると単価の高い地域を外してコストを下げられます。国内向けサービスなら北米・欧州・アジアに限定するPrice Class 200、日本を含む主要地域だけで足りるならさらに絞る、という調整ができます。あわせて効くのがキャッシュヒット率の底上げです。TTLを用途別に設計し、クエリ文字列やCookie、ヘッダをキャッシュキーに含めすぎないようにすると、同一オブジェクトが別物として扱われるのを防ぎ、オリジンへの取りこぼしを減らせます。感覚で全地域配信・短TTLに固定せず、CloudWatchでヒット率と地域別転送量を実測して絞り込むのが配信コスト管理の勘所です。

Amazon CloudFrontを採用すべき条件と見送るべき場面

ここでは判断を言い切ります。CloudFrontは配信の高速化とオリジン保護に効く反面、キャッシュ設計を誤ると更新が届かない、あるいはヒット率が上がらず費用対効果を出せません。自社システムのどこにCloudFrontを差し込むかを、条件付きで見極めてください。

CloudFrontの導入が効くワークロードの条件と設計の勘所

採用が効くのは、地理的に広い利用者へ静的・動的コンテンツを配りたい、S3の非公開バケットを安全に公開したい、オリジンサーバーへの負荷やデータ転送費を下げたい、という条件が重なるときです。具体例は、画像・動画・CSS/JSを多く含むWebサイト、SPAやメディアサイトの配信、APIレスポンスのエッジキャッシュ、ダウンロード配布などが当てはまります。こうしたAWS上の配信基盤やインフラ構成を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、キャッシュ設計やコスト見積もりを含めた構成の妥当性を相談するとよいでしょう。設計時は、まずキャッシュ可能なパスとそうでないパスを分け、TTLとキャッシュキーを用途別に決めるところから始めます。

CloudFrontを見送る・他手段へ寄せる場面と失敗パターン

見送るべきなのは、社内向けで利用者が単一拠点に固まり配信距離の短縮に意味がない用途、そもそもキャッシュできない完全に動的なレスポンスばかりの構成、そしてTCP/UDPの拠点間高速化が目的でHTTP配信ではないワークロードです。最後のケースはGlobal Acceleratorへ寄せるのが筋で、CloudFrontで代替しようとすると要件に噛み合いません。はまりやすい失敗は2つあります。1つはキャッシュキーにCookieやクエリ文字列を無配慮に含め、ヒット率が上がらず高コストと低速を招く構成。もう1つはオリジンにOACを設定せずS3を全公開してしまい、CloudFrontを迂回した直接アクセスを許す構成です。キャッシュキーは必要な要素だけに絞り、S3はOACで非公開に固定する——この2点を前提に組めば、CloudFrontの配信性能と保護を安全に引き出せます。

よくある質問

Amazon CloudFrontの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon CloudFrontとS3は必ずセットで使うのですか？

いいえ、S3はオリジンの選択肢の1つに過ぎません。オリジンにはELB（ALB/NLB）、EC2やオンプレのカスタムHTTPサーバー、API Gateway、MediaPackageなども指定できます。S3を静的サイトのオリジンにする構成は代表例ですが、動的なWebアプリならELBやEC2、APIならAPI Gatewayをオリジンに置く形が一般的です。S3を使う場合はOACで非公開のまま配信するのが安全な既定構成になります。

CloudFront FunctionsとLambda@Edgeはどちらを選ぶべきですか？

URL書き換えやヘッダ付与のような軽量で高頻度な処理はCloudFront Functions、認証や外部API連携、オリジン側での動的生成が必要な処理はLambda@Edgeが基本の分岐です。CloudFront Functionsはサブミリ秒で安価な代わりにビューアー側の2トリガーに限られ、Lambda@Edgeは4トリガー全てに対応する分だけ実行時間とコストが上がります。まず軽量側で足りるかを確認し、届かない要件だけLambda@Edgeへ回すと無駄がありません。

CloudFrontの料金を安く抑えるにはどうすればよいですか？

Price Classで配信地域を必要な範囲に絞り、単価の高い地域を外すのが第一歩です。次にキャッシュヒット率を上げるため、TTLを用途別に設計し、キャッシュキーに含めるCookieやクエリ文字列を必要最小限にします。AWSオリジンからの転送は無料なので、オリジンをAWS内に置くことも費用を抑える設計です。CloudWatchでヒット率と地域別転送量を実測し、取りこぼしの多いパスから見直すのが確実です。

キャッシュを更新したいときはどうすればよいですか？

方法は主に2つあります。1つはTTLを短く設定して自然に期限切れさせる方法、もう1つはInvalidation（キャッシュ無効化）で特定パスのキャッシュを明示的に消す方法です。無効化は毎月一定パス数まで無償で、それを超えるとパス単位で課金されます。頻繁に更新するファイルはファイル名にバージョンやハッシュを付けて別URLにする方が、無効化を多用するより安定してコストも読めます。

CloudFrontとGlobal Acceleratorは何が違いますか？

CloudFrontはHTTP/HTTPSコンテンツをエッジにキャッシュして配信するCDNで、静的・動的なWeb配信の高速化に向きます。一方のGlobal Acceleratorはキャッシュせず、TCP/UDP通信をAWSのバックボーンへ引き込んでレイテンシと可用性を上げるサービスです。ゲームやIoTなど非HTTPのアプリはGlobal Accelerator、Webサイトや動画・APIの配信はCloudFront、と用途で選び分けます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る