Amazon CloudFront コスト最適化入門｜Price Class・キャッシュヒット率・オリジンシールド設計でCDN転送料金を削減する実践ガイド

「CloudFrontの請求、思ったより全然高い……」。クラウド移行後にこの感想を抱くインフラエンジニアは少なくありません。オンプレミスのCDN（Akamai・Cloudflare）と同じ感覚で使い始めると、AWSのCloudFrontは思わぬコストを生みます。データ転送先のリージョン、キャッシュヒット率、Origin Shieldの有無——これらの設定次第で月額費用は大きく変わります。

この記事では、Amazon CloudFrontのコスト構造を正確に把握したうえで、Price Class設定・キャッシュヒット率の改善・Origin Shield導入・CloudFront FunctionsとLambda@Edgeの選択という4つの軸で転送料金を最大限に削減する実践的な設計判断を解説します。AWS Cost ExplorerでCloudFrontのコストを可視化する方法も合わせて説明します。

CloudFrontの料金構造を正確に把握する

コスト最適化の第一歩は、何に課金されているかを正確に理解することです。CloudFrontの料金は大きく以下の4要素で構成されています。

1. データ転送（アウト）料金
エッジロケーションからインターネットへ出るトラフィック（HTTPS/HTTPレスポンス）に対して課金されます。転送先リージョンによって単価が異なり、日本（東京・大阪）への転送は米国向けより高めに設定されています（2026年10月時点）。最初の10TBは比較的安価で、ボリュームが増えるほど単価が下がる階段型の料金体系です。

2. リクエスト料金
HTTPリクエスト数に対して課金されます。HTTPS（HTTP/2含む）とHTTPで単価が異なり、HTTPSの方が若干高くなっています。

3. Origin Shield追加料金
Origin Shieldを有効化した場合、シールドを通過したリクエスト数に対して追加料金が発生します。ただし後述のとおり、オリジンリクエストを削減する効果がこのコストを上回るケースが大半です。

4. 無効化（Invalidation）料金
キャッシュの強制削除（Invalidation）は、月あたり1,000パスまで無料です。それを超えると1パスあたり$0.005（2026年10月時点）の課金が発生します。

見落としがちな「オリジン転送料金」

CloudFrontの料金としてカウントされませんが、キャッシュミスが起きるたびにEC2やALBからCloudFrontへのデータ転送料金が別途発生します。オリジンがS3の場合、S3→CloudFrontのリージョン内転送は無料ですが、EC2やALBオリジンの場合はAWSのデータ転送料金が加算されます。

キャッシュヒット率が低い構成では、この「オリジン転送料金」が請求書のなかで意外と大きな割合を占めることがあります。

AWSデータ転送料金の全体像については、AWSデータ転送料金の仕組みと削減テクニックも参考にしてください。

Price Class設定でリージョン別転送料金を最適化する

CloudFrontでは、コンテンツを配信するエッジロケーションの地理的範囲を「Price Class」で制御できます。これはコスト最適化において、最も手軽で効果が大きい設定のひとつです。

Price Classの3パターンと単価の違い

日本国内のユーザー向けにコンテンツを配信するだけであれば、PriceClass_200で十分カバーできます。北米・欧州にユーザーがほとんどいない場合でも、デフォルトのPriceClass_Allのままにしていると、南米・オーストラリア・インドなどへの転送料金が発生し続けます。

Price Classの変更手順（AWS CLIの例）

既存のディストリビューションのPrice Classを変更するには、まず現在の設定をJSONとして取得し、`PriceClass`の値を書き換えてから更新します。

# AWS CLI: 現在のディストリビューション設定を取得
aws cloudfront get-distribution-config \
  --id DISTRIBUTION_ID \
  --output json > dist-config.json

# dist-config.json を編集して PriceClass を変更する
# "PriceClass": "PriceClass_All" → "PriceClass": "PriceClass_200"

# 変更を適用（ETagが必要なので取得してから実行する）
aws cloudfront update-distribution \
  --id DISTRIBUTION_ID \
  --distribution-config file://dist-config.json \
  --if-match YOUR_ETAG

【重要】Price Classを下げるときのレイテンシへの影響

PriceClass_100に絞ると、日本からのアクセスは北米のエッジから配信されることになり、レイテンシが数十ms増加します。静的コンテンツ（CSS・JS・画像）なら許容できる場合もありますが、API応答やリアルタイム性が重要なコンテンツには向きません。コスト削減幅とユーザー体験のトレードオフを定量的に確認してから変更してください。

キャッシュヒット率を上げてオリジン転送コストを削減する

CloudFrontのコスト削減において最も根本的な施策は、キャッシュヒット率（Cache Hit Ratio）を高めることです。キャッシュヒット率が上がれば、オリジンへのリクエスト数が減り、データ転送料金もオリジン側のサーバー負荷も同時に下がります。

キャッシュヒット率はCloudFrontの「Monitoring」タブ、またはAmazon CloudWatchメトリクスの`CacheHitRate`で確認できます。理想的には80%以上を目指すのが一般的な目安です。

1. TTL設定を適切に調整する

デフォルトでは、オリジンが`Cache-Control`ヘッダーを返さない場合、CloudFrontは独自のデフォルトTTL（24時間）でキャッシュします。しかし`Cache-Control: no-cache`や`no-store`が設定されていると、キャッシュはまったく機能しません。

・最小TTL（Minimum TTL）: オリジンの`Cache-Control`指示を上書きする下限。0秒のままだとno-cacheのコンテンツはキャッシュされない
・デフォルトTTL（Default TTL）: オリジンがキャッシュヘッダーを返さない場合に使われる値
・最大TTL（Maximum TTL）: オリジンのヘッダー指示にかかわらずキャッシュする上限

静的アセット（ハッシュ付きファイル名のJS・CSSなど）には`Cache-Control: max-age=31536000`（1年）を設定してTTLを最大化するのが定石です。動的コンテンツとは別のBehaviorを用意し、静的・動的でキャッシュ設定を分けることが重要です。

2. クエリ文字列・ヘッダーの転送ポリシーを最適化する

CloudFrontはデフォルトで、異なるクエリ文字列が付いたURLを別々のキャッシュエントリとして扱います。たとえば`/image.jpg?v=1`と`/image.jpg?v=2`は別エントリです。

問題は、キャッシュキーに含める必要のないクエリ文字列や不要なHTTPヘッダーを転送している場合です。トラッキングパラメータ（`utm_source`、`fbclid`、`gclid`など）がキャッシュキーに含まれると、同一コンテンツなのにキャッシュが分散してヒット率が著しく下がります。

推奨する設定:
・キャッシュポリシーで「Query Strings: None」または「Allowlist（必要なパラメータのみ）」を選択する
・オリジンリクエストポリシーでオリジンには全パラメータを転送しつつ、キャッシュキーには含めないよう分離する
・不要なHTTPヘッダー（`User-Agent`、`Accept-Encoding`の不適切な転送など）をキャッシュキーから除外する

3. コンテンツを静的・動的で明確に分離する

一般的に、キャッシュヒット率が低い原因の多くは「動的コンテンツがキャッシュ対象に混ざっている」ことです。Behaviorのパスパターンを使って、`/api/*`や`/auth/*`はキャッシュなし（TTL=0）、`/static/*`や`/images/*`は積極的にキャッシュする設定に分けてください。

Origin Shieldでオリジンへのリクエストを集約する

Origin Shieldの仕組み

通常、CloudFrontのエッジロケーションは世界各地に数百か所あり、それぞれがキャッシュを持ちます。キャッシュミスが発生すると、各エッジがオリジンに直接リクエストを送るため、同じコンテンツへの並行リクエストがオリジンに集中することがあります（キャッシュウォームアップ時に特に起きやすい）。

Origin Shieldはエッジとオリジンの中間に追加のキャッシュ階層を設けます。エッジのキャッシュミスがあっても、まずOrigin ShieldのRCキャッシュを確認し、そこにも無ければオリジンへ1本だけリクエストします。

Origin Shieldの導入判断基準

Origin Shieldにはリクエスト数に応じた追加料金が発生します。導入が割に合うのは以下の場合です。

・オリジンがEC2/ALBで、高トラフィック時のオリジン負荷が問題になっている
・グローバルに配信しており、世界各地のエッジからオリジンへのリクエストが多い
・コンテンツの変化が少なく、同一URLへのリクエストが集中しやすい

逆に、オリジンがS3でデータ転送無料、かつキャッシュヒット率が既に高い（90%以上）なら、Origin Shieldを追加する費用対効果は薄いです。

Origin Shieldの設定方法（AWS Management Console）

CloudFrontディストリビューションのオリジン設定で「Enable Origin Shield」を有効化し、オリジンに地理的に近いAWSリージョンを選択するだけです。リージョン選択はオリジンへのレイテンシが最小になるリージョン（東京リージョンのオリジンなら`ap-northeast-1`）を指定してください。

# AWS CLI: Origin ShieldをOrigin設定に追加する例
# 既存オリジン設定の OriginShield ブロックを追加・更新する
# OriginShield:
#   Enabled: true
#   OriginShieldRegion: "ap-northeast-1"

aws cloudfront update-distribution \
  --id DISTRIBUTION_ID \
  --distribution-config file://dist-config-with-origin-shield.json \
  --if-match YOUR_ETAG

CloudFront FunctionsとLambda@Edgeのコスト比較

CloudFrontにはエッジでコードを実行する仕組みが2種類あります。この選択がランニングコストに大きく影響します。

2つの実行環境の料金比較

コスト差は6倍です。URLの正規化・簡単なリダイレクト・HTTPヘッダーの追加削除・A/Bテストのためのルーティングといった軽量な処理であれば、CloudFront Functionsで十分対応できます。

よくあるつまずきとして、「以前Lambda@Edgeで実装した処理をそのままに放置しているケース」があります。ユーザー認証・バックエンドAPI呼び出しなどLambda@Edgeが必要なケースを除き、既存のLambda@Edge関数をCloudFront Functionsに移行するだけで同一処理コストを大幅に削減できます。

Lambda関数全般のコスト管理についてはAWS Lambda コスト最適化入門も参考にしてください。

Invalidation（無効化）のコスト管理

コスト増加の見落とされやすい原因として、過剰なキャッシュ無効化があります。

月1,000パスまでは無料ですが、CI/CDパイプラインからデプロイのたびに`/*`（ワイルドカード全無効化）を実行していると、1パスとしてカウントされる月もあれば、大量のパスを指定して課金が発生する月もあります。特にステージング環境でデプロイ頻度が高い場合は注意が必要です。

コスト削減のためのInvalidation設計:
・更新頻度が高いコンテンツはURLにコンテンツハッシュを付与（例: `main.abc123.js`）し、Invalidationを不要にする
・`/*`の一括Invalidationをやめ、更新されたファイルのパスのみを指定する
・CloudFront Functionsでリダイレクトの版数管理を行い、Invalidation不要の設計にする

CloudFrontのコスト可視化とアラート設定

AWS Cost Explorerでの内訳確認

AWS Cost ExplorerでサービスをCloudFrontにフィルタリングすると、使用タイプ別（データ転送・リクエスト・Lambda@Edge実行など）のコスト内訳が確認できます。「Usage Type」でフィルタリングして`CloudFront-DataTransfer`と`CloudFront-Requests`を比較することで、転送コストとリクエストコストどちらが支配的かが見えてきます。

Cost ExplorerとBudgetsの基本操作はAWS Cost ExplorerとAWS Budgets入門を参照してください。

CloudFrontのコスト急増を検知する

想定外のトラフィック急増（DDoS・クローラー）やキャッシュ設定ミスによるコスト爆発を早期検知するには、AWS Budgetsでサービス別（CloudFront）の月次予算アラートを設定しておくことを強く推奨します。

# AWS CLI: CloudFront専用のコストアラート予算を作成する例
aws budgets create-budget \
  --account-id YOUR_ACCOUNT_ID \
  --budget '{
    "BudgetName": "CloudFront-Monthly",
    "BudgetType": "COST",
    "TimeUnit": "MONTHLY",
    "BudgetLimit": {
      "Amount": "100",
      "Unit": "USD"
    },
    "CostFilters": {
      "Service": ["Amazon CloudFront"]
    }
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "your-email@example.com"
    }]
  }]'

よくあるコスト増加パターンと対処法

パターン1: 全コンテンツのキャッシュTTLが0秒になっている

アプリケーションフレームワーク（Ruby on Railsなど）のデフォルト設定で`Cache-Control: no-cache`が全レスポンスに付与されていると、CloudFrontはまったくキャッシュしません。一見「CloudFrontを使っているのに速くならない」という現象はこれが原因のことが多いです。CloudFrontの「Cache Hit Rate」メトリクスが0%に近い値を示している場合は、オリジンのキャッシュヘッダーを確認してください。

パターン2: API GatewayやALBをオリジンにして動的APIまでCloudFrontを経由させている

認証付きAPIのレスポンスをCloudFrontに通しても、キャッシュは機能しません（Cookieや`Authorization`ヘッダーが含まれるためキャッシュキーが一意になる）。むしろ不必要なリクエスト数とTTL=0のキャッシュミスが料金を押し上げます。

動的API呼び出しにCloudFrontを使う目的がSSL終端・WAF適用・グローバルルーティングであれば意味はありますが、コスト削減が目的なら動的APIはCloudFrontを経由させない構成も検討してください。

パターン3: Lambda@Edgeを不要な処理に使い続けている

前述のとおり、CloudFront FunctionsとLambda@Edgeの単価差は6倍です。軽量処理を移行するだけで、高トラフィックサービスでは月数万円規模の削減になる場合があります。

パターン4: 低トラフィックなS3オリジンでOrigin Shieldを有効化している

Origin Shieldのメリットはオリジンリクエストの集約です。S3オリジンで月間トラフィックが少ない場合、Origin Shield料金の方がS3転送節約額を上回ることがあります。CloudWatchの`OriginRequestCount`と`CacheMissRate`を確認し、Origin Shieldの費用対効果を定期的に見直してください。

コスト最適化施策の優先順位まとめ

本記事のまとめ

Amazon CloudFrontのコスト最適化は、単一の設定変更ではなく複数の施策を組み合わせることで効果が出ます。

・Price Class: 配信対象地域に合わせて最初に見直す。日本向けならPriceClass_200で十分
・キャッシュヒット率: クエリ文字列・ヘッダーのキャッシュキー設計とTTL設定が核心。80%以上を目標にする
・Origin Shield: EC2/ALBオリジンで高トラフィックの場合に有効。S3で低トラフィックなら不要
・CloudFront Functions: Lambda@Edgeの6分の1のコストで同等の軽量処理が可能。既存Lambda@Edgeの移行を検討する
・Invalidation設計: コンテンツハッシュ戦略でInvalidation自体を不要にするのが理想
・可視化: Cost ExplorerとCloudWatchでCacheHitRateとOriginRequestCountを継続的に監視する

オンプレのCDNとの大きな違いは、設定の透明性と変更の即時性です。CloudFrontは設定変更からコストへの反映が比較的速いため、施策の効果を数日単位で確認しながらPDCAを回せます。まずPrice Classの見直しとキャッシュキーポリシーの最適化から始めて、段階的に他の施策を適用するのが現実的なアプローチです。

グローバル配信のレイテンシ最適化という観点では、AWS Global Accelerator入門も合わせて参照してください。