# キャッシュと可用性
CloudFront を使用して、オリジンサーバーが直接応答する必要があるリクエストの数を減らすことができます。CloudFront キャッシュを使用すると、ユーザーに近い CloudFront エッジロケーションからより多くのオブジェクトが提供されます。これにより、オリジンサーバーの負荷が軽減され、レイテンシーが減少します。
エッジキャッシュから CloudFront が提供できるリクエスト数が多いほど、オブジェクトの最新バージョンまたは固有バージョンを取得するために CloudFront がオリジンに転送する必要のあるビューワーリクエストが少なくなります。CloudFront を最適化して、オリジンへのリクエストをできるだけ少なくするには、CloudFront Origin Shield の使用を検討してください。詳細については、「[Amazon CloudFront Origin Shield の使用](origin-shield.md)」を参照してください。
すべてのリクエスト数に対する、CloudFront キャッシュから直接提供されるリクエストの比率を*キャッシュヒット率*と呼びます。ヒット、ミス、またはエラーであるビューワーリクエストの割合は CloudFront コンソールで確認できます。詳細については、「[CloudFront キャッシュ統計レポートを表示する](cache-statistics.md)」を参照してください。
キャッシュヒット率に影響を与えるいくつかの要因があります。以下の「[CloudFront キャッシュから直接提供するリクエストの割合 (キャッシュヒット率) を増やす](cache-hit-ratio.md)」のガイダンスを参照して、キャッシュヒット率を向上させるために、CloudFront ディストリビューション設定を調整できます。
CloudFront が配信するコンテンツの追加および削除については、「[CloudFront が配信するコンテンツを追加、削除、または置き換える](AddRemoveReplaceObjects.md)」を参照してください。
**Topics**
+ [
# CloudFront キャッシュから直接提供するリクエストの割合 (キャッシュヒット率) を増やす
](cache-hit-ratio.md)
+ [
# Amazon CloudFront Origin Shield の使用
](origin-shield.md)
+ [
# CloudFront オリジンフェイルオーバーを使用して高可用性を最適化する
](high_availability_origin_failover.md)
+ [
# コンテンツをキャッシュに保持する期間 (有効期限) を管理する
](Expiration.md)
+ [
# クエリ文字列パラメータに基づいてコンテンツをキャッシュする
](QueryStringParameters.md)
+ [
# Cookie に基づいてコンテンツをキャッシュする
](Cookies.md)
+ [
# リクエストヘッダーに基づいてコンテンツをキャッシュする
](header-caching.md)
# CloudFront キャッシュから直接提供するリクエストの割合 (キャッシュヒット率) を増やす
コンテンツのオリジンサーバーにアクセスするのではなく、CloudFront キャッシュから直接提供されるビューワーリクエストの比率を増やしてパフォーマンスを向上させることができます。これは、キャッシュヒット率の向上として知られています。
以下のセクションでは、キャッシュヒット率を改善する方法について説明します。
**Topics**
+ [
## CloudFront がオブジェクトをキャッシュする期間を指定する
](#cache-hit-ratio-duration)
+ [
## オリジンシールドを使用する
](#cache-hit-ratio-use-origin-shield)
+ [
## クエリ文字列パラメータに基づくキャッシュ
](#cache-hit-ratio-query-string-parameters)
+ [
## Cookie 値に基づくキャッシュ
](#cache-hit-ratio-cookies)
+ [
## リクエストヘッダーに基づくキャッシュ
](#cache-hit-ratio-request-headers)
+ [
## 圧縮が不要な場合に `Accept-Encoding` ヘッダーを削除する
](#cache-hit-ratio-remove-accept-encoding)
+ [
## HTTP 経由でメディアコンテンツを提供する
](#cache-hit-ratio-http-streaming)
## CloudFront がオブジェクトをキャッシュする期間を指定する
キャッシュヒット率を向上させるには、[Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) ディレクティブをオブジェクトに追加し、`max-age` に対して最も長い実用的な値を指定するようにオリジンを設定します。キャッシュ期間が短ければ短いほど、オブジェクトが変更されているかどうかを特定して最新バージョンを取得するリクエストを CloudFront がオリジンに送信する頻度が高くなります。`stale-while-revalidate` および `stale-if-error` ディレクティブで `max-age` を補足すると、特定の条件下でのキャッシュヒット率をさらに向上させることができます。詳細については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
## オリジンシールドを使用する
CloudFront Origin Shield は、オリジンの前に追加のキャッシュレイヤーを提供するため、CloudFront ディストリビューションのキャッシュヒット率を向上させるために役立ちます。Origin Shield を使用すると、CloudFront のすべてのキャッシュレイヤーからオリジンへのすべてのリクエストは、1 つの場所から送信されます。CloudFront は、各オブジェクトを Origin Shield からオリジンへの 1 つのリクエストを使用して取得できます。CloudFront キャッシュの他のすべてのレイヤー (エッジロケーションと[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) は、OriginShield からオブジェクトを取得できます。
詳細については、「[Amazon CloudFront Origin Shield の使用](origin-shield.md)」を参照してください。
## クエリ文字列パラメータに基づくキャッシュ
クエリ文字列パラメータに基づいてキャッシュするように CloudFront を設定する場合、以下を行うことでキャッシュを改善できます。
+ オリジンが一意のオブジェクトを返すクエリ文字列パラメータのみを転送するように CloudFront を設定する。
+ 同じパラメータのすべてのインスタンスで大文字と小文字の区別を統一する。例えば、1 つのリクエストに `parameter1=A` が含まれており、別のリクエストに `parameter1=a` が含まれている場合、CloudFront は `parameter1=A` が含まれているリクエストと `parameter1=a` が含まれているリクエストを 2 つの個別のリクエストとしてオリジンに転送します。これが行われると、オブジェクトは同一であっても、CloudFront はオリジンから個別に返された対応するオブジェクトを個別にキャッシュします。`A` または `a` のどちらかのみを使用すると、CloudFront がオリジンに転送するリクエストが少なくなります。
+ パラメータの順序を統一する。大文字と小文字が区別されることと同じように、あるオブジェクトに対するリクエストに `parameter1=a¶meter2=b` というクエリ文字列が含まれており、同じオブジェクトに対する別のリクエストに `parameter2=b¶meter1=a` が含まれている場合、オブジェクトは同一であっても、CloudFront は両方のリクエストをオリジンに転送し、対応するオブジェクトを個別にキャッシュします。パラメータの順序を統一すると、CloudFront がオリジンに転送するリクエストが少なくなります。
詳細については、「[クエリ文字列パラメータに基づいてコンテンツをキャッシュする](QueryStringParameters.md)」を参照してください。CloudFront がオリジンに転送するクエリ文字列を確認するには、CloudFront ログファイルの `cs-uri-query` 列の値を参照します。詳細については、「[アクセスログ (標準ログ)](AccessLogs.md)」を参照してください。
## Cookie 値に基づくキャッシュ
Cookie 値に基づいてキャッシュするように CloudFront を設定する場合、以下を行うことでキャッシュを改善できます。
+ すべての Cookie を転送する代わりに特定の Cookie のみを転送するように CloudFront を設定する。Cookie をオリジンに転送するように CloudFront を設定する場合、CloudFront は Cookie の名前と値のすべての組み合わせを転送します。その場合、オリジンが返すオブジェクトがすべて同一であっても、別々にキャッシュされます。
たとえば、ビューワーがすべてのリクエストに 2 つの Cookie を含め、それぞれの Cookie に使用できる値が 3 つあり、Cookie 値のすべての組み合わせが可能であるとします。CloudFront は、オブジェクトごとに最大 9 つの異なるリクエストをオリジンに転送します。オリジンが 1 つの Cookie のみに基づいて同じオブジェクトの複数のバージョンを返す場合、CloudFront は必要以上のリクエストをオリジンに転送し、同一オブジェクトの複数のバージョンを不必要にキャッシュします。
+ 静的コンテンツと動的コンテンツに対してそれぞれ異なるキャッシュ動作を作成し、動的コンテンツの場合にのみ Cookie をオリジンに転送するように CloudFront を設定する。
例えば、ディストリビューションのキャッシュ動作が 1 つしかなく、このディストリビューションを `.js` ファイルなどの動的コンテンツと頻繁に変更されない `.css` ファイルの両方に使用するとします。CloudFront は Cookie 値に基づいて個別のバージョンの `.css` ファイルをキャッシュするため、それぞれの CloudFront エッジロケーションがすべての新しい Cookie 値または Cookie 値の組み合わせに対してリクエストをオリジンに転送します。
Cookie 値に基づいて CloudFront がキャッシュしない、`*.css` というパスパターンのキャッシュ動作を作成すると、CloudFront は、エッジロケーションが特定の `.css` ファイルに対して受け取る最初のリクエストおよび `.css` ファイルの有効期限が切れた後の最初のリクエストでのみ `.css` ファイルのリクエストをオリジンに転送します。
+ Cookie 値がユーザーごとに一意である (ユーザー ID など) 動的コンテンツと、より少ない数の一意の値に基づいて変化する動的コンテンツに対してそれぞれ異なるキャッシュ動作を作成する (可能な場合)。
詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。CloudFront がオリジンに転送する Cookie を確認するには、CloudFront ログファイルの `cs(Cookie)` 列の値を参照します。詳細については、「[アクセスログ (標準ログ)](AccessLogs.md)」を参照してください。
## リクエストヘッダーに基づくキャッシュ
リクエストヘッダーに基づいてキャッシュするように CloudFront を設定する場合、以下を行うことでキャッシュを改善できます。
+ すべてのヘッダーに基づいて転送およびキャッシュする代わりに特定のヘッダーのみに基づいて転送およびキャッシュするように CloudFront を設定します。CloudFront は、指定したヘッダーの名前と値のすべての組み合わせを転送します。その場合、オリジンが返すオブジェクトがすべて同一であっても、別々にキャッシュされます。
**注記**
CloudFront は常に以下のトピックで指定されているヘッダーをオリジンに転送します。
CloudFront がリクエストを処理して Amazon S3 オリジンサーバーに転送する方法 > [CloudFront が削除または更新する HTTP リクエストヘッダー](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
CloudFront がリクエストを処理してカスタムオリジンサーバーに転送する方法 > [HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
リクエストヘッダーに基づいてキャッシュするように CloudFront を設定する場合、CloudFront が転送するヘッダーを変更するのではなく、CloudFront がヘッダー値に基づいてオブジェクトをキャッシュするかどうかのみを変更します。
+ 多数の一意の値を持つリクエストヘッダーに基づいてキャッシュすることを可能な限り回避する。
例えば、ユーザーのデバイスに基づいてさまざまなサイズのイメージを提供する場合、使用できる値が多数ある `User-Agent` ヘッダーに基づいてキャッシュするように CloudFront を設定しないでください。代わりに、CloudFront デバイスタイプヘッダー `CloudFront-Is-Desktop-Viewer`、`CloudFront-Is-Mobile-Viewer`、`CloudFront-Is-SmartTV-Viewer`、`CloudFront-Is-Tablet-Viewer` に基づいてキャッシュするように CloudFront を設定します。さらに、タブレットとデスクトップに同じバージョンのイメージを返す場合は、`CloudFront-Is-Tablet-Viewer` ヘッダーではなく `CloudFront-Is-Desktop-Viewer` ヘッダーのみを転送します。
詳細については、「[リクエストヘッダーに基づいてコンテンツをキャッシュする](header-caching.md)」を参照してください。
## 圧縮が不要な場合に `Accept-Encoding` ヘッダーを削除する
圧縮が有効になっていない場合 (オリジンがサポートしていないため、CloudFront がサポートしていないため、またはコンテンツが圧縮可能でないため)、Custom Origin Header を以下のように設定するオリジンにディストリビューション内のキャッシュ動作を関連付けることで、キャッシュヒット率を増やすことができます。
+ **ヘッダー名**: `Accept-Encoding`
+ **ヘッダー値**: (空白のままにする)
この設定を使用すると、CloudFront はキャッシュキーから `Accept-Encoding` ヘッダーを削除し、オリジンリクエストにヘッダーを含めません。この設定は、そのオリジンからのディストリビューションに CloudFront が配信するすべてのコンテンツに適用されます。
## HTTP 経由でメディアコンテンツを提供する
ビデオオンデマンド (VOD) およびビデオコンテンツのストリーミングの最適化の詳細については、「[CloudFront を使用したビデオオンデマンドおよびライブストリーミングビデオ](on-demand-streaming-video.md)」を参照してください。
# Amazon CloudFront Origin Shield の使用
CloudFront Origin Shield は、オリジンの負荷を最小限に抑え、可用性を向上させ、運用コストを削減するために役立つ、CloudFront キャッシュインフラストラクチャ内の追加レイヤーです。CloudFront Origin Shield の使用には、次のメリットがあります。
**キャッシュヒット率の向上**
Origin Shield は、オリジンの前に追加のキャッシュレイヤーを提供するため、CloudFront ディストリビューションのキャッシュヒット率を向上させるために役立ちます。Origin Shield を使用すると、CloudFront のすべてのキャッシュレイヤーからオリジンへのすべてのリクエストが Origin Shield を通過し、キャッシュがヒットする可能性が高くなります。CloudFront は、Origin Shield からの 1 つのオリジンリクエストを使用して各オブジェクトを取得できます。CloudFront キャッシュのその他のレイヤー (エッジロケーションと[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) はすべて、Origin Shield からオブジェクトを取得できます。
**オリジンの負荷を軽減**
Origin Shield を使用すると、オリジンに送信される同じオブジェクトへの[同時リクエスト](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes)の数をさらに減らすことができます。Origin Shield のキャッシュにないコンテンツへのリクエストは、同じオブジェクトに対する他のリクエストと統合され、オリジンに送信されるリクエストは 1 件のみになります。オリジンで処理するリクエスト数を減らすと、ピークロード時や想定外のトラフィック急増時にオリジンの可用性が維持され、ジャストインタイムパッケージング、画像変換、データ転送 (DTO) などのコストを削減できます。
**ネットワークパフォーマンスの向上**
[オリジンに対するレイテンシーが最も低い](#choose-origin-shield-region) AWS リージョンで Origin Shield を有効にすることで、最良のネットワークパフォーマンスが得られます。AWS リージョン内のオリジンの場合、CloudFront のネットワークトラフィックは、オリジンに到達するまで高スループットの CloudFront ネットワーク上に留まります。AWS 外のオリジンの場合、CloudFront のネットワークトラフィックは、オリジンへの低レイテンシー接続がある Origin Shield に到達するまで CloudFront ネットワーク上に留まります。
Origin Shield の使用には追加料金が発生します。詳細については、「[CloudFront の料金](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
**注記**
Origin Shield は gRPC リクエストではサポートされていません。gRPC をサポートするディストリビューションで Origin Shield が有効になっている場合、gRPC リクエストは引き続き機能します。ただし、リクエストは Origin Shield を経由せずに gRPC オリジンに直接プロキシされます。詳細については、「[CloudFront ディストリビューションでの gRPC の使用](distribution-using-grpc.md)」を参照してください。
**Topics**
+ [
## Origin Shield のユースケース
](#origin-shield-use-cases)
+ [
## Origin Shield の AWS リージョンを選択する
](#choose-origin-shield-region)
+ [
## オリジンシールドを有効にする
](#enable-origin-shield)
+ [
## Origin Shield のコストの見積もり
](#origin-shield-costs)
+ [
## Origin Shield の高可用性
](#origin-shield-high-availability)
+ [
## Origin Shield と他の CloudFront 機能との連携
](#origin-shield-and-other-features)
## Origin Shield のユースケース
CloudFront Origin Shield は、次のような多くのユースケースで役立ちます。
+ 異なる地理的リージョンにビューワーが分散している場合
+ ライブストリーミングまたはオンザフライ画像処理のために、オリジンがジャストインタイムパッケージを提供する場合
+ オンプレミスのオリジンに、容量または帯域幅の制約がある場合
+ ワークロードが複数のコンテンツ配信ネットワーク (CDN) を使用する場合
Origin Shield は、動的コンテンツがオリジンにプロキシ化される場合、コンテンツのキャッシュ可能性が低い安倍、コンテンツのリクエスト頻度の低い場合など、上記以外の状況には適さないことがあります。
以下のセクションでは、以下のユースケースにおける Origin Shield の利点について説明します。
**Topics**
+ [
### 異なる地理的リージョンにビューワーが分散している場合
](#os-use-cases-global-viewers)
+ [
### 複数の CDN を使用する場合
](#os-use-cases-multi-cdn)
### 異なる地理的リージョンにビューワーが分散している場合
Amazon CloudFront を使用すると、CloudFront がキャッシュを使用して処理できるリクエストはオリジンに送信されないため、オリジンの負荷が軽減されます。CloudFront が提供する[エッジロケーションのグローバルネットワーク](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure)に加え、[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)は中間層のキャッシュレイヤーとして機能します。これにより、地理的に近いリージョンのビューワーにキャッシュヒットが提供され、オリジンリクエストが統合されます。ビューワーリクエストは、まず近くの CloudFront エッジロケーションにルーティングされ、オブジェクトがそのロケーションでキャッシュされていない場合、リクエストはリージョン別エッジキャッシュに送信されます。
ビューワーのリージョンが地理的に異なる場合、リクエストは異なるリージョン別エッジキャッシュを介してルーティングされ、それぞれから同じコンテンツに対するリクエストがオリジンに送信される可能性があります。Origin Shield を使用すると、リージョン別エッジキャッシュとオリジンの間にキャッシュのレイヤーが追加されます。すべてのリージョン別エッジキャッシュからのリクエストはすべて、Origin Shield を通過し、オリジンの負荷をさらに軽減します。次の図にその概念を示します。次の図で、オリジンは AWS Elemental MediaPackage です。
**Origin Shield を使用しない場合**
Origin Shield を使用しない場合は、次の図に示されているように、同じコンテンツに対するリクエストをオリジンが重複して受け取る可能性があります。
![\[CloudFront Origin Shield を使用しない場合、オリジンは重複したリクエストを受け取る可能性があります。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)
**Origin Shield を使用する場合**
Origin Shield を使用すると、次の図に示されているように、オリジンの負荷を軽減できます。
![\[CloudFront オリジンシールドを使用すると、オリジンが受け取る重複リクエストを減らすことができます。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)
### 複数の CDN を使用する場合
ライブビデオイベントや人気のあるオンデマンドコンテンツを配信するには、複数のコンテンツ配信ネットワーク (CDN) を使用することがあります。複数の CDN の使用には利点もありますが、同じコンテンツに対して多数の重複リクエストをオリジンが受け取る可能性があります。それぞれのリクエストは、異なる CDN から送信されることも、同じ CDN 内の異なる場所から送信されることもあります。このような冗長リクエストにより、オリジンの可用性に影響することも、ジャストインタイムパッケージングやインターネットへのデータ転送 (DTO) などのプロセスに追加の運用コストが発生することもあります。
Origin Shield を使用し、他の CDN のオリジンとして CloudFront ディストリビューションを組み合わせると、次のようなメリットがあります。
+ オリジンで受信される冗長リクエストが少なくなるため、複数の CDN を使用した場合の悪影響を軽減できます。
+ CDN 全体で共通の[キャッシュキー](controlling-the-cache-key.md)を使用し、オリジン向けの機能を一元管理できます。
+ ネットワークパフォーマンスの向上。他の CDN からのネットワークトラフィックが近くの CloudFront エッジロケーションで終了し、ローカルキャッシュからのヒットが発生する可能性があります。リクエストされたオブジェクトがエッジロケーションキャッシュ内にない場合、オリジンへのリクエストは Origin Shield までの間 CloudFront ネットワーク上に残り、オリジンへの高いスループットと低レイテンシーを提供します。リクエストされたオブジェクトが Origin Shield のキャッシュ内にある場合、オリジンへのリクエストは完全に回避されます。
**重要**
マルチ CDN アーキテクチャでオリジンシールドを使用し、割引料金を利用する場合は、[[お問い合わせ]](https://aws.amazon.com/contact-us/) または AWS 営業担当者を通じて詳細をご確認ください。追加料金が適用される場合があります。
以下の図は、複数の CDN で人気のあるライブビデオイベントを提供する場合に、この設定がオリジンへの負荷を最小限に抑える方法を示しています。次の図で、オリジンは AWS Elemental MediaPackage です。
**Origin Shield を使用しない場合 (複数の CDN を使用)**
Origin Shield を使用しない場合は、次の図に示されているように、同じコンテンツに対する多数の重複リクエストを (それぞれ異なる CDN から) オリジンが受け取る可能性があります。
![\[オリジンが、それぞれが異なる CDN から着信する重複リクエストをどのように受信できるかを示すグラフィック。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)
**Origin Shield を使用する場合 (複数の CDN を使用)**
Origin Shield を使用し、他の CDN のオリジンとして CloudFront を組み合わせると、次の図に示されているように、オリジンの負荷を軽減できます。
![\[CloudFront Origin Shield が受け取る重複リクエストの数が少ないことを示すグラフィック。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)
## Origin Shield の AWS リージョンを選択する
Amazon CloudFront は、CloudFront の[リージョンエッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)がある AWS リージョンで Origin Shield を提供しています。Origin Shield を有効にするときは、Origin Shield の AWS リージョンを選択します。オリジンに対するレイテンシーが最も低い AWS リージョンを選択するようにしてください。Origin Shieldは、AWS リージョン内にあるオリジンにも、AWS 外のオリジンにも使用できます。
### AWS リージョン内のオリジン
オリジンが AWS リージョンにある場合は、CloudFront が Origin Shield を提供するリージョン内にオリジンがあるかどうかを最初に判断します。CloudFront は、以下の AWS リージョンで Origin Shield を提供しています。
+ 米国東部 (オハイオ) – `us-east-2`
+ 米国東部 (バージニア北部) – `us-east-1`
+ 米国西部 (オレゴン) – `us-west-2`
+ アジアパシフィック (ムンバイ) – `ap-south-1`
+ アジアパシフィック (ソウル) – `ap-northeast-2`
+ アジアパシフィック (シンガポール) – `ap-southeast-1`
+ アジアパシフィック (シドニー) – `ap-southeast-2`
+ アジアパシフィック (東京) – `ap-northeast-1`
+ 欧州 (フランクフルト) – `eu-central-1`
+ 欧州 (アイルランド) – `eu-west-1`
+ 欧州 (ロンドン) – `eu-west-2`
+ 南米 (サンパウロ) – `sa-east-1`
+ 中東 (アラブ首長国連邦) – `me-central-1`
**CloudFront が Origin Shield を提供する AWS リージョンにオリジンがある場合**
CloudFront が Origin Shield を提供する AWS リージョン (上記のリストを参照) にオリジンがある場合は、オリジンと同じリージョンで Origin Shield を有効にします。
**CloudFront が Origin Shield を提供する AWS リージョンにオリジンがない場合**
CloudFront が Origin Shield を提供する AWS リージョンにオリジンがない場合は、以下の表を参照して、Origin Shield を有効にするリージョンを判断します。
| **オリジンの場所** | **Origin Shield を有効にするリージョン** |
| --- | --- |
| 米国西部 (北カリフォルニア) – `us-west-1` | 米国西部 (オレゴン) – `us-west-2` |
| アフリカ (ケープタウン) – `af-south-1` | 欧州 (アイルランド) – `eu-west-1` |
| アジアパシフィック (香港) – `ap-east-1` | アジアパシフィック (シンガポール) – `ap-southeast-1` |
| カナダ (中部) – `ca-central-1` | 米国東部 (バージニア北部) – `us-east-1` |
| 欧州 (ミラノ) – `eu-south-1` | 欧州 (フランクフルト) – `eu-central-1` |
| 欧州 (パリ) – `eu-west-3` | 欧州 (ロンドン) – `eu-west-2` |
| 欧州 (ストックホルム) – `eu-north-1` | 欧州 (ロンドン) – `eu-west-2` |
| 中東 (バーレーン) – `me-south-1` | アジアパシフィック (ムンバイ) – `ap-south-1` |
### オリジンが 外にある場合AWS
Origin Shield は、オンプレミスのオリジン、または AWS リージョン外のオリジンにも使用できます。その場合は、オリジンに対するレイテンシーが最も低い AWS リージョンで Origin Shield を有効にします。オリジンに対するレイテンシーが最も低い AWS リージョンがわからない場合は、以下の提案を参考にして判断することができます。
+ 上記の表を参照し、オリジンの地理的位置に基づいて、オリジンに対するレイテンシーが最も低いと思われる AWS リージョンを見計らいます。
+ オリジンに地理的に近いいくつかの異なる AWS リージョンで Amazon EC2 インスタンスを起動し、`ping` を使用してテストを数回実行して、これらのリージョンとオリジンの間の典型的なネットワークレイテンシーを測定できます。
## オリジンシールドを有効にする
Origin Shield を有効にすると、キャッシュヒット率の向上、オリジンへの負荷の軽減、パフォーマンスの強化を図ることができます。オリジンシールドを有効にするには、CloudFront ディストリビューションのオリジン設定を変更します。Origin Shield は、オリジンのプロパティです。CloudFront ディストリビューションのオリジンごとに、そのオリジンに最適なパフォーマンスを提供する AWS リージョンで Origin Shield を個別に有効化できます。
Origin Shield は、CloudFront コンソール、CloudFormation、または CloudFront API で有効にすることができます。
------
#### [ Console ]
**既存のオリジンに対して Origin Shield を有効にするには (コンソール)**
1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。
1. 更新するオリジンがあるディストリビューションを選択します。
1. [**オリジン**] タブを選択します。
1. 更新するオリジンを選択し、[**編集**] を選択します。
1. [**Origin Shield を有効にする**] で、[**はい**] を選択します。
1. [**Origin Shield Region**] (Origin Shield のリージョン) には、Origin Shield を有効にする AWS リージョンを選択します。リージョンの選択については、「[Origin Shield の AWS リージョンを選択する](#choose-origin-shield-region)」を参照してください。
1. **[Save changes]** (変更の保存) をクリックします。
ディストリビューションのステータスが [**デプロイ済み**] であれば、Origin Shield の準備が完了しています。これには数分かかります。
**新しいオリジンの Origin Shield を有効にするには (コンソール)**
1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。
1. 既存のディストリビューションに新しいオリジンを作成するには、次の操作を行います。
1. オリジンを作成するディストリビューションを選択します。
1. [**オリジンの作成**] を選択し、ステップ 3 に進みます。
新しい標準ディストリビューションに新しいオリジンを作成するには、次の操作を行います。
1. 手順に従って、コンソールで標準ディストリビューションを作成します。詳細については、「[コンソールに CloudFront ディストリビューションを作成する](distribution-web-creating-console.md#create-console-distribution)」を参照してください。
1. **[設定]** セクションで、**[オリジン設定のカスタマイズ]** を選択します。ステップ 3 に進みます。
1. [**Origin Shield を有効にする**] で、[**はい**] を選択します。
1. [**Origin Shield Region**] (Origin Shield のリージョン) には、Origin Shield を有効にする AWS リージョンを選択します。リージョンの選択については、「[Origin Shield の AWS リージョンを選択する](#choose-origin-shield-region)」を参照してください。
1. コンソールの手順に従って、オリジンまたはディストリビューションの作成を完了します。
ディストリビューションのステータスが [**デプロイ済み**] であれば、Origin Shield の準備が完了しています。これには数分かかります。
------
#### [ CloudFormation ]
CloudFormation で Origin Shield を有効にするには、`AWS::CloudFront::Distribution` リソースの `Origin` プロパティタイプに `OriginShield` プロパティを使用します。`OriginShield` プロパティは、既存の `Origin` に追加することも、新しい `Origin` を作成するときに含めることができます。
次の例は、米国西部 (オレゴン) リージョン (`OriginShield`) で `us-west-2` を有効にするための構文を YAML 形式で示しています。リージョンの選択については、「[Origin Shield の AWS リージョンを選択する](#choose-origin-shield-region)」を参照してください。この例では、`Origin` リソース全体ではなく、`AWS::CloudFront::Distribution` プロパティタイプのみを示しています。
```
Origins:
- DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com
Id: Example-EMP-3ae97e9482b0d011
OriginShield:
Enabled: true
OriginShieldRegion: us-west-2
CustomOriginConfig:
OriginProtocolPolicy: match-viewer
OriginSSLProtocols: TLSv1
```
詳細については、*AWS CloudFormation ユーザーガイド*のリソースとプロパティのリファレンスセクションで「[AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html)」を参照してください。
------
#### [ API ]
AWS SDK または AWS Command Line Interface (AWS CLI) を使用して CloudFront API で Origin Shield を有効にするには、`OriginShield` タイプを使用します。`OriginShield` は、`Origin` の `DistributionConfig` 内で指定します。`OriginShield` タイプの詳細については、「*Amazon CloudFront API リファレンス*」の以下の情報を参照してください。
+ [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html) (タイプ)
+ [Origin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (タイプ)
+ [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) (タイプ)
+ [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (オペレーション)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) (オペレーション)
これらのタイプと操作を使用するための具体的な構文は、使用する SDK、CLI、API クライアントによって異なります。詳細については、SDK、CLI、またはクライアントのリファレンスドキュメントを参照してください。
------
## Origin Shield のコストの見積もり
Origin Shield の料金は、増分レイヤーとして Origin Shield に送信されるリクエストの数に基づいて計算されます。
オリジンにプロキシ化される動的 (キャッシュ不可能な) リクエストの場合、Origin Shield は常に増分レイヤーとなります。動的リクエストでは、HTTP メソッド `PUT`、`POST`、`PATCH`、`DELETE` を使用します。
有効期限 (TTL) の設定が 3,600 秒未満の `GET` および `HEAD` リクエストは、動的リクエストと見なされます。また、キャッシュが無効になっている `GET` および `HEAD` リクエストも動的リクエストと見なされます。
動的リクエストに対する Origin Shield の料金を見積もるには、次の式を使用します。
動的リクエストの総数 **x** 10,000 リクエストあたりの Origin Shield 料金 **/** 10,000
HTTP メソッド `GET`、`HEAD`、`OPTIONS` を使用する非動的リクエストの場合、Origin Shield は増分レイヤーになることがあります。Origin Shield を有効にするときは、Origin Shield の AWS リージョンを選択します。Origin Shield と同じリージョン内の[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)に本来送信されるリクエストの場合、Origin Shield は増分レイヤーになりません。このようなリクエストに対しては、Origin Shield の料金が発生しません。Origin Shield とは異なるリージョンのリージョン別エッジキャッシュに送信されてから Origin Shield に送信されるリクエストの場合、Origin Shield は増分レイヤーになります。このようなリクエストに対しては、Origin Shield の料金が発生します。
キャッシュ可能なリクエストに対する Origin Shield の料金を見積もるには、次の式を使用します。
キャッシュ可能なリクエストの総数 **x** (1 – キャッシュヒット率) **x** 異なるリージョンのリージョン別エッジキャッシュから Origin Shield に送信されるリクエストの割合 **x** 10,000 リクエストあたりの Origin Shield 料金 **/** 10,000
Origin Shield の 10,000 リクエストあたりの料金について詳しくは、「[CloudFront の料金](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
## Origin Shield の高可用性
Origin Shield では、CloudFront の[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)を活用します。これらのエッジキャッシュはそれぞれ、少なくとも 3 つの[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)と Amazon EC2 Auto Scaling インスタンスのフリートを使用して、AWS リージョン内に構築されます。CloudFront のロケーションから Origin Shield への接続では、リクエストごとにアクティブなエラー追跡が使用されます。これにより、プライマリ Origin Shield ロケーションが利用できない場合は、リクエストがセカンダリ Origin Shield ロケーションに自動的にルーティングされます。
## Origin Shield と他の CloudFront 機能との連携
以下のセクションでは、Origin Shield と他の CloudFront 機能との連携について説明します。
### Origin Shield と CloudFront ログ記録
Origin Shield がいつリクエストを処理したかを確認するには、以下のいずれかを有効にする必要があります。
+ [CloudFront 標準ログ (アクセスログ)](AccessLogs.md)。標準ログは無料で提供されます。
+ [CloudFront リアルタイムのアクセスログ](real-time-logs.md)。リアルタイムのアクセスログの使用には追加料金が発生します。「[Amazon CloudFront の料金](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
Origin Shield からのキャッシュヒットは、CloudFront ログの `OriginShieldHit` フィールドに `x-edge-detailed-result-type` として表示されます。Origin Shield では、Amazon CloudFront の[リージョン別エッジキャッシュ](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)が活用されます。リクエストが CloudFront エッジロケーションから Origin Shield として機能するリージョン別エッジキャッシュにルーティングされた場合、ログには `Hit` としてではなく `OriginShieldHit` として報告されます。
### Origin Shield とオリジングループ
Origin Shield は [CloudFront オリジングループ](high_availability_origin_failover.md)との互換性があります。Origin Shield はオリジンのプロパティであるため、オリジンがオリジングループの一部であっても、リクエストは常に各オリジンの Origin Shield を通過します。CloudFront はリクエストごとに、プライマリオリジンの Origin Shield を介してリクエストをオリジングループのプライマリオリジンにルーティングします。このリクエストが失敗した場合 (オリジングループのフェイルオーバー基準に従って)、CloudFront はセカンダリオリジンの Origin Shield を介してリクエストをセカンダリオリジンにルーティングします。
### Origin Shield と Lambda@Edge
Origin Shield は [Lambda@Edge](lambda-at-the-edge.md) 関数の機能性には影響しませんが、これらの関数が実行される AWS リージョンに影響を及ぼす可能性があります。
Lambda@Edge と共に Origin Shield を使用する場合、[オリジン向けのトリガー](lambda-cloudfront-trigger-events.md) (オリジンリクエストとオリジンレスポンス) は、Origin Shield が有効になっている AWS リージョンで実行されます。プライマリ Origin Shield ロケーションが利用できないために、CloudFront がリクエストをセカンダリ Origin Shield ロケーションにルーティングする場合、Lambda@Edge オリジン向けのトリガーもセカンダリ Origin Shield ロケーションを使用するようにシフトされます。
ビューワー向けトリガーは影響を受けません。
# CloudFront オリジンフェイルオーバーを使用して高可用性を最適化する
高可用性が必要なシナリオでは、オリジンフェイルオーバーを使用するように CloudFront を設定できます。開始するには、プライマリとセカンダリの 2 つのオリジンを持つ*オリジングループ*を作成します。プライマリオリジンが使用できない場合、または障害を示す特定の HTTP レスポンスステータスコードを返す場合、CloudFront は自動的にセカンダリオリジンに切り替わります。
オリジンフェイルオーバーを設定するには、少なくとも 2 つのオリジンを持つディストリビューションが必要です。次に、1 つをプライマリとして設定した 2 つのオリジンを含むディストリビューションのオリジングループを作成します。最後に、オリジングループを使用するようにキャッシュ動作を作成または更新します。
オリジングループを設定して特定のオリジンフェイルオーバーオプションを設定する手順については、「[オリジングループを作成する](#concept_origin_groups.creating)」を参照してください。
キャッシュ動作のオリジンフェイルオーバーを設定すると、CloudFront は、ビューワーリクエストに対して以下の処理を実行します。
+ キャッシュヒットがあると、CloudFront はリクエストされたオブジェクトを返します。
+ キャッシュミスがあると、CloudFront はオリジングループのプライマリオリジンにリクエストをルーティングします。
+ プライマリオリジンがフェイルオーバー用に設定されていないステータスコード (HTTP 2xx や 3xx ステータスコードなど) を返すと、CloudFront はリクエストされたオブジェクトをビューワーに配信します。
+ 次のいずれかに該当する場合:
+ プライマリオリジンは、フェイルオーバー用に設定した HTTP ステータスコードを返す
+ CloudFront がプライマリオリジンに接続できない (503 がフェイルオーバーコードとして設定されている場合)
+ プライマリオリジンからのレスポンスに時間がかかりすぎる (タイムアウト) (504 がフェイルオーバーコードとして設定されている場合)
この場合、CloudFront はオリジングループ内のセカンダリオリジンにリクエストをルーティングします。
**注記**
ビデオコンテンツのストリーミングなど、ユースケースによっては、CloudFront をセカンダリオリジンにすばやくフェイルオーバーすることが必要になる場合があります。CloudFront がセカンダリオリジンにフェイルオーバーするのにかかる時間を調整するには、「[オリジンのタイムアウトと試行を制御する](#controlling-attempts-and-timeouts)」を参照してください。
CloudFront は、前のリクエストをセカンダリオリジンにフェイルオーバーした場合でも、すべての受信リクエストをプライマリオリジンにルーティングします。CloudFront は、プライマリオリジンへのリクエストが失敗した後にのみセカンダリオリジンにリクエストを送信します。
CloudFront は、ビューワーリクエストの HTTP メソッドが `GET`、`HEAD`、または `OPTIONS` の場合にのみ、セカンダリオリジンにフェイルオーバーします。ビューワーが別の HTTP メソッド (たとえば `POST` や `PUT` など) を送信しても、CloudFront はフェイルオーバーしません。
**注記**
キャッシュ動作で `OPTIONS` が [キャッシュされる HTTP メソッド](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) として設定されていない場合、CloudFront はフェイルオーバーしません。
以下の図は、オリジンフェイルオーバーのしくみを示しています。
![\[オリジンフェイルオーバーのしくみ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)
**Topics**
+ [
## オリジングループを作成する
](#concept_origin_groups.creating)
+ [
## オリジンのタイムアウトと試行を制御する
](#controlling-attempts-and-timeouts)
+ [
## Lambda@Edge 関数でのオリジンフェイルオーバーの使用
](#concept_origin_groups.lambda)
+ [
## オリジンフェイルオーバーでのカスタムエラーページの使用
](#concept_origin_groups.custom-error)
## オリジングループを作成する
**オリジングループを作成するには**
1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。
1. オリジングループを作成するディストリビューションを選択します。
1. [**オリジン**] タブを選択します。
1. ディストリビューションに複数のオリジンがあることを確認します。そうでない場合は、2 番目のオリジンを追加します。
1. [**Origin groups**] (オリジンのグループ) ペインの [**Origins**] (オリジン) タブで、[**Create Origin group**] (オリジングループの作成) を選択します。
1. オリジングループのオリジンを選択します。オリジンを追加したら、矢印を使用して優先度 (つまり、どのオリジンがプライマリで、どのオリジンがセカンダリであるか) を設定します。
1. オリジングループの名前を入力します。
1. フェイルオーバー基準として使用する HTTP ステータスコードを選択します。次のステータスコードを任意に組み合わせて選択できます。400、403、404、416、500、502、503、または 504。CloudFront は、指定したステータスコードの 1 つを含むレスポンスを受信すると、セカンダリオリジンにフェイルオーバーします。
**注記**
CloudFront は、ビューワーリクエストの HTTP メソッドが `GET`、`HEAD`、または `OPTIONS` の場合にのみ、セカンダリオリジンにフェイルオーバーします。ビューワーが別の HTTP メソッド (たとえば `POST` や `PUT` など) を送信しても、CloudFront はフェイルオーバーしません。
1. **[オリジン選択基準]** で、ディストリビューションがビューワーリクエストをルーティングするときにオリジンを選択する方法を指定します。以下のオプションを選択できます。
**デフォルト**
CloudFront は、**[設定]** ページで指定したデフォルトのオリジン優先度を使用します。
**メディア品質スコア**
CloudFront は、このスコアを追跡して使用し、リクエストを転送する先の最初のオリジンを決定します。これにより、CloudFront がオリジングループの代替オリジンに非同期 `HEAD` リクエストを行い、メディア品質スコアを決定することも許可します。このオプションは、AWS Elemental MediaPackage v2 のオリジンでのみ選択できます。詳細については、「[Media Quality-Aware Resiliency](media-quality-score.md)」を参照してください。
1. [**Create origin group**] (オリジングループの作成) を選択します。
ディストリビューションのキャッシュ動作のオリジンとしてオリジングループを割り当ててください。詳細については、「[名前](DownloadDistValuesOrigin.md#DownloadDistValuesId)」を参照してください。
## オリジンのタイムアウトと試行を制御する
デフォルトでは、CloudFront は、セカンダリオリジンにフェイルオーバーする前に 30 秒間 (それぞれ 10 秒間の接続試行が 3 回)、オリジングループ内のプライマリオリジンへの接続を試行します。ビデオコンテンツのストリーミングなど、ユースケースによっては、CloudFront をセカンダリオリジンに、さらにすばやくフェイルオーバーすることが必要になる場合があります。以下の設定を調整して、CloudFront がセカンダリオリジンにフェイルオーバーするのにかかる時間を変更できます。オリジンがセカンダリオリジンであるか、オリジングループの一部ではないオリジンである場合、これらの設定は、CloudFront が HTTP 504 レスポンスをビューワーに返す速度に影響します。
よりすばやくフェイルオーバーするには、接続タイムアウトを短くするか、接続試行回数を減らすか、またはその両方を行います。カスタムオリジン (静的ウェブサイトホスティングで*設定されている* Amazon S3 バケットオリジンを含む) の場合、オリジン応答タイムアウトを調整することもできます。
**オリジン接続タイムアウト**
オリジン接続タイムアウト設定は、オリジンへの接続を確立しようとしたときに CloudFront が待機する時間に影響します。デフォルトでは、CloudFront は接続の確立まで 10 秒待機しますが、1 ～ 10 秒 (両端の値を含む) を指定できます。詳細については、「[接続タイムアウト](DownloadDistValuesOrigin.md#origin-connection-timeout)」を参照してください。
**オリジン接続の試行**
オリジン接続試行の設定は、CloudFront がオリジンへの接続を試行する回数に影響します。デフォルトでは、CloudFront は 3 回接続を試行しますが、1 ～ 3 (両端の値を含む) を指定できます。詳細については、「[接続の試行](DownloadDistValuesOrigin.md#origin-connection-attempts)」を参照してください。
カスタムオリジン (静的ウェブサイトホスティングで設定された Amazon S3 バケットを含む) では、この設定は、オリジン応答タイムアウトの場合に CloudFront がオリジンから応答を取得しようとする回数にも影響します。
**オリジン応答タイムアウト**
オリジン応答タイムアウト (オリジンリードタイムアウトとも呼ばれる) は、CloudFront がオリジンからの応答を受信する (または完全な応答を受信する) まで待機する時間に影響します。デフォルトでは、CloudFront は 30 秒間待機しますが、1～120 秒 (両端の値を含む) を指定できます。詳細については、「[応答タイムアウト](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)」を参照してください。
### これらの設定を変更する方法
**[CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v4/home)でこれらの設定を変更するには**
+ 新しいオリジンまたは新しいディストリビューションの場合、リソースの作成時にこれらの値を指定します。
+ 既存のディストリビューションの既存のオリジンについては、オリジンを編集するときにこれらの値を指定します。
詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」を参照してください。
## Lambda@Edge 関数でのオリジンフェイルオーバーの使用
Lambda@Edge 関数は、オリジングループで設定した CloudFront ディストリビューションで使用できます。Lambda 関数を使用するには、キャッシュ動作を作成するときにオリジングループの[オリジンリクエストまたはオリジンレスポンストリガー](lambda-cloudfront-trigger-events.md)で指定します。オリジングループで Lambda@Edge 関数を使用すると、1 つのビューワーリクエストに対して、この関数を 2 回トリガーできます。たとえば、次のシナリオが考えられます。
1. オリジンリクエストトリガーを使用して Lambda@Edge 関数を作成します。
1. Lambda 関数は、(キャッシュミス時に) プライマリオリジンに CloudFront がリクエストを送信したときに 1 回トリガーされます。
1. プライマリオリジンは、フェイルオーバー用に設定された HTTP ステータスコードで応答します。
1. CloudFront がセカンダリオリジンに同じリクエストを送信すると、Lambda 関数が再度トリガーされます。
次の図は、オリジンリクエストまたはレスポンストリガーに Lambda@Edge 関数を含める場合、オリジンフェイルオーバーがどのように機能するかを示しています。
![\[Lambda@Edge 関数でのオリジンフェイルオーバーの機能\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)
Lambda@Edge トリガーの使用の詳細については、「[Lambda@Edge 関数のトリガーを追加する](lambda-edge-add-triggers.md)」を参照してください。
DNS フェイルオーバーの管理の詳細については、「Amazon Route 53 デベロッパーガイド」の「[DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)」を参照してください。**
## オリジンフェイルオーバーでのカスタムエラーページの使用
オリジンフェイルオーバー用に設定されていないオリジンでそれらを使用する方法と同様に、オリジングループでカスタムエラーページを使用できます。
オリジンフェイルオーバーを使用すると、プライマリまたはセカンダリオリジン (またはその両方) のカスタムエラーページを返すように CloudFront を設定できます。
+ **プライマリオリジンのカスタムエラーページを返す** - プライマリオリジンが、フェイルオーバー用に設定されていない HTTP ステータスコードを返す場合、CloudFront はカスタムエラーページをビューワーに返します。
+ **セカンダリオリジンのカスタムエラーページを返す** - CloudFront がセカンダリオリジンからエラーステータスコードを受け取った場合、CloudFront はカスタムエラーページを返します。
CloudFront でカスタムエラーページを使用する方法の詳細については、「[カスタムエラーレスポンスを生成する](GeneratingCustomErrorResponses.md)」を参照してください。
# コンテンツをキャッシュに保持する期間 (有効期限) を管理する
CloudFront が別のリクエストをオリジンに転送するまでにファイルを CloudFront キャッシュに保持する期間を制御できます。この期間を短くすると、動的なコンテンツを供給できます。この期間を長くすると、ユーザー側のパフォーマンスは向上します。ファイルがエッジキャッシュから直接返される可能性が高くなるためです。期間を長くすると、オリジンの負荷も軽減されます。
一般的に CloudFront は、指定したキャッシュ保持期間が経過するまで、つまりファイルの有効期限が切れるまでエッジロケーションからファイルを提供します。ファイルの有効期限が切れると、エッジロケーションがファイルのリクエストを次に受け取ったときに、CloudFront は、リクエストをオリジンに転送し、キャッシュにファイルの最新バージョンが含まれていることを確認します。オリジンからのレスポンスは、ファイルが変更されたかどうかによって異なります。
+ CloudFront キャッシュに最新バージョンがすでにある場合、オリジンはステータスコード `304 Not Modified` を返します。
+ CloudFront キャッシュに最新バージョンがない場合、オリジンはステータスコード `200 OK` とファイルの最新バージョンを返します。
エッジロケーションに頻繁にリクエストされないファイルがあれば、CloudFront は、頻繁にリクエストされるようになったファイル用にスペースを確保するために、そのファイルを削除する (そのファイルの有効期限が切れる前に削除する) 場合があります。
ディストリビューションのキャッシュポリシーを更新して、キャッシュ期間を管理することをお勧めします。キャッシュポリシーの使用をオプトアウトした場合、デフォルトの TTL (有効期限) は 24 時間ですが、次の設定を更新してデフォルトを上書きできます。
+ 同じパスパターンに一致するすべてのファイルのキャッシュ保持期間を変更するには、CloudFront の設定でキャッシュの動作の [**Minimum TTL (最小 TTL)**]、[**Maximum TTL (最大 TTL)**]、[**Default TTL (デフォルト TTL)**] を変更できます。個々の設定の詳細については、「[最小 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)」、「[最大 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL)」、「[デフォルト TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL)」を参照してください。
+ 個々のファイルのキャッシュ保持期間を変更するには、ファイルに `Cache-Control` または `max-age` ディレクティブが付いた `s-maxage` を追加するか、`Expires` ヘッダーフィールドを追加するようにオリジンを設定します。詳細については、「[ヘッダーを使用して個々のオブジェクトのキャッシュ保持期間を制御する](#expiration-individual-objects)」を参照してください。
[**Minimum TTL (最小 TTL)**]、[**Default TTL (デフォルト TTL)**]、[**Maximum TTL (最大 TTL)**] が `max-age` ディレクティブ、`s-maxage` ディレクティブ、`Expires` ヘッダーフィールドとどのように連動するかの詳細については、「[CloudFront がオブジェクトをキャッシュする期間を指定する](#ExpirationDownloadDist)」を参照してください。
CloudFront がオリジンに別のリクエストを転送して、リクエストされたオブジェクトを再度取得することを試みるまでに、エラー (`404 Not Found` など) が CloudFront キャッシュに保持される期間を制御することもできます。詳細については、「[CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理する方法](HTTPStatusCodes.md)」を参照してください。
**Topics**
+ [
## ヘッダーを使用して個々のオブジェクトのキャッシュ保持期間を制御する
](#expiration-individual-objects)
+ [
## 古い (期限切れの) コンテンツを提供する
](#stale-content)
+ [
## CloudFront がオブジェクトをキャッシュする期間を指定する
](#ExpirationDownloadDist)
+ [
## Amazon S3 コンソールを使用してオブジェクトにヘッダーを追加する
](#ExpirationAddingHeadersInS3)
## ヘッダーを使用して個々のオブジェクトのキャッシュ保持期間を制御する
`Cache-Control` および `Expires` ヘッダーを使用して、オブジェクトをキャッシュに保持する期間を制御できます。[**Minimum TTL**]、[**Default TTL**]、[**Maximum TTL**] の設定もキャッシュ保持期間に影響を与えますが、ここでは、ヘッダーがキャッシュ保持期間に与える影響について概要を示します。
+ `Cache-Control max-age` ディレクティブでは、CloudFront がオリジンサーバーからオブジェクトを再度取得するまでにオブジェクトをキャッシュに保持する期間 (秒単位) を指定できます。CloudFront がサポートする最小有効期限は 0 秒です。最大値は 100 (年) です。値は次の形式で指定します。
`Cache-Control: max-age=`*秒*
例えば、以下のディレクティブは CloudFront に関連付けられているオブジェクトを 3,600 秒 (1 時間) キャッシュに保持するよう指示します。
`Cache-Control: max-age=3600`
ブラウザキャッシュに保持される期間とは異なる期間、オブジェクトを CloudFront エッジキャッシュに保持する場合、`Cache-Control max-age` ディレクティブと `Cache-Control s-maxage` ディレクティブを併用できます。詳細については、「[CloudFront がオブジェクトをキャッシュする期間を指定する](#ExpirationDownloadDist)」を参照してください。
+ `Expires` ヘッダーフィールドでは、「[RFC 2616、ハイパーテキスト転送プロトコル –– HTTP/1.1 セクション 3.3.1、完全な日付](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1)」に規定された形式を使用して、有効期限切れ日時を指定できます。
`Sat, 27 Jun 2015 23:59:59 GMT`
オブジェクトのキャッシュを制御するには、`Expires` ヘッダーフィールドではなく、`Cache-Control max-age` ディレクティブを使用することをお勧めします。`Cache-Control max-age` と `Expires` の両方の値を指定した場合、CloudFront は `Cache-Control max-age` の値のみを使用します。
詳細については、「[CloudFront がオブジェクトをキャッシュする期間を指定する](#ExpirationDownloadDist)」を参照してください。
ビューワーからの `Cache-Control` リクエストで HTTP `Pragma` または `GET` ヘッダーフィールドを使用して、オリジンサーバーに戻ってオブジェクトを取得するように CloudFront を設定することはできません。CloudFront は、ビューワーからのリクエストにあるそのようなヘッダーフィールドを無視します。
`Cache-Control` および `Expires` ヘッダーフィールドの詳細については、「*RFC 2616、ハイパーテキスト転送プロトコル –– HTTP/1.1*」の以下のセクションを参照してください。
+ [セクション 14.9 キャッシュ制御](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [セクション 14.21 期限](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)
## 古い (期限切れの) コンテンツを提供する
CloudFront は `Stale-While-Revalidate` および `Stale-If-Error` キャッシュ制御ディレクティブをサポートしています。これらのディレクティブを使用して、ビューワーが古いコンテンツを利用できる期間を指定できます。
**Topics**
+ [
### `Stale-While-Revalidate`
](#stale-while-revalidate)
+ [
### `Stale-If-Error`
](#stale-if-error-only)
+ [
### 両方のディレクティブを使用する
](#use-both-stale-directives)
### `Stale-While-Revalidate`
このディレクティブにより、CloudFront はオリジンから新しいバージョンを非同期で取得しながら、キャッシュから古いコンテンツを提供できます。これにより、ビューワーはバックグラウンドフェッチを待たずにエッジロケーションからレスポンスをすぐに受け取るため、レイテンシーが向上します。新しいコンテンツは、今後のリクエストのためにバックグラウンドでロードされます。
**Example 例:`Stale-While-Revalidate`**
CloudFront は、これらのディレクティブを使用するように `Cache-Control` ヘッダーを設定するときに、以下を実行します。
```
Cache-Control: max-age=3600, stale-while-revalidate=600
```
1. CloudFront はレスポンスを 1 時間キャッシュします (`max-age=3600`)。
1. この期間を過ぎてリクエストが行われた場合、CloudFront は古いコンテンツを提供すると同時に、キャッシュされたコンテンツを再検証して更新するリクエストをオリジンに送信します。
1. コンテンツが再検証される間、CloudFront は、古いコンテンツは最大 10 分間 (`stale-while-revalidate=600`) 提供します。
**注記**
CloudFront は、`stale-while-revalidate` ディレクティブの値または CloudFront [最大 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 値のどちらか小さい方の値まで、古いコンテンツを提供します。最大 TTL 期間が経過すると、`stale-while-revalidate` の値に関係なく、古いオブジェクトはエッジキャッシュから使用できなくなります。
### `Stale-If-Error`
オリジンにアクセスできない場合やエラーコード 500～600 が返された場合、このディレクティブにより、CloudFront はキャッシュから古いコンテンツを提供できます。これにより、ビューワーはオリジンが停止しているときでもコンテンツにアクセスできるようになります。
**Example 例:`Stale-If-Error`**
CloudFront は、これらのディレクティブを使用するように `Cache-Control` ヘッダーを設定するときに、以下を実行します。
```
Cache-Control: max-age=3600, stale-if-error=86400
```
1. CloudFront はレスポンスを 1 時間キャッシュします (`max-age=3600`)。
1. この期間を過ぎてもオリジンがダウンしたり、エラーが返されたりした場合、CloudFront は最長 24 時間 (`stale-if-error=86400`)、古いコンテンツを提供し続けます。
1. カスタムエラーレスポンスが設定されると、指定された `stale-if-error` 期間内にエラーが発生した場合、CloudFront はまず古いコンテンツの提供を試みます。古いコンテンツが利用できない場合、CloudFront は対応するエラーステータスコードに設定されたカスタムエラーレスポンスを提供します。詳細については、「[カスタムエラーレスポンスを生成する](GeneratingCustomErrorResponses.md)」を参照してください。
**注意事項**
CloudFront は、`stale-if-error` ディレクティブの値または CloudFront [最大 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 値のどちらか小さい方の値まで、古いコンテンツを提供します。最大 TTL 期間が経過すると、`stale-if-error` の値に関係なく、古いオブジェクトはエッジキャッシュから使用できなくなります。
`stale-if-error` またはカスタムエラーレスポンスを設定しない場合、CloudFront はリクエストされたオブジェクトがエッジキャッシュにあるかどうかに応じて、古いオブジェクトを返すか、エラーレスポンスをビューワーに転送します。詳細については、「[カスタムエラーページが設定されていない場合に CloudFront がエラーを処理する方法](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages)」を参照してください。
### 両方のディレクティブを使用する
`stale-while-revalidate` および `stale-if-error` は独立したキャッシュ制御ディレクティブで、これらを一緒に使用することでレイテンシーを減らしたり、オリジンが応答または回復するためのバッファを追加したりできます。
**Example 例: 両方のディレクティブの使用**
CloudFront は、以下のディレクティブを使用するように `Cache-Control` ヘッダーを設定するときに、以下を実行します。
```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```
1. CloudFront はレスポンスを 1 時間キャッシュします (`max-age=3600`)。
1. この期間を過ぎてからリクエストが行われた場合、コンテンツが再検証される間、CloudFront は古いコンテンツを最大 10 分間 (`stale-while-revalidate=600`) 提供します。
1. CloudFront がコンテンツを再検証しようとしたときにオリジンサーバーがエラーを返した場合、CloudFront は古いコンテンツを最大 24 時間 (`stale-if-error=86400`) 提供し続けます。
キャッシュによって、パフォーマンスと鮮度が保たれます。`stale-while-revalidate` や `stale-if-error` などのディレクティブを使用すると、パフォーマンスとユーザーエクスペリエンスが向上しますが、コンテンツをどれだけ新鮮にするかの希望に合った設定にしてください。古いコンテンツディレクティブは、コンテンツを更新する必要があるが、最新バージョンであることが重要でない場合に最適です。さらに、コンテンツが変更されないか、ほとんど変更されない場合、`stale-while-revalidate` は不要なネットワークリクエストを追加する可能性があります。代わりに、キャッシュ期間を長く設定することを検討してください。
## CloudFront がオブジェクトをキャッシュする期間を指定する
CloudFront が、オリジンに別のリクエストを送信するまでの期間に オブジェクトをキャッシュに保持する時間の長さを制御するには、次の方法があります。
+ CloudFront ディストリビューションのキャッシュ動作の TTL 値に、最小、最大、およびデフォルトの値を設定します。これらの値は、キャッシュ動作にアタッチされた[キャッシュポリシー](controlling-the-cache-key.md) (推奨) の中、またはレガシーキャッシュ設定の中で設定できます。
+ オリジンからの応答に `Cache-Control` または `Expires` ヘッダーを含めます。これらのヘッダーは、別のリクエストがブラウザから CloudFront に送信されるまでの期間に、オブジェクトがブラウザーキャッシュに保持される時間を定義するためにも役立ちます。
次の表では、オリジンから送信された `Cache-Control` ヘッダーと `Expires` ヘッダーがキャッシュ動作の TTL 設定とどのように関係し、キャッシュに影響を与えるのかを説明しています。
****
| オリジンヘッダー | 最小 TTL = 0 | 最小 TTL > 0 |
| --- | --- | --- |
| **オリジンが `Cache-Control: max-age` ディレクティブをオブジェクトに追加** | **CloudFront キャッシュ** CloudFront は、`Cache-Control: max-age` ディレクティブの値と最大 TTL の値のうち、小さい方の値に対応する期間、オブジェクトをキャッシュに保持します。 **ブラウザキャッシュ** ブラウザは、`Cache-Control: max-age` ディレクティブの値に対応する期間、オブジェクトをキャッシュに保持します。 | **CloudFront キャッシュ** CloudFront のキャッシュ動作は、CloudFront 最小 TTL および最大 TTL、`Cache-Control max-age` ディレクティブの値によって異なります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **ブラウザキャッシュ** ブラウザは、`Cache-Control: max-age` ディレクティブの値に対応する期間、オブジェクトをキャッシュに保持します。 |
| **オリジンが `Cache-Control: max-age` ディレクティブをオブジェクトに追加しない** | **CloudFront キャッシュ** CloudFront は、デフォルト TTL の値に対応する期間、オブジェクトをキャッシュに保持します。 **ブラウザキャッシュ** ブラウザによって異なります。 | **CloudFront キャッシュ** CloudFront は、最小 TTL またはデフォルト TTL の値のうち、大きい方の値に対応する期間、オブジェクトをキャッシュに保持します。 **ブラウザキャッシュ** ブラウザによって異なります。 |
| **オリジンが `Cache-Control: max-age` および `Cache-Control: s-maxage` ディレクティブをオブジェクトに追加** | **CloudFront キャッシュ** CloudFront は、`Cache-Control: s-maxage` ディレクティブの値と最大 TTL の値のうち、小さい方の値に対応する期間、オブジェクトをキャッシュに保持します。 **ブラウザキャッシュ** ブラウザは、`Cache-Control max-age` ディレクティブの値に対応する期間、オブジェクトをキャッシュに保持します。 | **CloudFront キャッシュ** CloudFront のキャッシュ動作は、CloudFront 最小 TTL および最大 TTL、`Cache-Control: s-maxage` ディレクティブの値によって異なります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **ブラウザキャッシュ** ブラウザは、`Cache-Control: max-age` ディレクティブの値に対応する期間、オブジェクトをキャッシュに保持します。 |
| **オリジンが `Expires` ヘッダーをオブジェクトに追加** | **CloudFront キャッシュ** CloudFront は、`Expires` ヘッダーにある日付と最大 TTL の値に対応する日付のうち早い方の日付まで、オブジェクトをキャッシュに保持します。 **ブラウザキャッシュ** ブラウザは、`Expires` ヘッダーにある日付まで、オブジェクトをキャッシュに保持します。 | **CloudFront キャッシュ** CloudFront キャッシュは、CloudFront 最小 TTL および最大 TTL、`Expires` ヘッダーの値によって異なります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **ブラウザキャッシュ** ブラウザは、`Expires` ヘッダーの日付けおよび時刻まで、オブジェクトをキャッシュに保持します。 |
| **オリジンが `Cache-Control: no-cache`、`no-store`、および (または) `private` ディレクティブをオブジェクトに追加** | CloudFront とブラウザはヘッダーを優先させます。 | **CloudFront キャッシュ** CloudFront は、最小 TTL の値に対応する期間、オブジェクトをキャッシュに保持します。[この表の下にある注意点をお読みください](#stale-if-error)。 **ブラウザキャッシュ** ブラウザはヘッダーを優先します。 |
**警告**
最小 TTL が 0 より大きい場合は、`Cache-Control: no-cache`、`no-store`、`private` ディレクティブがオリジンヘッダーに含まれていても、CloudFront はキャッシュポリシーの最小 TTL を使用します。
オリジンとの接続が可能な場合、CloudFront はオリジンからオブジェクトを取得し、ビューワーに返します。
オリジンが接続不能で、最小または最大 TTL 値が 0 より大きい場合、CloudFront は、以前にオリジンから取得したオブジェクトを返します。**
この動作を回避するには、`Cache-Control: stale-if-error=0` ディレクティブに、オリジンから返されたオブジェクトを含めます。このようにすることで、オリジンが接続不能な場合に CloudFront が以後のリクエストに応答する際、以前にオリジンから取得したオブジェクトを返すのではなくエラーを返すようになります。
オリジンヘッダーに `Cache-Control: no-cache`、`no-store`、および/または `private` ディレクティブが含まれている場合、CloudFront は S3 オリジンから HTTP 501 ステータスコード (未実装) をキャッシュしません。これは、[最小 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) 設定が 0 より大きい場合でも、S3 オリジンのデフォルトの動作です。
CloudFront コンソールを使用して、ディストリビューションの設定を変更する方法については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。CloudFront API を使用してディストリビューションの設定を変更する方法については、「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
## Amazon S3 コンソールを使用してオブジェクトにヘッダーを追加する
`Cache-Control` または `Expires` ヘッダーフィールドを Amazon S3 オブジェクトに追加できます。そのために、オブジェクトのメタデータフィールドを変更します。
**Amazon S3 オブジェクトに `Cache-Control` または `Expires` ヘッダーフィールドを追加するには**
1. 「*Amazon S3 ユーザーガイド*」の「[Amazon S3 コンソールでのオブジェクトメタデータの編集](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html)」トピックの「**システム定義メタデータの置き換え**」セクションの手順に従います。
1. [**Key**] (キー) で、追加するヘッダーの名前 ([**Cache-Control**] または [**Expires**]) を選択します。
1. [**Value**] (値) で、ヘッダー値を入力します。例えば、`Cache-Control` ヘッダーの場合は、`max-age=86400` と入力します。`Expires` で、有効期限の日時を `Wed, 30 Jun 2021 09:28:00 GMT` のように入力できます。
1. 残りの手順に従って、メタデータの変更を保存します。
# クエリ文字列パラメータに基づいてコンテンツをキャッシュする
ウェブアプリケーションによっては、クエリ文字列を使用してオリジンに情報を送信します。クエリ文字列はウェブリクエストの一部で、`?` 文字の後に追加されます。この文字列には `&` 文字で区切られたパラメータを 1 つ以上含めることができます。次の例では、クエリ文字列には 2 つのパラメータ (*color=red* と *size=large*) が含まれています。
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
ディストリビューションでは、CloudFront がクエリ文字列をオリジンに転送するかどうかと、すべてのパラメータまたは一部のパラメータのどちらに基づいてコンテンツをキャッシュするかを選択できます。これが役立つ場合があるのはなぜですか。次の の例を考えます。
たとえば、ウェブサイトが 5 種類の言語で使用でき、ディレクトリ構造とファイル名はウェブサイトの 5 つのバージョンすべてで共通だとします。ユーザーがウェブサイトを表示すると、CloudFront に転送されるリクエストには、ユーザーが選択した言語に基づく言語によるクエリ文字列が含められます。また、クエリ文字列をオリジンに転送し、言語パラメータに基づいてキャッシュするよう CloudFront を設定できます。選択された言語に対応する特定バージョンのページを返すようウェブサーバーを設定した場合、CloudFront は、それぞれの言語によるクエリ文字列パラメータに基づく各言語のバージョンを個別にキャッシュします。
この例では、ウェブサイトのメインページが `main.html` であり、以下の 5 つのリクエストが実行されると、CloudFront は、各言語のクエリ文字列パラメータをそれぞれの値として `main.html` を 5 回キャッシュします。
+ `https://d111111abcdef8.cloudfront.net/main.html?language=de`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=en`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=es`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=fr`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=jp`
次の点に注意してください。
+ 一部の HTTP サーバーはクエリ文字列パラメータを処理しません。このため、パラメータ値に基づくオブジェクトの別バージョンを返しません。これらのオリジンに対して、クエリ文字列パラメータをオリジンに転送するように CloudFront を設定している場合、オリジンがパラメータ値ごとに同じバージョンのオブジェクトを CloudFront に返したとしても、CloudFront は引き続きパラメータ値に基づくキャッシュを実行します。
+ 上記の例で説明したようにクエリ文字列パラメータを言語で使用するには、クエリ文字列パラメータ間の区切り文字として `&` 文字を使用する必要があります。別の区切り文字を使用した場合、キャッシュは、キャッシュ条件として CloudFront で指定するパラメータと、それらのパラメータがクエリ文字列に記述される順序の影響を受けて、予期しない結果が生じる場合があります。
以下の例では、`color` パラメータだけに基づいてキャッシュするよう、異なる区切り記号を使用して CloudFront を設定した場合にどのようになるかを示しています。
+ 以下のリクエストでは、CloudFront は `color` パラメータの値に基づいてコンテンツをキャッシュしますが、この値を *red;size=large* と解釈します。
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
+ 以下のリクエストでは、CloudFront はコンテンツをキャッシュしますが、実行されるキャッシュは、クエリ文字列パラメータに基づくものではありません。これは、`color` パラメータに基づいてキャッシュするよう CloudFront が設定されているが、CloudFront は以下の文字列に `size` パラメータ (値は *large;color=red*) のみが含まれていると解釈するためです。
`https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`
次のいずれかを実行するよう CloudFront を設定できます。
+ クエリ文字列をオリジンにまったく転送しない。クエリ文字列を転送しない場合、CloudFront はクエリ文字列パラメータに基づくキャッシュを実行しません。
+ クエリ文字列をオリジンに転送し、クエリ文字列内のすべてのパラメータに基づいてキャッシュする。
+ クエリ文字列をオリジンに転送し、クエリ文字列内の指定したパラメータに基づいてキャッシュする。
詳細については、「[キャッシュを最適化する](#query-string-parameters-optimizing-caching)」を参照してください。
**Topics**
+ [
## クエリ文字列の転送とキャッシュのためのコンソールおよび API の設定
](#query-string-parameters-console)
+ [
## キャッシュを最適化する
](#query-string-parameters-optimizing-caching)
+ [
## クエリ文字列パラメータと CloudFront 標準ログ (アクセスログ)
](#query-string-parameters-access-logs)
## クエリ文字列の転送とキャッシュのためのコンソールおよび API の設定
CloudFront コンソールでディストリビューションを作成すると、CloudFront はオリジンタイプに基づいてクエリ文字列の転送とキャッシュを設定します。必要に応じて、これらの設定を手動で編集できます。詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の次の設定を参照してください。
+ [クエリ文字列の転送とキャッシュ](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [クエリ文字列の許可リスト](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)
CloudFront API でクエリ文字列の転送とキャッシュを設定するには、「Amazon CloudFront API リファレンス」の「[CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html)」と「[OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html)」を参照してください。**
## キャッシュを最適化する
クエリ文字列パラメータに基づいてキャッシュするように CloudFront を設定する場合、以下の手順を実行して、CloudFront がオリジンに転送するリクエストの数を減らすことができます。CloudFront エッジロケーションがオブジェクトを提供する場合、オリジンサーバーの負荷が軽減され、レイテンシーが減少します。これは、オブジェクトがユーザーに近い場所から提供されるためです。
**オリジンが返すオブジェクトのバージョンが変わるパラメータだけに基づいてキャッシュする**
CloudFront は、ウェブアプリケーションが CloudFront に転送する各クエリ文字列パラメータに対して、すべてのパラメータ値についてオリジンにリクエストを転送し、すべてのパラメータ値について異なるバージョンのオブジェクトをキャッシュします。これは、オリジンがパラメータの値に関係なく常に同じオブジェクトを返す場合も当てはまります。パラメータが複数ある場合、リクエスト数とオブジェクトの数は乗算されます。
このため、オリジンが返すバージョンが変化するようなクエリ文字列パラメータだけに基づいてキャッシュするよう CloudFront を設定し、各パラメータに基づいてキャッシュするメリットを慎重に検討することをお勧めします。たとえば、ある通販ウェブサイトを運営していて、ジャケットの写真が色違いで 6 つあり、ジャケットのサイズは 10 種類だとします。また、ジャケットの写真は色違いだけが表示され、サイズ違いの分までは表示されていないものとします。この場合にキャッシュを最適化するには、サイズのパラメータではなく、色のパラメータだけに基づいてキャッシュするよう CloudFront を設定する必要があります。これにより、CloudFront がキャッシュからリクエストを処理できる可能性が高くなり、パフォーマンスが向上し、オリジンの負荷が低下します。
**パラメータの順序を常に統一する**
クエリ文字列では、パラメータの順序が重要になります。次の例は、パラメータの順序だけが異なる同じクエリ文字列です。この場合 CloudFront は、image.jpg に対する 2 つの異なるリクエストをオリジンに転送し、2 つの異なるバージョンのオブジェクトをキャッシュします。
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
このため、パラメータ名は、常に同じ順序 (アルファベット順など) にすることをお勧めします。
**パラメータ名とパラメータ値の大文字と小文字を常に統一する**
CloudFront は、クエリ文字列パラメータに基づいてキャッシュを実行する際に、パラメータ名とパラメータ値の大文字と小文字の違いを区別します。次の例は、パラメータ名とパラメータ値の大文字と小文字だけが異なる、同じクエリ文字列です。この場合 CloudFront は、image.jpg に対する 4 つの異なるリクエストをオリジンに転送し、4 つの異なるバージョンのオブジェクトをキャッシュします。
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red`
このため、パラメータ名とパラメータ値の大文字と小文字を統一する (すべて小文字など) ことをお勧めします。
**署名付き URL と競合するパラメータ名を使わない**
署名付き URL を使用してコンテンツへのアクセスを制限している場合 (信頼された署名者をディストリビューションに追加した場合)、CloudFront は以下のクエリ文字列パラメータを削除してから URL の残りをオリジンに転送します。
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
署名付き URL を使用しており、クエリ文字列をオリジンに転送するように CloudFront を設定する場合、独自のクエリ文字列パラメータに `Expires`、`Key-Pair-Id`、`Policy`、または `Signature` という名前を付けることはできません。
## クエリ文字列パラメータと CloudFront 標準ログ (アクセスログ)
ログ作成を有効にした場合、CloudFront は、クエリ文字列パラメータを含む完全な URL をログに記録します。クエリ文字列がオリジンに転送されるように CloudFront を設定したかどうかに関係なく、そのような動作になります。CloudFront ログ記録の詳細については、「[アクセスログ (標準ログ)](AccessLogs.md)」を参照してください。
# Cookie に基づいてコンテンツをキャッシュする
デフォルトでは、CloudFront はリクエストとレスポンスを処理するとき、またはオブジェクトをエッジロケーションにキャッシュするときに Cookie を考慮しません。CloudFront が `Cookie` ヘッダーに含まれる内容以外は同一の 2 つのリクエストを受信した場合、デフォルトでは、CloudFront はリクエストを同一として扱い、両方のリクエストに対して同じオブジェクトを返します。
CloudFront でビューワーリクエストの一部またはすべて Cookie をオリジンに転送し、転送される Cookie 値に基づいてオブジェクトの別バージョンをキャッシュするように設定できます。これを行うと、CloudFront は、ビューワーリクエスト内の Cookie の一部またはすべて (転送するように設定されているものすべて) を使用して、キャッシュ内のオブジェクトを一意に識別します
たとえば、`locations.html` に対するリクエストに `country` Cookie が含まれており、その値が `uk` または `fr` であるとします。`country` Cookie の値に基づいてオブジェクトをキャッシュするように CloudFront を設定すると、CloudFront は `locations.html` に関するリクエストをオリジンに転送し、`country` Cookie とその値を含めます。オリジンは `locations.html` を返し、CloudFront は `country` Cookie の値が `uk` であるリクエスト用に 1 回、値が `fr` であるリクエスト用に 1 回、このオブジェクトをキャッシュします。
**重要**
Amazon S3 および一部の HTTP サーバーは Cookie を処理しません。Cookie を処理しないオリジンや、Cookie に基づいてレスポンスを変化させないオリジンに Cookie を転送するように CloudFront を設定しないでください。これにより、CloudFront によって同じオブジェクトのオリジンに多くのリクエストが転送されるため、パフォーマンスが低下し、オリジンの負荷が増加する可能性があります。前の例を考慮すると、オリジンが `country` Cookie を処理しない場合や、`locations.html` Cookie の値に関係なく同じバージョンの `country` を CloudFront に返す場合は、その Cookie を転送するように CloudFront を設定しないでください。
逆に、カスタムオリジンが特定の Cookie に依存しているか、Cookie に基づいて異なるレスポンスを送信する場合は、その Cookie をオリジンに転送するように CloudFront を設定してください。そのように設定しない場合、CloudFront はリクエストをオリジンに転送する前に Cookie を削除します。
Cookie 転送を設定するには、ディストリビューションのキャッシュ動作を更新します。キャッシュ動作の詳細については、「[キャッシュ動作の設定](DownloadDistValuesCacheBehavior.md)」の、特に「[cookie の転送](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies)」および「[許可リスト Cookie](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies)」セクションを参照してください。
各キャッシュ動作を設定して、次のいずれかを実行できます。
+ **オリジンにすべての Cookie を転送する - **CloudFront には、リクエストをオリジンに転送するときにビューワーが送信するすべての Cookie が含まれます。オリジンがレスポンスを返すと、CloudFront はビューワーリクエスト内の Cookie の名前と値を使用してレスポンスをキャッシュします。オリジンレスポンスに `Set-Cookie` ヘッダーが含まれている場合、CloudFront はリクエストされたオブジェクトと共にそれらのヘッダーをビューワーに返します。CloudFront は、オリジンから返されたオブジェクトと共に `Set-Cookie` ヘッダーもキャッシュし、すべてのキャッシュヒットでそれらの `Set-Cookie` ヘッダーをビューワーに送信します。
+ **指定した Cookie のセットを転送する - ** CloudFront は、リクエストをオリジンに転送する前に、アローリストにないビューワーが送信する Cookie をすべて削除します。CloudFront は、ビューワーリクエストのリストに登録された Cookie の名前と値を使用してレスポンスをキャッシュします。オリジンレスポンスに `Set-Cookie` ヘッダーが含まれている場合、CloudFront はリクエストされたオブジェクトと共にそれらのヘッダーをビューワーに返します。CloudFront は、オリジンから返されたオブジェクトと共に `Set-Cookie` ヘッダーもキャッシュし、すべてのキャッシュヒットでそれらの `Set-Cookie` ヘッダーをビューワーに送信します。
Cookie 名でワイルドカードを指定する方法の詳細については、「[許可リスト Cookie](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies)」を参照してください。
キャッシュ動作ごとに転送できる Cookie 名の数に関する現在のクォータについて、またはクォータの引き上げをリクエストするには、「[クエリ文字列のクォータ (従来のキャッシュ設定)](cloudfront-limits.md#limits-allowlisted-query-strings)」を参照してください。
+ **Cookie をオリジンに転送しない - **CloudFront は、ビューワーから送信された Cookie に基づくオブジェクトをキャッシュしません。さらに、CloudFront はリクエストをオリジンに転送する前に Cookie を削除し、レスポンスをビューワーに返す前にレスポンスから `Set-Cookie` ヘッダーを削除します。これはオリジンリソースの最適な使用方法ではないため、このキャッシュ動作を選択するときは、オリジンがデフォルトでオリジンレスポンスに Cookie を含めないようにする必要があります。
転送する Cookie を指定するときには、以下に注意してください。
**アクセスログ**
Cookie をオリジンに転送しないように CloudFront を設定した場合や、特定の Cookie のみを転送するように CloudFront を設定した場合でも、リクエストと Cookie をログに記録するように CloudFront を設定すると、CloudFront ではすべての Cookie とすべての Cookie 属性がログに記録されます。CloudFront ログ記録の詳細については、「[アクセスログ (標準ログ)](AccessLogs.md)」を参照してください。
**大文字と小文字の区別**
Cookie の名前と値は、大文字と小文字を区別します。例えば、CloudFront がすべての Cookie を転送するように設定されていて、同じオブジェクトに対する 2 つのビューワーリクエストに、大文字/小文字を除いて同一の Cookie がある場合、CloudFront はオブジェクトを 2 回キャッシュします。
**CloudFront による Cookie の並べ替え**
CloudFront が Cookie (すべてまたはサブセット) を転送するように設定されている場合、CloudFront はリクエストをオリジンに転送する前に、Cookie 名の自然な順序で Cookie を並べ替えます。
`$` 文字で始まる Cookie 名はサポートされません。CloudFront は、このリクエストをオリジンに転送する前に Cookie を削除します。`$` 文字を削除するか、Cookie 名の先頭に別の文字を指定できます。
**`If-Modified-Since` および `If-None-Match` **
`If-Modified-Since` と `If-None-Match` の条件付きリクエストは、CloudFront が Cookie (すべてまたはサブセット) を転送するように設定されている場合はサポートされません。
**標準の名前と値のペア形式が必要**
CloudFront は、値が[標準の名前と値のペア形式](https://tools.ietf.org/html/rfc6265#section-4.1.1) (`"Cookie: cookie1=value1; cookie2=value2"` など) に準拠している場合のみ、Cookie ヘッダーを転送します。
**`Set-Cookie` ヘッダーのキャッシュの無効化**
CloudFront が Cookie をオリジン (すべてまたは特定の Cookie にかかわらず) に転送するように設定されている場合、オリジンレスポンスで受信した `Set-Cookie` ヘッダーもキャッシュします。CloudFront は、元のビューワーへのレスポンスにこれらの `Set-Cookie` ヘッダーを含め、CloudFront キャッシュから提供される後続のレスポンスにも含めます。
オリジンで Cookie を受信するが、CloudFront がオリジンのレスポンスで `Set-Cookie` ヘッダーをキャッシュしないようにする場合、フィールド名として `Cache-Control` を指定する `no-cache` ディレクティブを含む `Set-Cookie` ヘッダーを追加するようにオリジンを設定します。例: `Cache-Control: no-cache="Set-Cookie"`。詳細については、「*Hypertext Transfer Protocol (HTTP/1.1): Caching*」標準の「[Response Cache-Control Directives](https://tools.ietf.org/html/rfc7234#section-5.2.2)」を参照してください。
**Cookie 名の全体の長さ**
特定の Cookie をオリジンに転送するように CloudFront を設定した場合、転送するように CloudFront を設定するすべての Cookie 名の合計バイト数は、512 から転送する Cookie の数を引いた値を超えることはできません。例えば、10 個の Cookie をオリジンに転送するように CloudFront を設定する場合は、10 個の Cookie 名の合計の長さが 502 バイト (512 - 10) を超えないようにしてください。
すべての Cookie をオリジンに転送するように CloudFront を設定する場合は、Cookie 名の長さを考慮する必要はありません。
CloudFront コンソールを使用して、CloudFront で Cookie をオリジンに転送するようにディストリビューションを更新する方法については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。CloudFront API を使用してディストリビューションを更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
# リクエストヘッダーに基づいてコンテンツをキャッシュする
CloudFront により、ヘッダーをオリジンに転送し、ビューワーリクエストのヘッダー値に基づいて異なるバージョンのオブジェクトをキャッシュするかどうかを選択できます。こうすることで、ユーザーが使っているデバイスの種類やビューワーの場所、ビューワーで使われている言語など、さまざまな条件に基づいてコンテンツの異なるバージョンを配信できます。
**Topics**
+ [
## ヘッダーとディストリビューションの概要
](#header-caching-web)
+ [
## キャッシュ条件に使用するヘッダーを選択する
](#header-caching-web-selecting)
+ [
## CORS 設定を適用するように CloudFront を設定する
](#header-caching-web-cors)
+ [
## デバイスタイプに基づいてキャッシュを設定する
](#header-caching-web-device)
+ [
## ビューワーの言語に基づいてキャッシュを設定する
](#header-caching-web-language)
+ [
## ビューワーの場所に基づいてキャッシュを設定する
](#header-caching-web-location)
+ [
## リクエストのプロトコルに基づいてキャッシュを設定する
](#header-caching-web-protocol)
+ [
## 圧縮ファイルのキャッシュを設定する
](#header-caching-web-compressed)
+ [
## ヘッダーに基づくキャッシュがパフォーマンスに及ぼす影響
](#header-caching-web-performance)
+ [
## ヘッダーとヘッダー値の大文字小文字がキャッシュに及ぼす影響
](#header-caching-web-case)
+ [
## CloudFront がビューワーに返すヘッダー
](#header-caching-web-response)
## ヘッダーとディストリビューションの概要
デフォルトで、CloudFront では、エッジロケーションでオブジェクトをキャッシュする際にヘッダーが考慮されません。オリジンが 2 つのオブジェクトを返し、そのリクエストヘッダーの値のみが異なる場合、CloudFront はオブジェクトの片方のみをキャッシュします。
ヘッダーをオリジンに転送するように CloudFront を設定できます。その場合、CloudFront は 1 つ以上のリクエストヘッダーの値に基づいてオブジェクトの複数のバージョンをキャッシュします。特定のヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定するには、ディストリビューションのキャッシュ動作の設定を指定します。詳細については、「[選択されたリクエストヘッダーに基づいたキャッシュ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders)」を参照してください。
たとえば、`logo.jpg` のヘッダーオブジェクトがカスタム `Product` ヘッダーを含み、その値が `Acme` または `Apex` であるとします。`Product` ヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定すると、CloudFront は `logo.jpg` に関するリクエストをオリジンに転送し、`Product` ヘッダーとヘッダー値を含めます。CloudFront は、`logo.jpg` ヘッダーの値が `Product` であるリクエスト用に 1 回、値が `Acme` であるリクエスト用に 1 回、`Apex` をキャッシュします。
ディストリビューションの各キャッシュ動作を以下のいずれかを実行するように設定できます。
+ すべてのヘッダーをオリジンに転送する
**注記**
**レガシーキャッシュ設定** - すべてのヘッダーをオリジンに転送するように CloudFront を設定した場合、CloudFront はこのキャッシュ動作に関連付けられたオブジェクトをキャッシュしません。その代わりに、すべてのリクエストをオリジンに送信します。
+ 指定したヘッダーのリストを転送する。CloudFront は、指定されたヘッダーすべての値に基づいてオブジェクトをキャッシュします。CloudFront は、デフォルトで転送するヘッダーも転送しますが、指定されたヘッダーの値にのみ基づいてオブジェクトをキャッシュします。
+ デフォルトのヘッダーのみを転送する。この設定の場合、CloudFront は、リクエストヘッダーの値に基づいてオブジェクトをキャッシュすることはありません。
キャッシュ動作ごとに転送できるヘッダーの数に関する現在のクォータについて、またはクォータの引き上げをリクエストするには、「[ヘッダーのクォータ](cloudfront-limits.md#limits-custom-headers)」を参照してください。
CloudFront コンソールを使用して、CloudFront でヘッダーをオリジンに転送するようにディストリビューションを更新する方法については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。CloudFront API を使用して既存のディストリビューションを更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
## キャッシュ条件に使用するヘッダーを選択する
オリジンに転送できるヘッダーおよび、CloudFront がキャッシュ条件にするヘッダーは、オリジンが Amazon S3 バケットであるか、カスタムオリジンを使用しているかに応じて変わります。
+ **Amazon S3 - **特定のヘッダーの数に基づいて、オブジェクトを転送し、キャッシュするように CloudFront を設定できます (以下の例外のリストを参照)。ただし、Cross-Origin Resource Sharing (CORS) を実装するか、オリジン側イベントで Lambda@Edge を使用してコンテンツをパーソナライズする必要がない限り、Amazon S3 オリジンを使用してヘッダーを転送しないようにすることをお勧めします。
+ CORS を設定するには、CloudFront に Cross-Origin Resource Sharing (CORS) が有効になっているウェブサイトのコンテンツの配信を許可するヘッダーを転送する必要があります。詳細については、「[CORS 設定を適用するように CloudFront を設定する](#header-caching-web-cors)」を参照してください。
+ Amazon S3 オリジンに転送するヘッダーを使用してコンテンツをパーソナライズするには、Lambda@Edge 関数を記述および追加し、オリジン側イベントによってトリガーされる CloudFront ディストリビューションに関連付けます。ヘッダーの操作によるコンテンツのパーソナライズの詳細については、「[国またはデバイスタイプヘッダー別のコンテンツのパーソナライズ - 例](lambda-examples.md#lambda-examples-redirecting-examples)」を参照してください。
使用していないヘッダーを転送してコンテンツをパーソナライズしないようにすることをお勧めします。追加のヘッダーを転送すると、キャッシュヒット率が低下する可能性があるためです。つまり、CloudFront はすべてのリクエストの比率として、エッジキャッシュからのすべてのリクエストに対応することができません。
+ **カスタムオリジン - **以下を除く任意のリクエストヘッダーの値に基づいてキャッシュするように CloudFront を設定できます。
+ `Connection`
+ `Cookie` - Cookie に基づいて転送しキャッシュする場合は、ディストリビューションの別の設定を使用します。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
+ `Host (for Amazon S3 origins)`
+ `Proxy-Authorization`
+ `TE`
+ `Upgrade`
`Date` および `User-Agent` ヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定できますが、これはお勧めできません。これらのヘッダーには可能な値が多数あり、その値に基づいてキャッシュすると、CloudFront がオリジンに転送するリクエストの数が大幅に増加します。
すべての HTTP リクエストヘッダーの一覧と、CloudFront がそれを処理する方法については、「[HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)」を参照してください。
## CORS 設定を適用するように CloudFront を設定する
Cross-Origin Resource Sharing (CORS) を Amazon S3 バケットまたはカスタムオリジンで有効にしている場合、その CORS 設定を優先させるために、転送する特定のヘッダーを選択する必要があります。転送する必要があるヘッダーは、オリジン (Amazon S3 またはカスタム)、および `OPTIONS` レスポンスをキャッシュするかどうかによって異なります。
**Amazon S3**
+ `OPTIONS` レスポンスをキャッシュする場合は、次の操作を行います。
+ `OPTIONS` レスポンスのキャッシュを有効にする、デフォルトのキャッシュ動作設定のオプションを選択します。
+ `Origin`、`Access-Control-Request-Headers`、および `Access-Control-Request-Method` ヘッダーを転送するように CloudFront を設定します。
+ `OPTIONS` レスポンスをキャッシュしない場合は、オリジンに必要な他のヘッダー (`Origin` や `Access-Control-Request-Headers` など) と一緒に `Access-Control-Request-Method` ヘッダーを転送するように CloudFront を設定します。
**カスタムオリジン** - オリジンが必要とする他のヘッダーと共に、`Origin` ヘッダーを転送します。
CORS に基づいてレスポンスをキャッシュするように CloudFront を設定するには、キャッシュポリシーを使用してヘッダーを転送するように CloudFront を設定する必要があります。詳細については、「[ポリシーを使用してキャッシュキーを制御する](controlling-the-cache-key.md)」を参照してください。
CORS と Amazon S3 の詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[Cross-Origin Resource Sharing (CORS) の使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html)」を参照してください。
## デバイスタイプに基づいてキャッシュを設定する
ユーザーがコンテンツの表示に使用しているデバイスに基づいて、オブジェクトの異なるバージョンを CloudFront でキャッシュするには、該当するヘッダーをカスタムオリジンに転送するように CloudFront を設定します。
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
CloudFront は、`User-Agent` ヘッダーの値に基づいて、これらのヘッダーの値を `true` または `false` に設定した後、リクエストをオリジンに転送します。デバイスが複数のカテゴリに属する場合は、複数の値が `true` になることがあります。たとえば、一部のタブレットデバイスに対して、CloudFront が `CloudFront-Is-Mobile-Viewer` と `CloudFront-Is-Tablet-Viewer` の両方を `true` に設定する場合があります。
## ビューワーの言語に基づいてキャッシュを設定する
リクエストで指定された言語に基づいて、オブジェクトの異なるバージョンを CloudFront でキャッシュするには、`Accept-Language` ヘッダーをオリジンに転送するように CloudFront を設定します。
## ビューワーの場所に基づいてキャッシュを設定する
リクエスト元の国に基づいて、オブジェクトの異なるバージョンを CloudFront でキャッシュするには、`CloudFront-Viewer-Country` ヘッダーをオリジンに転送するように CloudFront を設定します。CloudFront はリクエスト元の IP アドレスを 2 文字の国コードに自動的に変換します。コード順、国順に並べ替えることのできる使いやすい国コードの一覧については、Wikipedia の「[ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)」の項目を参照してください。
## リクエストのプロトコルに基づいてキャッシュを設定する
リクエストのプロトコル (HTTP または HTTPS) に基づいて、オブジェクトの異なるバージョンを CloudFront でキャッシュするには、`CloudFront-Forwarded-Proto` ヘッダーをオリジンに転送するように CloudFront を設定します。
## 圧縮ファイルのキャッシュを設定する
オリジンが Brotli 圧縮をサポートしている場合は、`Accept-Encoding` ヘッダーに基づいてキャッシュできます。オリジンがヘッダーに基づいて異なるコンテンツを配信する場合のみ、`Accept-Encoding` に基づいてキャッシュを設定する必要があります。
## ヘッダーに基づくキャッシュがパフォーマンスに及ぼす影響
ヘッダーに基づいてキャッシュするように CloudFront を設定した場合、ヘッダーで指定できる値が複数あると、CloudFront が同じオブジェクトについてオリジンサーバーに転送するリクエストの数が増えます。このためパフォーマンスが低下し、オリジンサーバーの負荷が増加します。所定のヘッダーの値に関係なくオリジンサーバーが同じオブジェクトを返す場合は、そのヘッダーに基づいてキャッシュするように CloudFront を設定しないことをお勧めします。
複数のヘッダーを転送するように CloudFront を設定した場合、ビューワーリクエストのヘッダーの順序は、値が同じである限り、キャッシュ動作には影響しません。例えば、あるリクエストのヘッダーが A:1、B:2 で、別のリクエストのヘッダーが B:2、A:1 である場合、CloudFront はそのオブジェクトのコピーを 1 つだけキャッシュします。
## ヘッダーとヘッダー値の大文字小文字がキャッシュに及ぼす影響
CloudFront がヘッダー値に基づいてキャッシュする場合、ヘッダー名の大文字小文字の違いは無視されますが、ヘッダー値の大文字小文字の違いは考慮されます。
+ ビューワーリクエストが `Product:Acme` と `product:Acme` の両方を含む場合、CloudFront がオブジェクトをキャッシュするのは 1 回だけです。両者の違いはヘッダー名の大文字小文字だけで、これはキャッシュ動作に影響しません。
+ ビューワーリクエストが `Product:Acme` と `Product:acme` の両方を含む場合、CloudFront はオブジェクトを 2 回キャッシュします。値が、あるリクエストでは `Acme`、別のリクエストでは `acme` と異なっているためです。
## CloudFront がビューワーに返すヘッダー
ヘッダーを転送およびキャッシュするように CloudFront を設定しても、CloudFront がビューワーに返すヘッダーには影響しません。CloudFront は、いくつかの例外を除いて、オリジンから取得したヘッダーをすべて返します。詳細については、該当するトピックを参照してください。
+ **Amazon S3 のオリジン - **「[CloudFront が削除または更新する HTTP レスポンスヘッダー](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers)」を参照してください。
+ **カスタムオリジン -** 「[CloudFront が削除または置き換える HTTP レスポンスヘッダー](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders)」を参照してください。