CloudFront / CDN設計 — キャッシュとオリジン保護

CloudFrontは「置けば速くなる」CDNではありません。キャッシュキーとオリジン保護の設計を外すと、キャッシュヒット率が上がらずコストだけ膨らむか、オリジンが素通しで晒されます。本記事は選定と設計の判断軸を、AWS一次情報に基づいて整理します。

CloudFrontの設計で失敗する典型は「ディストリビューションを作ってオリジンを指すだけ」で終わることです。キャッシュキーの設計を怠ればヒット率が上がらずオリジンへ素通しになり、オリジン保護を怠ればS3やALBが世界中に晒されます。本記事では、キャッシュ動作・オリジン保護・アクセス制御・エッジ処理・コストの5点を、実務の判断軸とともに整理します。

01まず全体像 — リクエストがどこを通るか

設計判断の前に、リクエストがエッジからオリジンまでどの層を通るかを押さえます。CloudFrontはエッジロケーション(ビューワーに最も近い層)、リージョナルエッジキャッシュ(中間層)、必要に応じてオリジンシールド(集約層)を経てオリジンに到達します。キャッシュヒットが手前の層で起きるほど速く、安くなります。

図：CloudFrontのキャッシュ階層。手前の層でヒットするほど低遅延・低コストになり、オリジンシールドは複数リージョナルキャッシュからのフェッチを集約してオリジン負荷を下げます。

この階層構造が、後述するキャッシュキー設計とコスト最適化の前提になります。キャッシュキーが細かすぎると各層でヒットしにくくなり、結局オリジンへ到達する割合が増えるためです。

02キャッシュキーとTTL — ヒット率の8割はここで決まる

キャッシュキーは「キャッシュ上のオブジェクトを一意に識別する鍵」です。ビューワーのリクエストがキャッシュヒットになるかどうかは、このキーの一致で決まります。既定ではURLパスのみですが、キャッシュポリシーでヘッダー・クッキー・クエリ文字列を含められます。ここに不要な要素を含めるほどキーが分散し、ヒット率が落ちます。

TTLはキャッシュポリシーで最小・最大・既定の3値を持ちます。AWSのマネージドキャッシュポリシー(例:CachingOptimized)は最小TTL 1秒・最大TTL 31,536,000秒(365日)・既定TTL 86,400秒(24時間)という値を持ちます。オリジンがCache-ControlやExpiresを返す場合はそれが優先され、既定TTLはオリジンがこれらを返さないときのみ使われます。実務ではオリジン側でCache-Control: max-ageを明示的に設計するのが基本です(具体的な値やマネージドポリシーの構成は変わり得るため、公式で最新を確認してください)。

現場のコツ：クエリ文字列を「全て」キャッシュキーに含める設定は、広告パラメータ(utm_*等)一つ違うだけで別オブジェクト扱いになり、ヒット率を壊します。キャッシュに影響しないパラメータはキーから除外し、必要なものだけを列挙してください。逆にオリジンへはOriginRequestPolicyで転送する、という「キャッシュキーと転送内容の分離」がCloudFront設計の肝です。

キャッシュキーに含める：レスポンスが実際に変わる要素だけ(言語ヘッダー、認証済みかどうかを表すクッキー等)。
キャッシュキーに含めない：トラッキングパラメータ、レスポンスに影響しないヘッダー。含めるとキーが分散。
オリジンに転送する：オリジンのログや動作に必要だがキャッシュを分けたくない要素は、オリジンリクエストポリシー側で転送。

03オリジンの選び方 — S3 / ALB / カスタム

オリジンの種類で保護方式と設計上の注意点が変わります。判断表で整理します。

図：オリジン種別ごとの保護方式の対応。S3はOACが標準、ALB・独自オリジンは「CloudFront経由以外を拒否する」仕組みをオリジン側で用意します。

S3(静的コンテンツ)：後述のOACが標準解。バケットは非公開のまま、CloudFrontだけがアクセスできる構成にします。
ALB(動的アプリ)：CloudFrontが付与するカスタムヘッダー(秘匿値)をALBのWAFやリスナールールで検証し、CloudFrontを経由しない直アクセスを弾きます。ALBのセキュリティグループをCloudFrontのマネージドプレフィックスリストに絞る方法と併用すると堅牢です。
カスタム(オンプレ等)：カスタムヘッダー検証に加え、CloudFront-オリジン間のmTLSやIP制限を組み合わせます。

04OAC — S3オリジン保護の標準

S3オリジンの保護は、現在はOAC(オリジンアクセスコントロール)が推奨です。旧来のOAI(オリジンアクセスアイデンティティ)に対し、OACは全リージョンのS3バケット(2022年12月以降のオプトインリージョン含む)と、AWS KMSによるサーバーサイド暗号化(SSE-KMS)に対応し、短期認証情報・頻繁なローテーション・リソースベースポリシーによって「混乱した代理(confused deputy)」攻撃への保護を強化しています。

設定のポイントは次の通りです(詳細な手順・条件は公式で最新を確認してください)。

S3のオブジェクト所有権を「バケット所有者強制(Bucket owner enforced)」にする(新規バケットの既定)。
バケットポリシーでCloudFrontサービスプリンシパル(cloudfront.amazonaws.com)からのアクセスを許可し、Conditionで「特定のディストリビューション経由のときだけ」に限定する。
署名は「常に署名する(always sign、推奨)」を選ぶと、CloudFront-S3間の通信は常にHTTPSになる。

現場のコツ：OAC移行でよくある詰まりが、バケットポリシーのConditionにディストリビューションARNを入れ忘れ、「同一アカウントのどのCloudFrontからでも読める」状態のまま放置することです。混乱した代理対策の肝はこの条件句なので、AWS Configルールcloudfront-s3-origin-access-control-enabled等で検知できるようにしておくと安全です。SSE-KMS併用時はKMSキーポリシー側にもCloudFrontからのkms:Decrypt許可が必要な点も見落としがちです。

05署名URL / 署名Cookie — 有料/限定コンテンツの制御

OACは「オリジンをCloudFrontだけに絞る」仕組みで、「誰がそのコンテンツを見られるか」は制御しません。会員限定動画や有料ダウンロードのように配信対象を絞りたい場合は、署名URLまたは署名Cookieを使います。両者は同じアクセス制御機能を提供し、使い分けは対象範囲で決めます。

署名URL：個別ファイル(インストーラのダウンロード等)へのアクセスを制限したいとき。URLごとに署名を付与。
署名Cookie：複数の制限ファイルへまとめてアクセスを与えたいとき、または既存のURLを変えたくないとき。

両方を同一ファイルに使い、ビューワーが署名URLでアクセスした場合は、CloudFrontは署名URLだけで可否を判断します(署名URLが署名Cookieに優先)。署名にはRSA 2048およびECDSA 256の鍵が使えます。実装は署名者(信頼できるキーグループ)の設計と鍵管理が要点です。

現場のコツ：署名URLの有効期限を長く取りすぎると、URLが漏れた瞬間に誰でもダウンロードできる「実質公開」状態になります。有効期限は用途に応じ最短にし、IP制限を付けられるカスタムポリシーの利用も検討してください。鍵の管理はKMS等と合わせて統制することが重要で、KMS暗号化設計やSecrets Manager / Parameter Storeの記事も参考になります。

06WAF連携 — 境界防御をエッジに寄せる

AWS WAFのWeb ACLをCloudFrontディストリビューションに関連付けると、リクエストがオリジンに届く前にエッジで検査・ブロックできます。SQLインジェクションやレートベースのDDoS的アクセスを、オリジン負荷をかけずに前段で処理できるのが利点です。

設計上の注意点として、CloudFront向けのWeb ACLはCLOUDFRONTスコープで作成し、リージョンは米国東部(バージニア北部/us-east-1)固定になります。IPセットやルールグループなど関連リソースも同リージョンで用意する必要があります。IaCで複数リージョン展開する場合、この「WAFだけus-east-1」という制約はTerraform/CloudFormationのプロバイダ設定で頻繁に踏む落とし穴です。

マネージドルールで共通脅威をまず塞ぎ、レートベースルールとカスタムIPセットで自社要件を足す、という順で組むのが実務的です。全体のガバナンスはマルチアカウント統制やGuardDuty / Security Hub運用と合わせて設計してください。

07エッジ処理 — CloudFront Functions と Lambda@Edge

エッジでリクエスト/レスポンスを加工したい場合、選択肢はCloudFront FunctionsとLambda@Edgeの2つです。多くのケースでは「まずCloudFront Functionsで足りるか」を検討し、足りないときにLambda@Edgeへ、が正しい順序です。判断表を示します(数値は変わり得るため公式で最新を確認してください)。

観点	CloudFront Functions	Lambda@Edge
言語	JavaScript(ECMAScript 5.1準拠)	Node.js / Python
実行時間	サブミリ秒	最大30秒
メモリ	2MB	128MB〜10GB(トリガー種別による)
ネットワークアクセス	不可	可
リクエストボディへのアクセス	不可	可
スケール	毎秒数百万リクエスト	リージョンあたり毎秒1万リクエスト
向く用途	キャッシュキー正規化、ヘッダー操作、URLリライト/リダイレクト、JWTなど軽量な認可	外部サービス呼び出し、ボディ書き換え、重い処理、SDK/第三者ライブラリ利用

CloudFront Functionsはビューワーリクエスト/レスポンスのトリガーで、ネットワークもファイルシステムも使えない軽量ランタイムです。その代わり全エッジで実行され、超低遅延・低コストです。URL正規化やヘッダー付与のような「ネットワークを使わない変換」は、迷わずCloudFront Functionsを選びます。DB照会や外部API呼び出し、ボディの書き換えが必要ならLambda@Edgeです。Lambdaの本番運用勘所はLambda本番運用も参照してください。

現場のコツ：キャッシュキー正規化(小文字化、パラメータ並べ替え)はCloudFront Functionsの得意分野で、これだけでヒット率が改善しコストも下がることがあります。一方Lambda@Edgeはデプロイの伝播や関数のバージョン管理、削除時のレプリカ残存など運用が重くなりがちです。「本当にエッジで動かす必要があるか、オリジン側やCloudFront Functionsで済まないか」を必ず一度立ち止まって確認してください。

08コストと転送最適化 — 効くのは3つ

CloudFrontの課金は主に「データ転送量(GB)」と「リクエスト数」です。AWSオリジン(S3・EC2・ALB)からCloudFrontへのオリジンフェッチ転送はCloudFront経由の場合に有利になるため、AWS内で完結する構成ほどコスト効率が高くなります。転送単価は配信先リージョンで異なり、また月間転送量が増えるほど段階的に単価が下がります(具体的な単価・しきい値・割引バンドルは頻繁に変わるため、必ず公式の料金ページで最新を確認してください)。

実務で効果が大きいのは次の3点です。

圧縮の有効化：Gzip/Brotli圧縮でテキスト系レスポンスの転送量を大きく削減できます。ディストリビューションで自動圧縮を有効にし、オリジンが圧縮可能なContent-Typeを返すようにします。
キャッシュヒット率の改善：キャッシュキーを絞り、TTLを適切に長く取ることでオリジンフェッチとリクエスト課金を減らします(セクション02が効いてきます)。
プライスクラスの選択：配信対象が国内/一部地域中心なら、Price Class 100等でエッジ範囲を絞りコストを抑える判断もあります。ただしレイテンシとのトレードオフを確認してください。

オリジン負荷が課題なら、オリジンシールドを挟むと複数のリージョナルキャッシュからのフェッチが集約され、オリジンへの重複リクエストが減ります。追加のリクエスト課金は発生するため、オリジン保護効果とのバランスで判断します。関連してNAT Gatewayのコスト設計やS3データレイク設計のように、AWS全体の転送コスト観点で見直すと効果が出やすい領域です。

—まとめ

CloudFront設計は「速くする」より前に「キャッシュキーで何を分けるか」「オリジンをどう閉じるか」を決める作業です。要点を整理します。

キャッシュキーは必要な要素だけに絞り、TTLはオリジンのCache-Controlで明示する。ヒット率の8割はここで決まる。
S3オリジンはOACで閉じ、バケットポリシーのConditionでディストリビューションを限定する。ALB/独自オリジンはカスタムヘッダー+WAFで直アクセスを遮断する。
配信対象を絞るなら署名URL/署名Cookie。有効期限は最短に。
WAFはエッジ境界防御。CloudFront向けはus-east-1固定という制約を忘れない。
エッジ処理はまずCloudFront Functions、ネットワーク/ボディ操作が要るときだけLambda@Edge。
コストは圧縮・ヒット率・プライスクラスの3点が効く。数値は必ず公式で最新を確認する。

既存のCloudFront構成のレビューや、オリジン保護・キャッシュ設計の見直しについては、導入事例もご覧いただき、お問い合わせください。

—参考(一次情報)

CloudFrontを含むCDN・オリジン保護の設計でお困りの場合は、お問い合わせください。現行構成のレビューから対応します。

相談する

← ブログ一覧へ戻る