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

Amazon CloudFrontは、世界750以上のエッジロケーションからコンテンツを配信するAWSのCDN（コンテンツ配信ネットワーク）です。この記事では2層キャッシュとディストリビューション・オリジン・TTLという骨格を公式ドキュメントの数値で整理し、AWS CLIでディストリビューションを作りOACでS3を非公開のまま配信するところまでを、コピーして動く設定JSONとコマンドで示します。CloudFront FunctionsとLambda@Edgeの上限値、月額プランとPrice Classのコスト設計、採用条件と見送り条件も数値で埋めました。

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

Amazon CloudFrontは、S3やELB、EC2上のWebサーバーといったオリジンのコンテンツを、利用者の近くにあるエッジロケーションへキャッシュして配信するCDNです。AWSはCloudFrontの機能ページで、50カ国・100都市以上に750を超えるPoPと15拠点のリージョナルエッジキャッシュ、300都市以上に1,140を超える組み込みPoPを公表しています。配信設定はディストリビューション単位で全エッジへ展開されます。独自ドメインで公開するなら、Amazon Route 53とは？の解説で扱うAliasレコードをこのディストリビューションへ向けてください。

料金はデータ転送量とリクエスト数に応じた従量課金に加え、月額プラン（Free・Pro・Business・Premium）も選べます。プラン側は許容量の範囲内なら超過課金が発生せず、VPCオリジンや稼働率SLAが付くのはBusiness以上です。静的資産の配信、S3の非公開バケットの安全な公開、APIレスポンスのエッジ配信には効きます。一方、拠点間のTCP/UDP高速化が目的ならGlobal Accelerator、単一拠点の社内向け少量配信なら過剰です。

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

キャッシュがどこに置かれ、ミス時にどう遡るのかを一体で押さえます。ここが曖昧だと、更新が反映されない構成を作り込みます。

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

CloudFrontのキャッシュは2層構造です。1層目は利用者に最も近いエッジロケーション（PoP）、2層目はエッジとオリジンの中間に立つリージョナルエッジキャッシュになります。AWSのCloudFrontの動作を説明したドキュメントは、リクエストがまず最寄りのエッジへルーティングされ、そこにオブジェクトが無ければオリジンへ取りに行く流れを示しています。数字で押さえるなら、PoPが750以上に対して中間層は15拠点。この扇形の集約構造が、アクセス集中時にオリジンへ直接届くリクエストを絞ります。

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

配信の起点はディストリビューションで、どのオリジンから何を配るかをここで定義します。AWSのオリジンの種類を整理したドキュメントによれば、S3バケット、ELB（ALB/NLB）、EC2やオンプレのカスタムHTTPサーバー、Elemental MediaPackageなどを指定可能です。保持期間はTTLで制御します。有効期限の管理に関する公式ドキュメントは、キャッシュポリシーを使わない場合の既定TTLが24時間、Cache-Control: max-ageの下限が0秒・上限が100年だと明記しています。

同じドキュメントには、実務で効く2つのディレクティブも載っています。stale-while-revalidateは期限切れ後もエッジが古い応答を返しつつ裏で取り直す指定、stale-if-errorはオリジンが500番台を返す、あるいは到達不能なときに古い応答で凌ぐ指定です。max-age=3600, stale-while-revalidate=600, stale-if-error=86400なら、1時間キャッシュし、期限後10分は再検証しながら旧版を返し、障害時は24時間まで旧版を配れます。TTLを詰める前にこの2つを入れてください。

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

CloudFrontはCDNというカテゴリのAWS実装で、キャッシュやエッジ配信という考え方自体はCDN全般に共通します。一般論と他社サービスの選び方はCDNとは何かを実装目線で整理した記事に、キャッシュモードの設計思想が異なる比較対象はGoogle CloudのCloud CDNを解説した記事にまとめました。固有の強みはAWSサービスとの統合の深さと、AWSオリジンからの転送が無料になる点です。クラウドネイティブの構成技術を整理した記事でいう配信・エッジ層の部品と捉えてください。

エッジで書き換え・認証・遮断を行うCloudFrontの機能と設定

CloudFrontはエッジでコードを実行し、配信経路そのものを保護する機能も備えます。オリジンの負荷を上げずに認証や改ざん対策まで手前で処理できます。

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

エッジ処理には2つの選択肢があります。AWSの両者の違いをまとめた比較表が上限値まで公開しているので、感覚ではなく数値で選べます。CloudFront Functionsはメモリ2MB・コード10KBという枠の中で、サブミリ秒の実行時間と毎秒数百万リクエストのスケールを出す軽量ランタイムです。Lambda@Edgeは最大30秒まで走り、オリジン側トリガーならメモリ10GB・コード50MBまで使えますが、スケールはリージョンあたり毎秒1万に収まります。

切り分けは上限値から機械的に決まります。URL書き換え、ヘッダ付与、キャッシュキーの正規化、JWT検証はCloudFront Functionsで足りる処理です。外部APIを呼ぶ、AWS SDKを読み込む、POSTのボディを見る処理はLambda@Edgeへ回してください。CognitoのログインをLambda@Edgeで実装する具体的な手順とコードはCloudFrontとCognitoで認証を掛ける手順：Lambda@Edge実装と署名付きCookieの比較で解説しています。なお公式の機能解説によれば、CloudFront Functionsは相互TLS（mTLS）の接続確立時に走るconnection requestにも対応します。

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

S3バケットを非公開のままCloudFront経由でのみ配信するには、OAC（Origin Access Control）を使います。AWSのS3オリジンへのアクセス制限に関するドキュメントは、旧来のOAI（Origin Access Identity）が2023年1月以降の新リージョン、SSE-KMS暗号化、PUT・POST・DELETEに対応しないと明記し、OACを推奨しています。既存構成がOAIのままなら、バケットポリシーへ両方のプリンシパルを併記して切り替え、展開完了後にOAI側の文を消してください。設定値の細部はCloudFront OACとOAIの違いを設定手順まで追った記事にあります。

会員向けコンテンツや期限付きダウンロードには署名付きURL・署名付きCookieで到達範囲を制御します。SQLインジェクションやボットなどアプリ層の攻撃はAWS WAFで手前から落とし、防御の考え方はWAFの仕組みと選び方を解説した記事に整理しました。VPCオリジンの公式ドキュメントによれば、ALB・NLB・EC2をパブリックアクセス無しのプライベートサブネットへ置いたまま公開でき、CloudFront-VPCOrigins-Service-SGという管理用セキュリティグループが自動生成されます。詳細はCloudFront VPC Originsの仕組みを解説した記事で追えます。

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

CloudFrontはAPI GatewayやLambdaと組み合わせると、動的なAPIレスポンスまでエッジで配信できます。構成例はCloudFrontとAPI Gateway、Lambdaの連携を解説した記事にあります。混同しやすいのがGlobal Acceleratorです。Global Acceleratorの公式ドキュメントは、2つの静的Anycast IPアドレスを入口にTCP・UDPのトラフィックをAWSのグローバルネットワークへ引き込むサービスだと定義しています。キャッシュしない点が決定的な差で、切り分けはGlobal Acceleratorの概要を解説した記事と読み比べてください。

作業手順｜AWS CLIでCloudFrontを作成しOACでS3を保護する

ここからは手を動かす章です。S3を非公開のまま配信する最小構成を、設定JSONをリポジトリへ置く前提でAWS CLIから作ります。

ディストリビューション設定JSONとcreate-distributionの実行

先にOACを作り、そのIDをオリジン定義へ埋め込みます。キャッシュポリシーはAWS管理のものを使うと手間が減るので、IDは事前に一覧から引いておきます。PriceClass_200を指定しているのは、後述のとおり日本がこのクラスから対象に入るためです。

aws cloudfront create-origin-access-control \
  --origin-access-control-config Name=issoh-oac,SigningProtocol=sigv4,SigningBehavior=always,OriginAccessControlOriginType=s3

aws cloudfront list-cache-policies --type managed \
  --query "CachePolicyList.Items[?CachePolicy.CachePolicyConfig.Name=='Managed-CachingOptimized'].CachePolicy.Id"

aws cloudfront create-distribution --distribution-config file://dist-config.json

設定JSONは次のとおりです。OriginAccessControlIdには1つ目のコマンドが返したID、CachePolicyIdには2つ目が返したIDを入れます。S3OriginConfig.OriginAccessIdentityが空文字なのがOAC構成の目印です。

{
  "CallerReference": "issoh-cf-20260905",
  "Comment": "static assets distribution",
  "Enabled": true,
  "PriceClass": "PriceClass_200",
  "DefaultRootObject": "index.html",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "s3-assets",
        "DomainName": "example-assets.s3.ap-northeast-1.amazonaws.com",
        "OriginAccessControlId": "REPLACE_WITH_OAC_ID",
        "S3OriginConfig": { "OriginAccessIdentity": "" }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "s3-assets",
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "REPLACE_WITH_CACHE_POLICY_ID",
    "Compress": true
  }
}

指定できるフィールドの一覧と既定値はDistributionConfigのAPIリファレンスにあります。PriceClassが取り得る値も同じページに載っていて、PriceClass_100・PriceClass_200・PriceClass_Allの3種類です。

S3バケットポリシーとOAC署名設定で直接アクセスを塞ぐ手順

ディストリビューションを作っただけではS3側が拒否します。バケットポリシーでcloudfront.amazonaws.comサービスプリンシパルを許可し、AWS:SourceArn条件でディストリビューションを限定してください。この条件を書き忘れると、他アカウントのディストリビューションからも読めてしまいます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-assets/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1234567890ABC"
        }
      }
    }
  ]
}

署名の挙動は3択で、公式ドキュメントはalways（常に署名）を推奨しています。neverはOACを一括で無効化する逃げ道で、バケットを公開に戻さないと配信できません。ビューアーのAuthorizationヘッダーを通したい場合だけno-overrideを選び、キャッシュポリシーへ同ヘッダーを追加します。バケット側のObject Ownershipは「バケット所有者の強制」が前提で、ストレージクラスの選び方はAmazon S3の仕組みと料金を整理した記事を参照してください。

CloudFront Functionsでキャッシュキーを絞り込む関数コード

ヒット率が伸びない原因の多くは、キャッシュキーに余計な要素が入っていることです。キャッシュキーの解説ドキュメントは、既定のキーがドメイン名とURLパスだけで構成され、クエリ文字列やヘッダー、Cookieは明示的に含めた場合のみキーに入ると説明しています。広告由来のutm_sourceを素通しすると、同じ画像が別オブジェクト扱いで何度もオリジンへ取りに行かれます。ビューアーリクエストで正規化すれば、キーは1本に集約可能です。

function handler(event) {
  var request = event.request;
  var uri = request.uri;

  if (uri.endsWith('/')) {
    request.uri = uri + 'index.html';
  }

  var qs = request.querystring;
  var allowed = ['v', 'page'];
  Object.keys(qs).forEach(function (key) {
    if (allowed.indexOf(key) === -1) {
      delete qs[key];
    }
  });

  return request;
}

この関数をビューアーリクエストへ関連付けると、許可した2つ以外のクエリ文字列が捨てられ、キャッシュキーが揃います。末尾スラッシュをindex.htmlへ書き換える処理も入れているので、S3をウェブサイトエンドポイントにせずディレクトリ風URLを引けます。ただしコードは10KBまでという上限があるため、ライブラリを読み込む発想は捨ててください。

キャッシュヒット率と無効化をCLIとCloudWatchで確認する

デプロイのたびに全消しするのは費用の面で不利です。無効化の課金に関する公式ドキュメントは、月1,000パスまで無料で超過分はパス単位の課金になると明記しています。ワイルドカードを含むパスは何千ファイルを消しても1パス、枠はアカウント単位の合算です。3つのディストリビューションで600パスずつ投げれば1,800パスとなり、800パス分が課金対象になります。

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/index.html" "/assets/app.css"

aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=E1234567890ABC Name=Region,Value=Global \
  --start-time 2026-09-01T00:00:00Z \
  --end-time 2026-09-05T00:00:00Z \
  --period 86400 --statistics Average --region us-east-1

引数仕様はcreate-invalidationのCLIリファレンスにあります。CloudFrontのCloudWatchメトリクスはグローバル扱いのため、--region us-east-1を付けないと取得できません。無効化に関する公式ドキュメント自体が、頻繁に更新するファイルにはバージョン付きファイル名を推奨しています。企業プロキシやブラウザに残った旧版は、無効化では消せないからです。

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

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

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

従来からの課金はデータ転送量（GB単位・地域別）とリクエスト数に応じた従量制です。AWSオリジン（S3・ELB・API Gateway）からCloudFrontへの転送は無料で、課金対象はビューアーへのアウトバウンド転送とリクエスト数に絞られます。これに加えてCloudFrontの料金ページは月額プランを掲げ、2026年9月時点の表記では許容量の範囲内で追加の超過課金が発生しないと説明しています。日本向けの単価の実額と、定額プランと従量課金が逆転する分岐点はCloudFrontの料金を実額で計算するで解説しています。

プラン選びで効くのは金額よりも機能の段差です。標準ログはPro以上、VPCオリジン・カスタムキャッシュルール・JavaScriptチャレンジ・稼働率SLAはBusiness以上、難読化ボット対策とオリジン負荷低減・高速オリジンルーティング・オリジンフェイルオーバーはPremium以上という切り方になっています。プライベートサブネットのALBをそのままオリジンにしたい構成は、この段差からBusinessが下限です。

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

データ転送単価は配信地域によって差があり、Price Classで使うエッジ地域を絞れば単価の高い地域を外せます。見落としやすいのが対象範囲です。PriceClass_100は米国・カナダ・欧州・イスラエルまでで、日本は含まれません。日本向けサービスならPriceClass_200が下限になり、これで日本・シンガポール・韓国・インド・中東・アフリカまで入ります。国内向けだからとPriceClass_100を選ぶと、日本のPoPが使われず遠方から配信される結果を招きます。

もう一方の軸がヒット率です。前章の関数コードはキャッシュキーを絞る目的で書いたものでした。感覚で全地域配信・短TTLに固定せず、CacheHitRateと地域別転送量をCloudWatchで実測し、取りこぼしの多いパスから直してください。

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

ここでは判断を言い切ります。キャッシュ設計を誤れば更新が届かず、ヒット率も上がりません。自社システムのどこに差し込むかを条件付きで見極めてください。

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

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

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

見送るべきなのは、社内向けで利用者が単一拠点に固まり配信距離の短縮に意味がない用途、キャッシュできない完全に動的なレスポンスばかりの構成、TCP/UDPの拠点間高速化が目的でHTTP配信ではないワークロードです。最後のケースはGlobal Acceleratorへ寄せる場面で、CloudFrontでは要件に噛み合いません。はまりやすい失敗は3つです。1つはキャッシュキーにCookieやクエリ文字列を無配慮に含め、ヒット率が上がらず高コストと低速を招く構成。2つ目はOACを設定せずS3を全公開し、迂回した直接アクセスを許す構成。3つ目はデプロイのたびに/*で全消しし、無料枠1,000パスを食い潰す運用です。キャッシュキーは必要な要素だけに絞り、S3はOACで非公開に固定し、更新はバージョン付きファイル名で回してください。

よくある質問

Amazon CloudFrontの導入検討で実装者から多く挙がる質問を、公式ドキュメントの記述に基づいて整理します。

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

いいえ、S3はオリジンの選択肢の1つに過ぎません。公式ドキュメントはELB（ALB/NLB）、EC2やオンプレのカスタムHTTPサーバー、Elemental MediaPackage、VPCオリジンとしてのプライベートなALB・NLB・EC2も指定できると示しています。動的なWebアプリならELBやEC2、APIならAPI Gatewayをオリジンに置く形が一般的です。

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

URL書き換えやキャッシュキーの正規化のような軽量で高頻度な処理はCloudFront Functions、外部API連携やリクエストボディの参照が必要な処理はLambda@Edgeが基本の分岐です。前者はメモリ2MB・コード10KBという枠の代わりにサブミリ秒と毎秒数百万リクエストを出し、後者は最大30秒と引き換えにスケールがリージョンあたり毎秒1万に収まります。

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

まず月額プランと従量課金のどちらが自社の稼働量に合うかを比べます。プランは許容量内で超過課金が出ない一方、稼働が小さい構成では従量課金が安く収まる場合もあります。次にPrice Classで配信地域を絞り（日本向けはPriceClass_200が下限）、TTLとキャッシュキーを見直してヒット率を上げてください。

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

方法は主に2つです。1つはTTLを短く設定して自然に期限切れさせる方法、もう1つは無効化（Invalidation）で特定パスを明示的に消す方法になります。無効化は月1,000パスまで無償で、ワイルドカードを含むパスは何ファイル消しても1パス換算です。ただし公式ドキュメントはバージョン付きファイル名を推奨しています。ブラウザや企業プロキシに残った旧版は無効化では消せないためです。

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

CloudFrontはHTTP/HTTPSコンテンツをエッジにキャッシュして配信するCDNで、Web配信の高速化に向きます。一方のGlobal Acceleratorはキャッシュせず、2つの静的Anycast IPアドレスを入口にTCP・UDP通信をAWSのグローバルネットワークへ引き込みます。固定IPをファイアウォールに登録したい要件があるならこちらです。非HTTPのアプリはGlobal Accelerator、Web・動画・APIの配信はCloudFrontと選び分けてください。

関連記事

• CDNとは？仕組み・キャッシュ制御からサービスの選び方まで解説：上位概念であるCDN全般の仕組みと選定軸
• CloudFront OACとは？OAIとの違いとS3バケットポリシー設定手順：実装章で扱ったOAC設定の詳細な手順
• CloudFront VPCオリジンとは？ALB・EC2をプライベートのまま公開する設定：プライベートオリジン構成の深掘り
• AWS CloudFront、API Gateway、Lambdaの連携とは何か？基本解説：APIレスポンスをエッジ配信する連携パターン
• AWS Global Acceleratorとは何か：グローバルネットワーク高速化の概要：役割の違いと非HTTP高速化の使い分け