AWS CloudFront入門｜CDNキャッシュ設定の実践
※本記事にはプロモーション（広告）を含みます。
AWS CloudFrontでキャッシュ配信を安定させるなら、まずキャッシュポリシーとオリジン側のCache-Controlヘッダーの設定を一致させることを優先してください。TTL(Time To Live)の値だけを漠然と伸ばしても、オリジンが返すヘッダーと矛盾していれば意図しないキャッシュミスが発生します。本記事では、ディストリビューションの基本構成からキャッシュ動作の設定手順、無効化(Invalidation)の運用、よくある設定ミス、コスト最適化まで、初めてCloudFrontを触るエンジニアが押さえるべき手順を順番に整理しました。
目次
- 基本構成を理解する
- キャッシュ設定の手順
- 無効化と更新戦略
- よくある設定ミス
- コスト最適化のコツ
- よくある質問
基本構成を理解する
CloudFrontはAmazon Web Servicesが提供するCDN(コンテンツデリバリーネットワーク)サービスです。世界各地に配置されたエッジロケーションにコンテンツをキャッシュし、ユーザーから物理的に近い拠点からデータを返すことで、レイテンシを短縮します。設定を始める前に、「ディストリビューション」「オリジン」「ビヘイビア」という3つの用語の関係を押さえておくと、後続の作業でつまずきにくくなります。
オリジンとの関係
ディストリビューションはCloudFrontの配信単位で、1つ以上のオリジンと紐づきます。オリジンにはS3バケット、Application Load Balancer、EC2上のWebサーバー、外部ドメインのカスタムオリジンなどを指定できます。S3を静的サイトのオリジンにする場合は、S3の静的ウェブサイトホスティング機能を使う方法と、Origin Access Control(OAC)を使ってバケットへの直接アクセスを禁止する方法があります。後者のほうがセキュリティ面で推奨される構成です。バージョンによって設定画面の項目名が変わることがあるため、実際の作業前にAWS公式のCloudFrontデベロッパーガイドで最新の手順を確認してください。
エッジロケーションの役割
エッジロケーションは、オリジンのコンテンツをキャッシュして配信する拠点です。リクエストが届くと、CloudFrontはまずエッジ側にキャッシュがあるかを確認し、あればそのまま返却(キャッシュヒット)、なければオリジンへ取りに行きます(キャッシュミス)。ヒット率を上げることが配信速度とオリジン負荷軽減の両方に直結するため、次章で扱うキャッシュ動作の設定が実運用の肝になります。
キャッシュ設定の手順
キャッシュ動作は「ビヘイビア(Behavior)」単位で設定します。パスパターンごとに異なるキャッシュポリシーを割り当てられるため、静的ファイルと動的APIを同じディストリビューション内で扱う構成にも対応できます。設定の基本的な流れは以下のとおりです。
- ディストリビューション作成時、または既存ディストリビューションの編集画面でビヘイビアを追加する
- パスパターン(例: /static/*、/api/*)を指定する
- キャッシュポリシーを選択、または新規作成する
- 圧縮配信の有効化やビューワープロトコルポリシーを設定する
- 変更をデプロイし、反映までの数分を待つ
TTL値の決め方
TTLはキャッシュがオリジンに再確認せず配信され続ける時間です。画像やCSS、JavaScriptのようにファイル名が変わらない限り内容が更新されない静的アセットは、TTLを長め(例えば1年相当の31536000秒)に設定しても問題になりにくい対象です。一方、価格情報やログイン後の個人向けコンテンツのように更新頻度が高いものは、TTLを短く設定するか、キャッシュ自体を無効化する判断が必要です。目安として、更新頻度が1日に複数回あるコンテンツはTTLを数分〜1時間程度に抑える運用が現実的です。
キャッシュポリシー選択
CloudFrontにはAWSが用意したマネージドキャッシュポリシーが複数あります。代表的な3つを比較します。
| ポリシー名 | デフォルトTTL | 最小TTL | 最大TTL | 主な用途 |
|---|---|---|---|---|
| CachingOptimized | 86400秒(1日) | 1秒 | 31536000秒(365日) | 静的アセットなど圧縮配信を活かしたいコンテンツ |
| CachingDisabled | 0秒 | 0秒 | 0秒 | 動的API、個人化されたレスポンス |
| CachingOptimizedForUncompressedObjects | 86400秒(1日) | 1秒 | 31536000秒(365日) | 既に圧縮済みの画像・動画ファイル |
（出典: AWS CloudFrontデベロッパーガイド「マネージドキャッシュポリシーの使用」）
独自のキャッシュポリシーを作成する場合は、Cookie・クエリ文字列・ヘッダーのうちどれをキャッシュキーに含めるかを個別に選べます。クエリ文字列を全て含めるとURLの組み合わせごとにキャッシュが分かれてしまい、ヒット率が下がる原因になります。API側で使っていないパラメータまで含める設定は避けてください。
無効化と更新戦略
キャッシュされたコンテンツを更新したい場合、CloudFrontには2つの主なアプローチがあります。ひとつはInvalidation(無効化)リクエストを送る方法、もうひとつはファイル名やパスにバージョン情報を含めてキャッシュキー自体を変える方法です。
無効化リクエスト
Invalidationは、指定したパスパターンのキャッシュを即座に破棄する機能です。AWSマネジメントコンソール、CLI、SDKのいずれからも実行できます。ただし無料枠を超えるパス数を指定すると課金対象になるため、緊急時の修正用途に留め、日常的な更新手段としては使わない運用が現実的です。無効化が完了するまでには数分程度かかる場合があり、即時反映を前提にした設計は避けたほうが安全です。
ファイル名変更で更新
ビルド時にファイル名へハッシュ値を付与する方式(例: main.a1b2c3.js)は、フロントエンドのビルドツールで広く採用されています。ファイル名が変わればCloudFrontは新しいオブジェクトとして扱うため、無効化リクエストを送らずに確実な更新ができます。TTLを長く設定しても更新の即時性を犠牲にしないため、静的アセット配信ではこちらの方式のほうが運用コストは低くなります。
よくある設定ミス
CloudFrontの設定でつまずくポイントは、オリジン側のヘッダー設定とCloudFront側のポリシー設定の不一致に集中しています。ここでは代表的な2つのケースを取り上げます。
オリジンヘッダー設定
オリジンがCache-Controlヘッダーを返していない場合、CloudFrontはキャッシュポリシーで指定したデフォルトTTLに従って動作します。オリジン側で意図的にno-storeやno-cacheを指定しているつもりでも、CloudFront側のポリシーがそれを上書きしていないか確認してください。特にCachingOptimizedのようなマネージドポリシーを安易に適用すると、オリジンの意図と異なる長さでキャッシュされることがあります。動的コンテンツにはCachingDisabledを明示的に割り当てるか、オリジンレスポンスにCache-Control: no-storeを付与する対応が必要です。
動的コンテンツの誤配信
ログイン状態によって内容が変わるページを、キャッシュキーにCookieを含めないポリシーで配信してしまうと、ある利用者向けのレスポンスが別の利用者に配信される事故につながります。個人情報を含むレスポンスを扱うビヘイビアでは、認証用Cookieをキャッシュキーに含めるか、そもそもキャッシュを無効化する設計にしてください。セキュリティに関わる設定は自己責任での実施が前提となるため、本番反映前にステージング環境で複数アカウントによる配信確認を行うことを推奨します。
コスト最適化のコツ
CloudFrontの料金は転送データ量とリクエスト数に応じて発生します。キャッシュヒット率を上げることが最も基本的なコスト削減策ですが、それ以外にも設定でコントロールできる要素があります。
圧縮配信を有効化
ビヘイビア設定内の「Compress objects automatically」を有効にすると、テキスト系ファイル(HTML、CSS、JavaScript、JSONなど)をGzipやBrotliで自動圧縮して配信します。転送量が減るだけでなく、クライアント側の表示速度改善にもつながります。画像や動画のようにすでに圧縮済みの形式には効果が薄いため、対象ファイル種別を意識した設定が有効です。
Price Classの選び方
ディストリビューション設定にはPrice Classという項目があり、配信に使うエッジロケーションの地理的範囲を選べます。全世界を対象にすると料金の高いリージョンも含まれるため、日本国内向けサービスであれば北米・欧州・アジアを中心としたPrice Classに絞ることで、配信範囲を限定しつつ料金を抑えられます。ユーザー分布が判明している場合は、公式ドキュメントで各Price Classに含まれるリージョン一覧を確認したうえで選定してください。
よくある質問
Q1. TTLを0に設定すると何が起きますか
A. リクエストのたびにオリジンへ確認が行われ、実質的にキャッシュされない状態になります。動的APIなど内容が頻繁に変わる対象に向いていますが、静的アセットに適用するとオリジンの負荷が下がらないため注意してください。
Q2. 無効化リクエストは何回まで無料ですか
A. 無料で利用できるパス数には上限があり、それを超えると1パスごとに課金されます。正確な上限と料金は変更される可能性があるため、AWSの公式料金ページで最新情報を確認してください。
Q3. S3をオリジンにする際の推奨設定は
A. Origin Access Control(OAC)を使い、S3バケットへの直接アクセスを禁止したうえでCloudFront経由のみでコンテンツを配信する構成が推奨されています。バケットポリシーの設定内容は公式ドキュメントの手順に沿って確認してください。
Q4. キャッシュヒット率はどこで確認できますか
A. CloudFrontのモニタリング機能やAmazon CloudWatchのメトリクスでキャッシュヒット率を確認できます。ヒット率が低い場合は、キャッシュキーに含めているクエリ文字列やヘッダーの種類を見直す対応が有効です。
Q5. HTTPSへのリダイレクトは必須ですか
A. 必須ではありませんが、ビューワープロトコルポリシーで「Redirect HTTP to HTTPS」を選択することで、暗号化されていない通信を自動的にHTTPSへ切り替えられます。個人情報を扱うサイトでは有効化を検討してください。
関連記事
まとめ
CloudFrontのキャッシュ設定は、オリジン側のCache-Controlヘッダーとキャッシュポリシーの整合性を取ることから始まります。静的アセットはファイル名にハッシュを付与してTTLを長く保ち、動的コンテンツはCachingDisabledや短めのTTLで個別に扱う、という切り分けが基本方針になります。無効化リクエストは緊急時の手段として位置づけ、日常的な更新にはビルド時のファイル名変更を使う運用のほうが安定します。設定項目や料金体系はAWSのアップデートにより変更されることがあるため、本番環境へ適用する前に必ず公式ドキュメントで最新仕様を確認し、ステージング環境での動作確認を経てから反映してください。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
