CloudFront の設定と運用ポイント｜キャッシュ対策と VPC Origin

はじめに

Amazon CloudFront は、コンテンツを高速かつ安全に配信するための CDN（コンテンツ配信ネットワーク）サービスで、Amazon S3 と組み合わせた Web サイトホスティングなどで広く利用されています。

一方で運用フェーズに入ると、「コストを最適化するための料金クラス（Price Class）の選定」「意図しないキャッシュミス（Miss from cloudfront）の解消」「VPC 内のバックエンドリソースとの安全な通信」といった、一歩踏み込んだ課題に直面することが少なくありません。

本記事では、S3 連携をベースとした CloudFront の基本構成から、運用者が押さえておきたいキャッシュ対策、VPC Origin によるバックエンドの非公開化までを解説します。あわせて、CloudFront Functions でサブディレクトリへのアクセス時に index.html を自動補完する設定手順も紹介します。

運用コストは配信リージョンと料金体系の選択で変わり、用途によっては Price Class やフラットレートプランの見直しが有効です。キャッシュミスの多くはキャッシュキーの設定に起因し、ビヘイビアの見直しで改善が見込めます。バックエンドの保護は、S3 では OAC、ALB / EC2 では VPC Origin が現行の選択肢となります。

CloudFront と S3 の連携構成と料金クラス（Price Class）

CloudFront の最も一般的なユースケースが、Amazon S3 をオリジン（コンテンツの取得元）とする静的 Web サイトの配信構成です。CloudFront を経由させることで、世界中のエッジロケーションからコンテンツを配信できるほか、SSL/TLS 証明書（HTTPS 通信）の適用や、オリジンへの直接アクセスを制限する OAC（Origin Access Control）の利用が可能になります。

また、CloudFront の前段に AWS WAF（Web Application Firewall）を配置すれば、S3 バケットを不正なアクセスから保護する構成を組めます。WAF の IP 制限で生じやすい挙動については、関連記事『AWS WAF の IP 制限で 403 エラーが出る原因と解決方法』を参照してください。

コスト最適化のための料金クラス（Price Class）の選定

CloudFront のデータ転送料金は、配信される地域（エッジロケーション）によって異なります。運用コストを抑える上で重要になるのが、料金クラス（Price Class）の選定です。Price Class は 3 種類が用意されており、利用するエッジロケーションの範囲が異なります。

たとえばターゲットが日本国内やアジア圏中心であれば、南米やオセアニアといった割高なエッジを含まない Price Class 200 を選ぶことで、対象ユーザーへのパフォーマンスを保ちつつコストを抑えられる可能性があります。一方、Price Class 100 は最も安価ですが日本のエッジを含まないため、日本のユーザーは米国・欧州のエッジから配信され、遅延が大きくなります。日本向けのサイトでは Price Class 200 が選定の基準になります。

データ転送の単価は配信リージョンによって異なり、2026 年時点で米国・カナダ・欧州は最初の 10 TB が $0.085/GB 程度、アジアパシフィックは $0.114/GB 程度です（最新の単価は公式の料金ページで確認することをおすすめします）。

従量課金とフラットレート料金プラン

CloudFront の料金体系は、従来の従量課金（pay-as-you-go）に加えて、月額固定のフラットレート料金プランも選択できます。フラットレートプランは、CDN に加えて WAF・DDoS 防御・Route 53（DNS）・CloudWatch Logs・TLS 証明書・サーバーレスのエッジコンピュート・S3 ストレージクレジットなどをまとめて定額化するモデルで、Free（$0）・Pro（$15）・Business（$200）などのプランが用意されています。トラフィックが読みやすく、超過課金を避けたい場合に検討の余地があります（各プランの利用枠は変更される場合があるため、最新の内容は公式ページで確認することをおすすめします）。

参考: Amazon CloudFront Pricing（AWS 公式）
“you pay one price that includes multiple AWS services like CloudFront, WAF, Route 53”
（CloudFront・WAF・Route 53 など複数の AWS サービスを 1 つの料金にまとめて支払う）
https://aws.amazon.com/cloudfront/pricing/

なお無料利用枠として、データ転送 1 TB・HTTP/HTTPS リクエスト 1,000 万件・CloudFront Functions 200 万呼び出しが毎月提供され、これは利用開始からの期間に関わらず恒久的に適用されます。小規模なサイトであれば、この枠内で運用できるケースもあります。

キャッシュミス（Miss from cloudfront）の原因と対策

CloudFront を運用する中で、「想定通りにキャッシュが効かず、オリジンへの通信量や負荷が減らない」という事象が発生することがあります。まずはキャッシュの状態を確認し、原因を切り分けます。

ブラウザの開発者ツールや curl コマンドで HTTP レスポンスヘッダーを確認すると、キャッシュの状態を判別できます。

curl -I https://example.com/path/

レスポンスの x-cache ヘッダーが Miss from cloudfront であれば、エッジロケーションに有効なキャッシュが存在せず、都度オリジン（S3 や ALB など）へ取得しに行っている状態です。Hit from cloudfront であれば、キャッシュから配信されています。

キャッシュヒット率を低下させる主な原因と対処

初回アクセスや TTL（キャッシュの有効期限）切れによるキャッシュミスは正常な動作です。一方、恒常的に Miss となる場合は、キャッシュポリシーの設定を見直す必要があります。

最も多い原因は、不要なクエリ文字列（Query Strings）や HTTP ヘッダー、Cookie をキャッシュキーに含めてしまっているケースです。たとえば、トラッキング用のランダムなクエリ文字列（?utm_source=... や ?session_id=... など）をキャッシュキーに含める設定になっていると、URL が実質的に毎回異なるものと判定され、結果としてほぼすべてのリクエストでキャッシュミスが発生します。

対処として、CloudFront のビヘイビア（Behaviors）で適用しているキャッシュポリシーを確認し、オリジンへ転送する必要のないクエリ文字列やヘッダーはキャッシュキーに含めない（None）設定に変更すると、キャッシュヒット率の改善が見込めます。

バックエンドとの安全な連携（CloudFront VPC Origin）

CloudFront は S3 のような静的コンテンツの配信だけでなく、動的な Web アプリケーションのフロントエンドとしても利用されます。この用途で活用できるのが VPC Origin です。VPC Origin は 2024 年 11 月（re:Invent 2024）に提供が開始された機能で、追加料金なしで利用できます。

従来、CloudFront から VPC（Virtual Private Cloud）内のリソース（ALB や EC2 など）へリクエストを転送するには、それらをパブリックサブネットに配置してインターネット経由で通信させるか、複雑なプロキシ構成を組む必要がありました。

VPC Origin を利用すると、CloudFront から VPC のプライベートサブネット内にある ALB・NLB・EC2 へ、AWS が管理する経路で直接ルーティングできます。これにより、バックエンドにパブリック IP を付与せずに済み、オリジンをインターネットから隔離した状態で CloudFront を唯一の入口にできます。オリジンが公開されないため、CloudFront（および前段の WAF）を迂回した直接アクセスを防ぎ、攻撃面を縮小できます。

参考: Introducing Amazon CloudFront VPC origins（AWS 公式ブログ）
“CloudFront VPC origins is available at no additional cost”
（CloudFront VPC origins は追加料金なしで利用できる）
https://aws.amazon.com/blogs/aws/introducing-amazon-cloudfront-vpc-origins-enhanced-security-and-streamlined-operations-for-your-applications/

提供開始後も機能拡張が続いており、2025 年 11 月にはクロスアカウント対応（AWS RAM 経由で別アカウントの VPC Origin を共有）が、2026 年 5 月には WebSocket 対応が追加されています。マルチアカウント構成でも、オリジンをプライベートに保ったまま CloudFront へ集約できるようになりました。

保護方式の選定（S3 は OAC、ALB/EC2 は VPC Origin）

オリジンの種別によって、推奨される保護方式が異なります。

なお OAC は、従来の OAI（Origin Access Identity）の後継にあたる現行の推奨方式です。新規構築では OAC を選択するとよいでしょう。

制約事項・前提条件（VPC Origin 導入時の注意点）

VPC Origin は構成がシンプルになる一方で、設計時に押さえておきたい前提条件や制約があります。導入前に確認しておくと、つまずきを避けられます。

 インターネットゲートウェイ（IGW）が VPC に必要:
「プライベート」な機能でありながら IGW の attach が要件となります。これは VPC がインターネットからの受信を許可されていることを示すマーカーとしての役割で、オリジンへのルーティングには使われず、ルートテーブルの変更も不要です。サブネット自体はプライベートのまま維持されます。

 プライベートサブネットに利用可能な IPv4 アドレスが 1 つ以上必要:
CloudFront がサービス管理の ENI を作成するために使用します。IPv6 のみのサブネットには対応していません。

 セキュリティグループの許可設定:
オリジン側のセキュリティグループで、CloudFront のマネージドプレフィックスリスト（または自動作成されるサービス管理セキュリティグループ）からの通信を許可する必要があります。

 対応リージョン:
AWS 商用リージョンでのみ利用できます。利用予定のリージョンが対象かを事前に確認しておくとよいでしょう。

 ロードバランサーの制約:
Gateway Load Balancer は VPC Origin に利用できません。NLB の場合、デュアルスタック構成および TLS リスナーを持つ構成は利用できません。

参考: Restrict access with VPC origins（AWS 公式ドキュメント）
“The internet gateway is not used for routing traffic to origins inside the subnet”
（インターネットゲートウェイは、サブネット内のオリジンへのトラフィックのルーティングには使われない）
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html

CloudFront Functions による index.html の自動補完

動的なバックエンドとの連携で VPC Origin が有効な一方、S3 をオリジンとした静的 Web サイトの配信では別の課題に直面することがあります。「サブディレクトリへのアクセス時に index.html が表示されない」という問題です。

S3 を直接「静的ウェブサイトホスティング」として公開している場合は自動で補完されますが、OAC を用いて CloudFront 経由でのみアクセスを許可する構成（S3 の REST API エンドポイントを使用）では、https://example.com/test/ にアクセスしても自動的に https://example.com/test/index.html を読みには行きません。CloudFront のデフォルトルートオブジェクトの設定は、ディストリビューションのルート（最上位）にのみ適用され、サブディレクトリには適用されないためです。

これを解決し、URL に index.html を明示せずに目的のページを表示させるには、CloudFront Functions を使用します。Functions は軽量な URL 書き換えに適しており、Lambda@Edge より低コストで運用できます。

参考: Implementing Default Directory Indexes（AWS 公式ブログ）
“CloudFront Functions is our current recommended service for lightweight manipulation”
（CloudFront Functions は、軽量な操作に対する現行の推奨サービスである）
https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-cloudfront-functions/

関数の作成

CloudFront コンソールの左ペインから「関数」を選択し、「関数を作成」をクリックします。

任意の名前（例: test）を入力して作成後、以下のコードを入力して「変更を保存」します。このコードは AWS 公式ドキュメント（example-function-add-index.html）のサンプルと同一です。

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

    // Check whether the URI is missing a file name.
    if (uri.endsWith('/')) {
        request.uri += 'index.html';
    }
    // Check whether the URI is missing a file extension.
    else if (!uri.includes('.')) {
        request.uri += '/index.html';
    }

    return request;
}

関数の発行

コードを保存したら、「発行」タブから「関数を発行」をクリックします。

この発行を行わずに後述の紐づけを行うと、以下のエラーが表示され、設定が完了しません。

The parameter FunctionAssociationArn is invalid; test was not found or is not published.

ビヘイビアへの紐づけ（関連付け）

対象のディストリビューションを開き、「ビヘイビア」タブから対象のパスパターンを選択して「編集」をクリックします。

画面下部の「関数の関連付け（Function associations）」セクションで、以下のとおり設定して保存します。

• ビューワーリクエスト（Viewer request）: 関数タイプに「CloudFront Functions」を選択
• 関数 ARN / 名前: 作成・発行した関数名（例: test）を選択

設定がディストリビューションに反映（デプロイ）されると、サブディレクトリへのアクセス時に index.html が自動補完されて表示されるようになります。

CloudFront Functions の制約

Functions は高速かつ低コストな一方、設計上の制約があります。これらを超える処理が必要な場合は Lambda@Edge を検討します。

• ネットワークアクセス・ファイルシステムアクセス・環境変数・タイマーは利用できません。
• 実行時間は 1ms 未満、メモリは 2MB、コードサイズは 10KB が上限です。
• 利用できるのは JavaScript（ECMAScript 5.1）のみで、Node.js のモジュールは使えません。
• リクエスト／レスポンスのボディにはアクセスできません。
• トリガーはビューワーリクエストとビューワーレスポンスの 2 種類のみです。

CloudFront Functions と Lambda@Edge の使い分け

URL 書き換えのような軽量な処理は CloudFront Functions、外部通信や複雑なロジックが必要な処理は Lambda@Edge、という使い分けが基本となります。

まとめ

本記事では、Amazon CloudFront の運用で直面しやすい課題と対処を、料金・キャッシュ・バックエンド連携の観点から解説しました。Price Class やフラットレートプランの選定、キャッシュミスの切り分け、VPC Origin によるオリジンの非公開化が要点となります。

• 日本向け配信は Price Class 200 が基準で、100 は日本のエッジを含まない。
• 従量課金に加え、月額固定のフラットレート料金プランも選べる。
• 恒常的なキャッシュミスの多くはキャッシュキーの設定に起因する。
• curl -I で x-cache を確認し、Hit と Miss を切り分ける。
• VPC Origin はプライベートサブネットの ALB や EC2 へ直接ルーティングできる。
• VPC Origin には IGW が必要・IPv6 非対応などの前提条件がある。
• index.html の補完は CloudFront Functions のビューワーリクエストで対応する。

以上、最後までお読みいただきありがとうございました。