サーバー ソフトウェア 公開日 2026.04.27 更新日 2026.04.27

CloudFrontの料金は何で決まる?リクエスト課金と転送課金の見方

CloudFrontの料金が何で決まるのかを、データ転送、HTTP/HTTPSリクエスト、無効化、Origin Shieldの観点で整理します。請求書でどこを見るべきか、ヒットでもミスでも何が課金されるのかを初心者向けに解説します。

先に要点

  • CloudFront の料金は、まず視聴者向けデータ転送量HTTP/HTTPS リクエスト数で決まりやすいです。
  • リクエスト課金は `HIT だから無料` ではなく、キャッシュヒットでも通常はリクエストとして数えます。
  • 動画、画像、大きいダウンロード配布では転送課金が主役になりやすく、小さいファイルを大量配信する構成ではリクエスト課金も無視しにくくなります。
  • 加えて、無効化Origin Shield のような周辺費用もあるので、`CloudFront = 転送料金だけ` と見ると請求を読み違えやすいです。

CloudFront を使い始めると、請求の見え方でまず迷いやすいです。
特に CDN だから速くなるのは分かるけど、料金は何に対して発生しているのか が直感ではつかみにくいことがあります。

ここで混ざりやすいのが、リクエスト課金転送課金 です。
どちらも CloudFront の主要な料金軸ですが、効き方が違います。

今回は、CloudFront の料金が何で決まるのかを、AWS 公式の料金ページと開発者向けドキュメントをベースに、何が主役になりやすいのか 請求でどこを見るべきか どんな構成だとどちらが膨らむのか まで整理します。
CDN 全体の基本は CDNとは?何が速くなるのか、どこまで必要なのかを解説、請求書全体の追い方は 転送量課金はどこで増える?クラウド請求書で最初に見るべき項目 とつながりますが、今回は CloudFront の料金内訳 を主役にします。

CloudFrontの料金は何が主役なのか

AWSCloudFront ドキュメントでは、CloudFront は主に edge locations からの data transfers outHTTP or HTTPS requests に対して課金されると説明されています。
まずはこの2本が中心です。

ざっくり分けるとこうです。

料金の見方 何に対してかかるか 主役になりやすい場面
データ転送課金 視聴者へ返したレスポンスのバイト量 画像、動画、PDF、ZIP、APIの大きいレスポンス
リクエスト課金 CloudFront に届いた HTTP / HTTPS リクエスト数 小さいファイルが多いサイト、アセット分割が細かい構成
無効化 invalidation で指定したパス数 頻繁に手動パージする運用
Origin Shield 追加レイヤーに届くリクエスト数 マルチCDN、大規模配信、動的配信の最適化

つまり、何GB流れたか だけでは足りません。
何回さばいたか も CloudFront の請求には効きます。

データ転送課金は何に対してかかるのか

一番イメージしやすいのは転送課金です。
これは、CloudFront が視聴者へ返したデータ量に応じて増えていく費用です。

ページ本体、画像、CSS、JavaScript、動画、PDF ダウンロード、API レスポンスなど、CloudFront が返すバイト数が大きいほど請求も伸びやすくなります。

特に効きやすいのは次のような場面です。

  • 高画質画像をそのまま多く返している
  • 動画を配信している
  • CSV や PDF を大量に配布している
  • 一覧APIで大きい JSON を返している

CloudFront の料金ページでも、データ転送量は配信先地域や利用量で単価が変わる前提で整理されています。
なので、同じ1GBでも どこへ配ったかどのくらいの規模か で見え方が変わります。

動画配信のように 1回あたりが重い 場面では、この転送課金がまず主役になりやすいです。
この流れは 動画配信はなぜ高くなりやすいのか?保存費より転送料金が大きくなりやすい理由 でも詳しくつながります。

リクエスト課金は何に対してかかるのか

次に混ざりやすいのがリクエスト課金です。

これは、CloudFront に届いた HTTP / HTTPS リクエスト数に応じて増える費用です。
ここで大事なのは、キャッシュヒットならノーカウント ではないことです。

CloudFront が edge から即返せたとしても、そのリクエスト自体は処理されています。
そのため、データ量が小さくてもリクエスト数が多ければ、リクエスト課金は積み上がります。

リクエスト課金が目立ちやすいのは、たとえばこういう構成です。

  • 小さい画像やアイコンを大量に読み込む
  • JS / CSS を細かく分割しすぎている
  • キャッシュヒット率は高いが、アクセス回数が非常に多い
  • API 呼び出しが細かく多い

1回あたりのデータは軽いのに、ファイル数やアクセス回数が多いサイトでは、転送量より先にリクエスト数を見る 方が当たりやすいことがあります。

HITでもMISSでも何が課金されるのか

ここは請求を読み間違えやすいポイントです。

キャッシュヒット時

キャッシュヒットなら、オリジンへ取りに行かず CloudFront から返せます。
このときオリジン負荷は減りますし、AWS オリジンから CloudFront への転送も気にしなくてよくなりやすいです。

ただし、視聴者へ返している以上、CloudFront から見た配信 は発生しています。
そのため、少なくとも viewer へのデータ転送リクエスト処理 の観点は残ります。

キャッシュミス時

キャッシュミスだと、CloudFront はオリジンへ取りに行ったうえで、視聴者へ返します。
つまり、視聴者向け課金に加えて、オリジンまわりの負荷や構成次第の追加コストが効きやすくなります。

CloudFront の紹介ページや料金説明では、AWS オリジンとの data transfer out が自動で免除される点が案内されています。
これはかなり大きいですが、CloudFront 自体の viewer 向け配信課金まで消える という意味ではありません。

この違いが分かっていないと、HIT なのに請求がある CloudFront を入れたのにまだ高い と感じやすいです。

無効化料金はどこで効くのか

CloudFront はキャッシュ無効化、つまり invalidation を使えます。
便利ですが、これも完全無料ではありません。

AWS の invalidation 料金ドキュメントでは、無効化リクエストを1回送るかどうかではなく、指定した path 数 が課金の数え方の基本だと案内されています。
つまり、まとめて投げても path が多ければそのぶん数える という見方です。

この費用は通常、転送課金やリクエスト課金ほど大きくならないことが多いです。
ただ、頻繁に手動パージする運用や、更新のたびに大量 path を invalidation する運用では、想定外の細かいコスト として効いてきます。

よくあるつらさ

  • 更新のたびに個別 path を大量に無効化している
  • バージョン付きファイル名ではなく、毎回パージ前提で運用している
  • テスト的な invalidation を何度も繰り返している

Origin Shieldはどんなときに課金が増えるのか

Origin Shield は、CloudFront からオリジンへのリクエストをさらに集約して、オリジン負荷を減らすための追加レイヤーです。
AWS のドキュメントでも、オリジンの可用性維持や、just-in-time packaging、画像変換、DTO などのコスト削減に役立つ場面があると説明されています。

ただし、Origin Shield 自体は無料の飾りではなく、追加レイヤーとしての課金があります。
特に AWSOrigin Shield ドキュメントでは、動的リクエストや低TTLGET / HEAD、キャッシュ無効化に近い構成では、増分レイヤーとして課金を見積もる考え方が整理されています。

つまり、Origin Shield は 入れれば常に得 ではありません。
大規模配信やオリジン負荷の高い構成では有効ですが、小さいサイトで何となく足すより、まずは HIT 率やオリジン負荷を見てから判断した方が自然です。

どういうサイトで何が主役になりやすいか

実務では、サイトの性質によって主役が変わります。

1. 画像や動画が重いメディア

この場合は、まず転送課金が効きます。
1回あたりのデータ量が大きいので、アクセスが伸びるほど請求が分かりやすく増えます。

2. 小さいアセットを大量に返すWebアプリ

この場合は、転送量だけでなくリクエスト課金も見た方がよいです。
1回あたりは軽くても、ファイル数が多いと request 数が積み上がります。

3. API 配信中心

API はレスポンスサイズ次第です。
軽いレスポンスを高頻度で返すならリクエスト課金、重い JSON やファイル返却が多いなら転送課金の方が前に出ます。

4. 頻繁に更新してパージが多いサイト

この場合は invalidation 運用も請求の見方に入れるべきです。
とくに ファイル名バージョニングで避けられるコストを、毎回パージで払っていないか は見直しどころです。

請求書で最初にどこを見るべきか

CloudFront の請求を読むときは、いきなり総額だけ見ても原因が分かりにくいです。
最初は次の順で見ると整理しやすいです。

  1. viewer 向けデータ転送量
  2. HTTP / HTTPS リクエスト数
  3. 配信物の種類
  4. invalidation の有無
  5. Origin Shield や周辺設定の有無

そのうえで、

  • 重いファイルが主因か
  • 小さいファイルの数が主因か
  • 更新運用が細かくコストを増やしていないか

を切り分けると、改善ポイントが見えやすくなります。

まとめ

CloudFront の料金は、ざっくり言えば どれだけ配ったか何回さばいたか で決まります。
そして実際の請求は、そこに invalidation や Origin Shield のような周辺要素が少しずつ乗ります。

覚え方としてはこの順で十分です。

  1. 大きいファイルや動画なら、まず転送課金を見る
  2. 小さいファイルが多いなら、リクエスト課金も見る
  3. 頻繁なパージや追加レイヤー設定があるなら、その費用も足して考える

この見方があるだけで、CloudFront が高い何が高いのか に言い換えやすくなります。

関連で読むなら、CDNの基本は CDNとは?何が速くなるのか、どこまで必要なのかを解説、帯域全体の考え方は 帯域コストとは?画像・動画・CDNで請求が膨らみやすい理由、CloudFront を入れても請求が下がらない場面は CDNを入れているのに帯域コストが下がらないのはなぜか がつながります。


参考情報

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。