キャッシュビヘイビアと TTL 設定
パスベースのキャッシュビヘイビアを定義し、最小、デフォルト、最大 TTL を設定して、Cache-Control ヘッダーでキャッシュを細かく調整します。
「キャッシュビヘイビアと TTL 設定」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。
キャッシュビヘイビアとは
キャッシュビヘイビアは、異なる URL パスパターンのリクエストを CloudFront がどのように処理するかを定めるルールです。各キャッシュビヘイビアは、パスパターン(例: /images/*、/api/*、*.css)を特定のオリジンとキャッシュ設定に対応付けます。
1 つのディストリビューションには、より具体的なビヘイビアに一致しないすべてのパスに適用されるデフォルトキャッシュビヘイビアが 1 つあり、さらに最大 25 個のパスベースのビヘイビアを追加できます。CloudFront は、最も具体的なものから最も具体性の低いものの順にビヘイビアを評価し、最後にデフォルトへフォールスルーします。
パスパターンの照合
パスパターンではワイルドカードを使用できます。*はスラッシュを含む任意の文字の組み合わせに一致し、?は任意の 1 文字に一致します。例:
/images/*— /images/ で始まるすべての URL*.jpg— パス内の場所に関係なく .jpg で終わるすべてのリクエスト/api/v2/*— すべての API v2 ルート/static/??.css— .css の前に 2 文字がちょうど入る静的 CSS ファイル
ビヘイビアは、ディストリビューション設定に記載された順序で評価されます。より具体的なパターンを先に配置してください。デフォルトビヘイビア(*)は常に最後に一致します。
キャッシュポリシーとオリジンリクエストポリシー
CloudFront では、キャッシュのロジックを 2 種類のポリシーに分けます。
- キャッシュポリシー: CloudFront がキャッシュキーとして使用するものを定義します。これは、キャッシュ済みオブジェクトがリクエストに一致するかどうかを決めるヘッダー、クエリ文字列、Cookie の組み合わせです。また、TTL の範囲も設定します。
- オリジンリクエストポリシー: キャッシュキーの一部ではない場合でも、オリジンに転送するヘッダー、クエリ文字列、Cookie を定義します(トークンごとにキャッシュを分けずに、認証ヘッダーをオリジンへ送信できます)
AWS が提供するマネージドポリシー(例: CachingOptimized、CachingDisabled)で多くのユースケースに対応できます。必要に応じてカスタムポリシーを作成することもできます。
CloudFront の TTL 設定
CloudFront は、キャッシュポリシーの 3 つの TTL 値を使用します。
- 最小 TTL: オリジンのヘッダーに関係なく、CloudFront がオブジェクトをキャッシュする最短時間(デフォルトは 0)
- デフォルト TTL: オリジンが
Cache-ControlヘッダーまたはExpiresヘッダーを送信しない場合に、CloudFront がオブジェクトをキャッシュする時間(デフォルトは 86,400 秒 = 1 日) - 最大 TTL: CloudFront がオブジェクトをキャッシュする最長時間。オリジンの
Cache-Control max-ageディレクティブに上限を設定します(デフォルトは 31,536,000 秒 = 1 年)
これら 3 つの値によって、オリジンが Cache-Control ヘッダーで指定する実際のキャッシュ期間の範囲が決まります。
オリジンからの Cache-Control ヘッダー
オリジンが Cache-Control: max-age=3600 ヘッダーを送信すると、CloudFront はオブジェクトを 3,600 秒間キャッシュします。ただし、この値がキャッシュポリシーの最小 TTL と最大 TTL の範囲内にある場合に限ります。オリジンが Cache-Control: no-cache または Cache-Control: no-store を送信した場合、CloudFront はキャッシュ済みのコピーを提供する前に、毎回オリジンへ確認します。
めったに変更されない静的アセットには、長い max-age(例: 31536000 = 1 年)を設定し、キャッシュバスティングを使用します。ファイル名にコンテンツハッシュ(例: app.a3f4b5.js)を含めると、コンテンツの変更時に URL も変わるため、古いキャッシュバージョンが自動的に無効になります。
# S3 object metadata with long cache TTL
aws s3 cp app.a3f4b5.js s3://my-bucket/ \
--cache-control 'max-age=31536000, immutable' \
--content-type 'application/javascript'静的ビヘイビアと動的ビヘイビアの分離
キャッシュビヘイビアでは、静的コンテンツと動的コンテンツを分離する強力なパターンを使用できます。
/static/*、*.css、*.js、*.jpg→ S3 オリジン、CachingOptimized ポリシー(長い TTL、キャッシュキーに Cookie やクエリ文字列を含めない)/api/*→ ALB オリジン、CachingDisabled ポリシー(常にオリジンから取得し、すべてのヘッダーと Cookie を転送)/*(デフォルト) → ALB オリジン、適度なキャッシュ
この構成では、キャッシュしやすい静的コンテンツ層と動的な API 層を分離できます。静的コンテンツのキャッシュヒット率を高めながら、API レスポンスを常に最新に保てます。
キャッシュの無効化
S3 またはオリジンのコンテンツを更新し、TTL の期限切れを待たずに新しいバージョンを CloudFront からすぐに配信したい場合は、キャッシュの無効化を作成します。無効化するパス(例: /images/logo.png または /images/*)を指定すると、CloudFront はすべてのエッジキャッシュから該当するオブジェクトを削除します。
無効化には料金がかかります。毎月最初の 1,000 パスまでは無料で、それを超えるパスにはパス単位で料金がかかります。ワイルドカードによる無効化(例: /*)は 1 パスとして数えられます。ベストプラクティスは、コストと遅延を抑えるため、頻繁な無効化ではなく静的アセットにバージョン付きファイル名(キャッシュバスティング)を使用することです。
# Create a cache invalidation for updated images
aws cloudfront create-invalidation \
--distribution-id EDFDVBD6EXAMPLE \
--paths '/images/logo.png' '/css/main.css'キャッシュキーの構成要素
キャッシュキーは、キャッシュ済みレスポンスを検索するために CloudFront が使用する一意の識別子です。デフォルトでは、キャッシュキーに含まれるのは URL パスだけです。追加の構成要素を含めると、異なるキャッシュエントリの数が増えます。
- クエリ文字列:
qがキャッシュキーに含まれる場合、/search?q=awsと/search?q=s3は別々のキャッシュエントリになります - ヘッダー:
Accept-Encodingを含めると、CloudFront は gzip 版と非 gzip 版を別々にキャッシュできます - Cookie: セッション Cookie を含めるとユーザーごとのキャッシュエントリが作成され、実質的にキャッシュが無効になります
キャッシュ効率を最大限に高めるには、キャッシュキーの構成要素を最小限にしてください。レスポンスの内容を実際に変えるものだけを含めます。
エッジでの圧縮
CloudFront は、テキストベースのオブジェクト(HTML、CSS、JavaScript、JSON)を gzip または Brotli で自動的に圧縮してからビューワーに配信できます。これによりペイロードサイズが 60~80% 削減され、オリジンを変更せずにページの読み込み時間を短縮できます。
圧縮を有効にするには、キャッシュポリシーのキャッシュキーに Accept-Encoding が含まれていることを確認し(CloudFront は gzip 版と非 gzip 版を別々にキャッシュする必要があります)、キャッシュビヘイビアで Compress Objects Automatically を有効にします。CloudFront は 1,000 バイトを超え、10 MB 未満のオブジェクトを圧縮します。
キャッシュヒット率とモニタリング
キャッシュヒット率は、オリジンにアクセスせず、CloudFront のキャッシュから提供されたリクエストの割合です。ヒット率が高い(80% 以上)と、オリジンのコストが下がり、パフォーマンスが向上します。CloudFront コンソールのキャッシュ統計レポート、または CacheHitRate CloudWatch メトリクスで監視できます。
キャッシュヒット率を向上させる方法には、TTL 値を増やす、キャッシュキーに含めるヘッダーや Cookie の数を減らす、クエリ文字列の正規化を使用する(アプリケーションが実際に使用するクエリ文字列だけを転送する)、オリジンで適切な Cache-Control ヘッダーを設定する、といったものがあります。
# Get CloudFront metrics for cache hit rate
aws cloudwatch get-metric-statistics \
--namespace AWS/CloudFront \
--metric-name CacheHitRate \
--dimensions Name=DistributionId,Value=EDFDVBD6EXAMPLE \
--start-time 2026-06-19T00:00:00Z \
--end-time 2026-06-20T00:00:00Z \
--period 3600 \
--statistics Average \
--region us-east-1ビヘイビアごとのオリジンとプロトコルの設定
各キャッシュビヘイビアは異なるオリジンを指定できるため、1 つの CloudFront ディストリビューションから複数のバックエンドのコンテンツを配信できます。例:
/static/*→ S3 オリジン(OAC 経由の非公開バケット)/api/*→ us-east-1 の ALB オリジン/media/*→ 動画ストリーミング用の MediaPackage CDN オリジン
また、各ビヘイビアでは、ビューワープロトコルポリシー、許可する HTTP メソッド、関数の関連付け(CloudFront Functions または Lambda@Edge)を個別に設定できます。これにより、1 つのディストリビューションを柔軟な多目的配信レイヤーとして利用できます。
クイックチェック
このレッスンで扱った AWS Solutions Architect(SAA-C03)の概念について、理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、キャッシュビヘイビアが URL パスパターンをオリジンとキャッシュルールに対応付けること、最小 TTL、デフォルト TTL、最大 TTL の範囲によってコンテンツのキャッシュ期間を制御し、オリジンの Cache-Control ヘッダーが存在する場合はそれが優先されること、そしてキャッシュの無効化によってすべてのエッジロケーションから古いコンテンツを直ちに削除できることを学びました。ヒット率を最大化するには、キャッシュキーの構成要素を最小限にしてください。次は、署名付き URL、署名付き Cookie、地理的制限について学びます。
よくある質問
「キャッシュビヘイビアと TTL 設定」レッスンは無料ですか?
はい。「キャッシュビヘイビアと TTL 設定」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。
「キャッシュビヘイビアと TTL 設定」で何を学びますか?
パスベースのキャッシュビヘイビアを定義し、最小、デフォルト、最大 TTL を設定して、Cache-Control ヘッダーでキャッシュを細かく調整します。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AWS Solutions Architectを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。
「キャッシュビヘイビアと TTL 設定」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAWS Solutions Architectレッスンでコードを書いて実行できますか?
はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- CloudFront ディストリビューションとオリジン
- キャッシュビヘイビアと TTL 設定
- 署名付き URL、署名付き Cookie、地理的制限
- WAF と Lambda@Edge を組み合わせた CloudFront