# リクエストとレスポンスの動作
以下のトピックでは、CloudFront がリクエストとレスポンスを処理する方法について説明します。
CloudFront が Amazon S3 またはカスタムオリジンとやり取りする方法、さまざまな HTTP メソッドとヘッダーを処理する方法、ステータスコードを処理する方法、キャッシュとエラーレスポンスを管理する方法について説明します。
**Topics**
+ [CloudFront が HTTP および HTTPS リクエストを処理する方法](HTTPandHTTPSRequests.md)
+ [Amazon S3 オリジンに対するリクエストとレスポンスの動作](RequestAndResponseBehaviorS3Origin.md)
+ [カスタムオリジンの場合のリクエストおよびレスポンスの動作](RequestAndResponseBehaviorCustomOrigin.md)
+ [オリジングループに対するリクエストとレスポンスの動作](RequestAndResponseBehaviorOriginGroups.md)
+ [オリジンリクエストにカスタムヘッダーを追加する](add-origin-custom-headers.md)
+ [CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法](RangeGETs.md)
+ [CloudFront がオリジンからの HTTP 3xx ステータスコードを処理する方法](http-3xx-status-codes.md)
+ [CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理する方法](HTTPStatusCodes.md)
+ [カスタムエラーレスポンスを生成する](GeneratingCustomErrorResponses.md)
# CloudFront が HTTP および HTTPS リクエストを処理する方法
Amazon S3 オリジンの場合、デフォルトでは、CloudFront は、HTTP および HTTPS プロトコルで、CloudFront ディストリビューション内のオブジェクトのリクエストを受け取ります。次に、CloudFront は、リクエストと同じプロトコルを使用して、リクエストを Amazon S3 バケットに転送します。
カスタムオリジンでは、ディストリビューションを作成する場合、CloudFront がオリジンにアクセスする方法を指定できます (HTTP のみか、ビューワーが使用しているプロトコルと一致させます)。カスタムオリジンにおいて CloudFront が HTTP および HTTPS リクエストを処理する方法については、「[プロトコル](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols)」を参照してください。
エンドユーザーが HTTPS を使用してのみオブジェクトにアクセスできるようにディストリビューションを制限する方法については、「[CloudFront で HTTPS を使用する](using-https.md)」を参照してください。
**注記**
HTTPS リクエストの料金は HTTP リクエストの料金よりも高くなります。請求料率の詳細については、「[CloudFront の料金](https://aws.amazon.com/cloudfront/#pricing)」を参照してください。
# Amazon S3 オリジンに対するリクエストとレスポンスの動作
オリジンとして Amazon S3 を使用している場合に、CloudFront がリクエストとレスポンスを処理する方法については、以下のセクションを参照してください。
**Topics**
+ [CloudFront がリクエストを処理して Amazon S3 オリジンに転送する方法](#RequestBehaviorS3Origin)
+ [CloudFront が Amazon S3 オリジンからのレスポンスを処理する方法](#ResponseBehaviorS3Origin)
## CloudFront がリクエストを処理して Amazon S3 オリジンに転送する方法
CloudFront がビューワーのリクエストを処理して Amazon S3 オリジンに転送する方法について説明します。
**Contents**
+ [キャッシュ期間および最小 TTL](#RequestS3Caching)
+ [クライアント IP アドレス](#RequestS3IPAddresses)
+ [条件付き GET リクエスト](#RequestS3ConditionalGETs)
+ [Cookie](#RequestS3Cookies)
+ [Cross-Origin Resource Sharing (CORS)](#RequestS3-cors)
+ [本文が含まれている GET リクエスト](#RequestS3-get-body)
+ [HTTP メソッド](#RequestS3HTTPMethods)
+ [CloudFront が削除または更新する HTTP リクエストヘッダー](#request-s3-removed-headers)
+ [リクエストの最大長と URL の最大長](#RequestS3MaxRequestStringLength)
+ [OCSP Stapling](#request-s3-ocsp-stapling)
+ [プロトコル](#RequestS3Protocol)
+ [クエリ文字列](#RequestS3QueryStrings)
+ [オリジン接続のタイムアウトと試行](#s3-origin-timeout-attempts)
+ [オリジン応答タイムアウト](#RequestS3RequestTimeout)
+ [同一オブジェクトへの同時リクエスト (リクエストを折りたたむ)](#request-s3-traffic-spikes)
### キャッシュ期間および最小 TTL
CloudFront が別のリクエストをオリジンに転送するまでにオブジェクトを CloudFront キャッシュに保持する時間を制御するには、次の手順を実行します。
+ `Cache-Control` または `Expires` ヘッダーフィールドを各オブジェクトに追加するようにオリジンを構成します。
+ CloudFront キャッシュ動作で、最小 TTL の値を指定します。
+ デフォルト値の 24 時間を使用します。
詳細については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
### クライアント IP アドレス
ビューワーが CloudFront に送信したリクエストに、`X-Forwarded-For` リクエストヘッダーを含めなかった場合、CloudFront は TCP 接続からビューワーの IP アドレスを取得して、IP アドレスを含めた `X-Forwarded-For` ヘッダーを追加し、リクエストをオリジンに転送します。たとえば、CloudFront が TCP 接続から IP アドレス `192.0.2.2` を取得する場合、以下のヘッダーをオリジンに転送します。
`X-Forwarded-For: 192.0.2.2`
ビューワーがリクエストを CloudFront に転送して `X-Forwarded-For` リクエストヘッダーを含める場合、CloudFront はビューワーの IP アドレスを TCP 接続から取得してそれを `X-Forwarded-For` ヘッダーの末尾に追加し、リクエストをオリジンに転送します。たとえば、ビューワーのリクエストに `X-Forwarded-For: 192.0.2.4,192.0.2.3` が含まれ、CloudFront が TCP 接続から IP アドレス `192.0.2.2` を取得する場合、以下のヘッダーをオリジンに転送します。
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
**注記**
`X-Forwarded-For` ヘッダーには、IPv4 アドレス (192.0.2.44 など) および IPv6 アドレス (2001:0db8:85a3::8a2e:0370:7334 など) が含まれます。
### 条件付き GET リクエスト
CloudFront は、エッジキャッシュで有効期限切れになっているオブジェクトに対するリクエストを受け取ると、リクエストを Amazon S3 オリジンに転送し、オブジェクトの最新バージョンを取得するか、CloudFront エッジキャッシュに最新バージョンが既に存在することを Amazon S3 に確認します。Amazon S3 はオブジェクトを CloudFront に最初に送信するときに、`ETag` 値と `LastModified` 値をレスポンスに含めます。CloudFront は、Amazon S3 に転送する新しいリクエストに、以下のヘッダーのどちらかまたは両方を追加します。
+ オブジェクトの有効期限切れバージョンの `If-Match` 値が含まれる `If-None-Match` または `ETag` ヘッダー。
+ オブジェクトの有効期限切れバージョンの `If-Modified-Since` 値が含まれる `LastModified` ヘッダー。
Amazon S3 は、この情報を使用して、オブジェクトが更新されているかどうかを判別します。つまり、オブジェクト全体を CloudFront に返すか、または HTTP 304 ステータスコード (変更なし) のみを返すかを判別します。
### Cookie
Amazon S3 は Cookie を処理しません。Cookie を Amazon S3 オリジンに転送するようにキャッシュ動作を構成した場合、CloudFront は Cookie を転送しますが、Amazon S3 は Cookie を無視します。同じオブジェクトに対する今後すべてのリクエストは、Cookie を変更するかどうかに関わらず、キャッシュ内の既存のオブジェクトから処理されます。
### Cross-Origin Resource Sharing (CORS)
CloudFront で Amazon S3 の Cross-Origin Resource Sharing 設定を尊重する場合は、選択したヘッダーを Amazon S3 に転送するように CloudFront を設定します。詳細については、「[リクエストヘッダーに基づいてコンテンツをキャッシュする](header-caching.md)」を参照してください。
### 本文が含まれている GET リクエスト
ビューワー `GET` のリクエストの本文が含まれている場合、CloudFront はビューワーに HTTP ステータスコード 403 (禁止) を返します。
### HTTP メソッド
サポートするすべての HTTP メソッドを処理するよう CloudFront を構成すると、CloudFront はビューワーからの以下のリクエストを受け入れて Amazon S3 オリジンに転送します。
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront は、`GET` リクエストと `HEAD` リクエストへの応答を常にキャッシュします。`OPTIONS` リクエストへの応答をキャッシュするように CloudFront を設定することもできます。CloudFront は他のメソッドを使用するリクエストへのレスポンスをキャッシュしません。
マルチパートアップロードを使用してオブジェクトを Amazon S3 バケットに追加する場合は、CloudFront オリジンアクセスコントロール (OAC) をディストリビューションに追加して、その OAC に必要な許可を付与する必要があります。詳細については、「[Amazon S3 オリジンへのアクセスを制限する](private-content-restricting-access-to-s3.md)」を参照してください。
**重要**
CloudFront がサポートするすべての HTTP メソッドを受け入れて Amazon S3 に転送するように CloudFront を設定する場合、Amazon S3 コンテンツへのアクセスを制限する CloudFront OAC を作成して、OAC に必要なアクセス許可を付与する必要があります。例えば、`PUT` を使用するために、上記のメソッドを受け入れて転送するように CloudFront を設定する場合は、削除すべきでないリソースをビューワーが削除できないようにするために、`DELETE` リクエストを適切に処理するように Amazon S3 バケットポリシーを設定する必要があります。詳細については、「[Amazon S3 オリジンへのアクセスを制限する](private-content-restricting-access-to-s3.md)」を参照してください。
Amazon S3 がサポートする操作の詳細については、「[Amazon S3 ドキュメント](https://docs.aws.amazon.com/s3/index.html)」を参照してください。
### CloudFront が削除または更新する HTTP リクエストヘッダー
CloudFront は、リクエストを Amazon S3 オリジンに転送する前に、一部のヘッダーを削除または更新します。ほとんどのヘッダーで、この動作はカスタムオリジンの場合と同じです。すべての HTTP リクエストヘッダーの一覧と、CloudFront がそれを処理する方法については、「[HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)」を参照してください。
### リクエストの最大長と URL の最大長
パス、クエリ文字列 (ある場合)、ヘッダーを含め、リクエストの最大長は 20480 バイトです。
CloudFront はリクエストから URL を構築します。この URL の最大長は 8192 文字です。
リクエストまたは URL が最大長を超えると、CloudFront は、HTTP ステータスコード 413 (Request Entity Too Large) をビューワーに返し、ビューワーへの TCP 接続を終了します。
### OCSP Stapling
ビューワーがオブジェクトへの HTTPS リクエストを送信する場合、CloudFront またはビューワーは、ドメインの SSL 証明書が無効になっていないことを認証機関 (CA) に確認する必要があります。OCSP Stapling を使用すると、CloudFront で証明書を検証して CA からの応答をキャッシュできるため、クライアントが直接 CA に対して証明書を検証する必要がなくなり、証明書の検証速度が向上します。
同一ドメイン内のオブジェクトに対する多数の HTTPS リクエストを CloudFront が受信した場合は、OCSP Stapling によるパフォーマンス向上がさらに顕著になります。CloudFront エッジロケーション内の各サーバーは、別々の検証リクエストを送信する必要があります。CloudFront が同一ドメインで多数の HTTPS リクエストを受信すると、エッジロケーション内のすべてのサーバーは、CA からの即座のレスポンスに応じて、SSL ハンドシェイクのパケットにステープルできます。証明書が有効であることをビューワーが確認すると、CloudFront はリクエストされたオブジェクトを提供できます。CloudFront エッジロケーション内でディストリビューションが十分なトラフィックを確保できない場合、新しいリクエストは、CA に対して証明書がまだ検証されていないサーバーに誘導される可能性が高くなります。この場合は、ビューワーが検証ステップを別途実行し、CloudFront サーバーがオブジェクトを提供します。この CloudFront サーバーも CA に検証リクエストを送信するため、同じドメイン名が含まれるリクエストを次に受信したときには、CA からの検証応答が既に存在しているということになります。
### プロトコル
CloudFront は、ビューワーリクエストのプロトコル (HTTP または HTTPS) に基づいて、HTTP または HTTPS リクエストをオリジンサーバーに転送します。
**重要**
Amazon S3 バケットがウェブサイトエンドポイントとして設定されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を設定することはできません。Amazon S3 はその設定で HTTPS 接続をサポートしていないためです。
### クエリ文字列
CloudFront でクエリ文字列パラメータを Amazon S3 オリジンに転送するかどうかを設定できます。詳細については、「[クエリ文字列パラメータに基づいてコンテンツをキャッシュする](QueryStringParameters.md)」を参照してください。
### オリジン接続のタイムアウトと試行
*オリジン接続タイムアウト*は、オリジンへの接続を確立しようとしたときに CloudFront が待機する秒数です。
*オリジン接続試行*は、CloudFront がオリジンへの接続を試行する回数です。
これらの設定により、セカンダリオリジンにフェイルオーバーするか (オリジングループの場合)、ビューワーにエラーレスポンスを返す前に、CloudFront がオリジンへの接続を試行する時間が決まります。デフォルトでは、CloudFront はセカンダリオリジンへの接続を試行したり、エラーレスポンスを返したりする前に 30 秒 (それぞれ 10 秒間の試行が 3 回) 待機します。接続タイムアウトを短くするか、試行回数を減らすか、その両方を行うことで、この時間を短縮できます。
詳細については、「[オリジンのタイムアウトと試行を制御する](high_availability_origin_failover.md#controlling-attempts-and-timeouts)」を参照してください。
### オリジン応答タイムアウト
*オリジン応答タイムアウト* (*オリジンの読み取りタイムアウト*または*オリジンリクエストタイムアウト*とも呼ばれます) は、次の両方に適用されます。
+ CloudFront がリクエストをオリジンに転送してからレスポンスを受け取るまでの待機時間 (秒)。
+ CloudFront がオリジンからレスポンスのパケットを受け取ってから次のパケットを受け取るまでの待機時間 (秒)。
CloudFront の動作は、ビューワーリクエストの HTTP メソッドによって決まります。
+ `GET` および `HEAD` リクエスト – オリジンが 30 秒以内に応答しない場合、または 30 秒間応答を停止する場合は、CloudFront は接続を中断します。指定された[オリジン接続の試行回数](DownloadDistValuesOrigin.md#origin-connection-attempts)が 1 回を超える場合、CloudFront は完全な応答の取得を再試行します。*オリジン接続の試行回数*設定の値で決められているように、CloudFront は最大 3 回試行します。最後の試行でもオリジンが応答しない場合、CloudFront は同じオリジンのコンテンツに対する別のリクエストを受け取るまで接続を試みません。
+ `DELETE`、`OPTIONS`、`PATCH`、`PUT`、`POST` リクエスト – オリジンが 30 秒以内に応答しない場合、CloudFront は接続を中断し、オリジンへの接続を再試行しません。クライアントは、必要に応じてリクエストを再送信できます。
Amazon S3 オリジン (静的ウェブサイトホスティングで設定されて*いない* S3 バケット) の応答タイムアウトを変更することはできません。
### 同一オブジェクトへの同時リクエスト (リクエストを折りたたむ)
CloudFront エッジロケーションがオブジェクトのリクエストを受け取り、オブジェクトが現在キャッシュにないか、有効期限が切れている場合、CloudFront はすぐにオリジンにリクエストを送信します。ただし、同一オブジェクトへの同時リクエストがある場合 (同じキャッシュキーを使用)、CloudFront が最初のリクエストへのレスポンスを受信する前に、同一オブジェクト (同じキャッシュキー) への追加のリクエストがエッジロケーションに届く場合、CloudFront は一時停止してから、追加のリクエストをオリジンに転送します。この短い一時停止により、オリジンでの負荷を減らすことができます。CloudFront は、一時停止中に受け取ったすべてのリクエストに、元のリクエストからのレスポンスを送信します。これは*リクエストの折りたたみ*と呼ばれます。CloudFront ログでは、最初のリクエストは `x-edge-result-type` フィールドで `Miss` と識別され、折りたたまれたリクエストは `Hit` とし識別されます。CloudFront ログの詳細については、「[CloudFront とエッジ関数のログ記録](logging.md)」を参照してください。
CloudFront は、[*キャッシュキー*](understanding-the-cache-key.md)を共有するリクエストのみを折りたたみます。リクエストヘッダーまたはクッキーまたはクエリ文字列に基づいてキャッシュするように CloudFront を設定した場合など、追加のリクエストが同じキャッシュキーを共有しない場合、CloudFront は一意のキャッシュキーを持つすべてのリクエストをオリジンに転送します。
すべてのリクエストの折りたたみを防ぐ場合は、マネージドキャッシュポリシー `CachingDisabled` を使用できます (このポリシーはキャッシュも防ぎます)。詳細については、「[マネージドキャッシュポリシーを使用する](using-managed-cache-policies.md)」を参照してください。
特定のオブジェクトへのリクエストの折りたたみを防ぐ場合は、キャッシュ動作の最小 TTL を 0 に設定し、さらに `Cache-Control: private`、`Cache-Control: no-store`、`Cache-Control: no-cache`、`Cache-Control: max-age=0`、または `Cache-Control: s-maxage=0` を送信するようにオリジンを設定できます。**これらの設定に伴ってオリジンへの負荷が増え、CloudFront が最初のリクエストへのレスポンスを待機中に一時停止される同時リクエストのレイテンシーが高くなります。
**重要**
現在、[キャッシュポリシー](controlling-the-cache-key.md)、[オリジンリクエストポリシー](controlling-origin-requests.md)、またはレガシーキャッシュ設定で Cookie 転送を有効にした場合、CloudFront はリクエストの折りたたみをサポートしません。
## CloudFront が Amazon S3 オリジンからのレスポンスを処理する方法
CloudFront が Amazon S3 オリジンからのレスポンスを処理する方法について説明します。
**Contents**
+ [取り消されたリクエスト](#response-s3-canceled-requests)
+ [CloudFront が削除または更新する HTTP レスポンスヘッダー](#response-s3-removed-headers)
+ [キャッシュ可能なファイルの最大サイズ](#ResponseS3MaxFileSize)
+ [リダイレクト](#ResponseS3Redirects)
### 取り消されたリクエスト
オブジェクトがエッジキャッシュになく、CloudFront がオブジェクトをオリジンから取得したものの、リクエストされたオブジェクトを配信する前にビューワーがセッションを終了すると (ブラウザを閉じるなど)、CloudFront はそのオブジェクトをエッジロケーションにキャッシュしません。
### CloudFront が削除または更新する HTTP レスポンスヘッダー
CloudFront は、Amazon S3 オリジンからのレスポンスをビューワーに転送する前に、以下のヘッダーフィールドを削除または更新します。
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie` – Cookie を転送するように CloudFront を構成している場合、`Set-Cookie` ヘッダーフィールドがクライアントに転送されます。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
+ `Trailer`
+ `Transfer-Encoding` – Amazon S3 オリジンがこのヘッダーフィールドを返す場合、CloudFront は値を `chunked` に設定してからビューワーにレスポンスを返します。
+ `Upgrade`
+ `Via` – CloudFront は、ビューワーへの応答で値を次のように設定します。
`Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
例えば、値は次のようになります。
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### キャッシュ可能なファイルの最大サイズ
CloudFront がキャッシュに保存するレスポンスボディの最大サイズは 50 GB です。これには、`Content-Length` ヘッダーの値を指定しないチャンク転送レスポンスが含まれます。
それぞれ 50 GB 以下のパートのオブジェクトをリクエストする範囲リクエストを使用して、このサイズを超えるオブジェクトをキャッシュするには、CloudFront を使用します。CloudFront がこれらのパートをキャッシュするのは、それぞれが 50 GB 以下であるためです。ビューワーによって、オブジェクトのすべてのパートを取得した後、元の大きなオブジェクトが再構築されます。詳しくは、「[範囲リクエストを使用して大きなオブジェクトをキャッシュする](RangeGETs.md#cache-large-objects-with-range-requests)」を参照してください。
### リダイレクト
すべてのリクエストを別のホスト名にリダイレクトするように Amazon S3 バケットを構成できます。別のホスト名には、別の Amazon S3 バケットまたは HTTP サーバーを使用できます。すべてのリクエストをリダイレクトするようにバケットを構成しており、バケットが CloudFront ディストリビューションのオリジンの場合、ディストリビューションのドメイン名 (例: d111111abcdef8.cloudfront.net) またはディストリビューションに関連付けられた代替ドメイン名 (CNAME) (例: example.com) を使用してすべてのリクエストを CloudFront ディストリビューションにリダイレクトするようにバケットを構成することをお勧めします。このように構成しない場合、ビューワーリクエストは CloudFront をバイパスし、オブジェクトは新しいオリジンから直接提供されます。
**注記**
代替ドメイン名にリクエストをリダイレクトする場合は、CNAME レコードを追加してドメインの DNS サービスを更新する必要もあります。詳細については、「[代替ドメイン名 (CNAME) を追加することによって、カスタム URL を使用する](CNAMEs.md)」を参照してください。
すべてのリクエストをリダイレクトするようにバケットを構成した場合の動作を以下に示します。
1. ビューワー (例: ブラウザ) が CloudFront にオブジェクトを要求します。
1. CloudFront は、ディストリビューションのオリジンである Amazon S3 バケットにリクエストを転送します。
1. Amazon S3 は、HTTP ステータスコード 301 (Moved Permanently) と新しい場所を返します。
1. CloudFront は、リダイレクトのステータスコードと新しい場所をキャッシュし、ビューワーに値を返します。CloudFront がリダイレクトに従って新しい場所からオブジェクトを取得することはありません。
1. ビューワーはオブジェクトに対する別のリクエストを送信しますが、今回は、CloudFront から取得した新しい場所を指定します。
+ Amazon S3 バケットが、ディストリビューションのドメイン名または代替ドメイン名を使用してすべてのリクエストを CloudFront ディストリビューションにリダイレクトする場合、CloudFront は新しい場所にある Amazon S3 バケットまたは HTTP サーバーのオブジェクトをリクエストします。新しい場所からオブジェクトが返されると、CloudFront はオブジェクトをビューワーに返し、エッジロケーションにオブジェクトをキャッシュします。
+ Amazon S3 バケットがリクエストを別の場所にリダイレクトする場合、2 番目のリクエストは CloudFront をバイパスします。新しい場所にある Amazon S3 バケットまたは HTTP サーバーがオブジェクトをビューワーに直接返すので、オブジェクトは CloudFront エッジキャッシュに一切キャッシュされません。
# カスタムオリジンの場合のリクエストおよびレスポンスの動作
カスタムオリジンの使用時に CloudFront がリクエストとレスポンスを処理する方法については、以下のセクションを参照してください。
**Topics**
+ [CloudFront がリクエストを処理してカスタムオリジンに転送する方法](#RequestBehaviorCustomOrigin)
+ [CloudFront がカスタムオリジンからのレスポンスを処理する方法](#ResponseBehaviorCustomOrigin)
## CloudFront がリクエストを処理してカスタムオリジンに転送する方法
CloudFront がビューワーのリクエストを処理してカスタムオリジンに転送する方法について説明します。
**Contents**
+ [認証](#RequestCustomClientAuth)
+ [キャッシュ期間および最小 TTL](#RequestCustomCaching)
+ [クライアント IP アドレス](#RequestCustomIPAddresses)
+ [クライアント側の SSL 認証](#RequestCustomClientSideSslAuth)
+ [圧縮](#RequestCustomCompression)
+ [条件付きリクエスト](#RequestCustomConditionalGETs)
+ [Cookie](#RequestCustomCookies)
+ [Cross-Origin Resource Sharing (CORS)](#request-custom-cors)
+ [暗号化](#RequestCustomEncryption)
+ [本文が含まれている GET リクエスト](#RequestCustom-get-body)
+ [HTTP メソッド](#RequestCustomHTTPMethods)
+ [HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)](#request-custom-headers-behavior)
+ [HTTP バージョン](#RequestCustomHTTPVersion)
+ [リクエストの最大長と URL の最大長](#RequestCustomMaxRequestStringLength)
+ [OCSP stapling](#request-custom-ocsp-stapling)
+ [持続的接続](#request-custom-persistent-connections)
+ [プロトコル](#RequestCustomProtocols)
+ [クエリ文字列](#RequestCustomQueryStrings)
+ [オリジン接続のタイムアウトと試行](#custom-origin-timeout-attempts)
+ [オリジン応答タイムアウト](#request-custom-request-timeout)
+ [同一オブジェクトへの同時リクエスト (リクエストを折りたたむ)](#request-custom-traffic-spikes)
+ [`User-Agent` ヘッダー](#request-custom-user-agent-header)
### 認証
`Authorization` ヘッダーをオリジンに転送すると、次のタイプのリクエストに対してクライアント認証を要求するようにオリジンサーバーを設定できます。
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`
`OPTIONS` リクエストの場合、次の CloudFront 設定を使用した場合のみ、クライアント認証を設定できます。**
+ CloudFront は、`Authorization` ヘッダーをオリジンに転送するように設定されます。
+ CloudFront は、`OPTIONS` リクエストへの応答をキャッシュしないように設定されます。**
詳細については、「[`Authorization` ヘッダーを転送するように CloudFront を設定する](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization)」を参照してください。
HTTP または HTTPS を使用して、リクエストをオリジンサーバーに転送できます。詳細については、「[CloudFront で HTTPS を使用する](using-https.md)」を参照してください。
### キャッシュ期間および最小 TTL
CloudFront が別のリクエストをオリジンに転送するまでにオブジェクトを CloudFront キャッシュに保持する時間を制御するには、次の手順を実行します。
+ `Cache-Control` または `Expires` ヘッダーフィールドを各オブジェクトに追加するようにオリジンを構成します。
+ CloudFront キャッシュ動作で、最小 TTL の値を指定します。
+ デフォルト値の 24 時間を使用します。
詳細については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
### クライアント IP アドレス
ビューワーがリクエストを CloudFront に送信し、`X-Forwarded-For` リクエストヘッダーを含めない場合、CloudFront は TCP 接続からビューワーの IP アドレスを取得して、IP アドレスが含まれた `X-Forwarded-For` ヘッダーを追加し、リクエストをオリジンに転送します。たとえば、CloudFront が TCP 接続から IP アドレス `192.0.2.2` を取得する場合、以下のヘッダーをオリジンに転送します。
`X-Forwarded-For: 192.0.2.2`
ビューワーがリクエストを CloudFront に転送して `X-Forwarded-For` リクエストヘッダーを含める場合、CloudFront はビューワーの IP アドレスを TCP 接続から取得してそれを `X-Forwarded-For` ヘッダーの末尾に追加し、リクエストをオリジンに転送します。たとえば、ビューワーのリクエストに `X-Forwarded-For: 192.0.2.4,192.0.2.3` が含まれ、CloudFront が TCP 接続から IP アドレス `192.0.2.2` を取得する場合、以下のヘッダーをオリジンに転送します。
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
ロードバランサー (Elastic Load Balancing を含む)、ウェブアプリケーションファイアウォール、リバースプロキシ、侵入防御システム、API Gateway などの一部のアプリケーションでは、リクエストを転送した CloudFront エッジサーバーの IP アドレスが `X-Forwarded-For` ヘッダーの末尾に付加されます。たとえば、CloudFront から ELB に転送するリクエストに `X-Forwarded-For: 192.0.2.2` が含まれていて、CloudFront エッジサーバーの IP アドレスが 192.0.2.199 である場合、EC2 インスタンスで受け取るリクエストのヘッダーは次のようになります。
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**注記**
`X-Forwarded-For` ヘッダーには、IPv4 アドレス (192.0.2.44 など) および IPv6 アドレス (2001:0db8:85a3::8a2e:0370:7334 など) が含まれます。
また、`X-Forwarded-For` ヘッダーは現在のサーバー (CloudFront) へのパス上のすべてのノードによって変更される可能性があることにも注意してください。詳細については、[RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239) のセクション 8.1 を参照してください。CloudFront エッジコンピューティング関数を使用してヘッダーを変更することもできます。
### クライアント側の SSL 認証
CloudFront は、クライアントとサーバーの両方が証明書を使用して相互に認証する相互 TLS (mTLS) 認証をサポートしています。mTLS を設定すると、CloudFront は TLS ハンドシェイク中にクライアント証明書を検証し、オプションで CloudFront Functions を実行してカスタム検証ロジックを実装できます。
mTLS が設定されていないときにクライアント側の証明書をリクエストするオリジンの場合、CloudFront はリクエストを削除します。
mTLS の設定に関する詳細は、「[CloudFront Connection Function を関連付ける](connection-functions.md)」を参照してください。
CloudFront はクライアント側の SSL 証明書を使用したクライアント認証をサポートしていません。オリジンがクライアント側証明書をリクエストした場合、CloudFront はリクエストを削除します。
### 圧縮
詳しくは、「[圧縮ファイルを供給する](ServingCompressedFiles.md)」を参照してください。
### 条件付きリクエスト
CloudFront は、エッジキャッシュで有効期限切れになっているオブジェクトに対するリクエストを受け取ると、リクエストをオリジンに転送し、オブジェクトの最新バージョンを取得するか、CloudFront エッジキャッシュに最新バージョンがすでに存在することをオリジンに確認します。通常、オリジンはオブジェクトを CloudFront に最後に送信するときに、`ETag` 値または `LastModified` 値、あるいはその両方の値をレスポンスに含めます。CloudFront は、CloudFront がオリジンに転送する新しいリクエストには、次のどちらかまたは両方を追加します。
+ オブジェクトの有効期限切れバージョンの `If-Match` 値が含まれる `If-None-Match` または `ETag` ヘッダー。
+ オブジェクトの有効期限切れバージョンの `If-Modified-Since` 値が含まれる `LastModified` ヘッダー。
オリジンは、この情報を使用して、オブジェクトが更新されているかどうかを判別します。つまり、オブジェクト全体を CloudFront に返すか、または HTTP 304 ステータスコード (変更なし) のみを返すかを判別します。
**注記**
`If-Modified-Since` と `If-None-Match` の条件付きリクエストは、CloudFront が Cookie (すべてまたはサブセット) を転送するように設定されている場合はサポートされません。
詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
### Cookie
Cookie をオリジンに転送するように CloudFront を構成できます。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
### Cross-Origin Resource Sharing (CORS)
CloudFront で Cross-Origin Resource Sharing 設定を適用する場合は、`Origin` ヘッダーをオリジンに転送するように CloudFront を設定します。詳しくは、「[リクエストヘッダーに基づいてコンテンツをキャッシュする](header-caching.md)」を参照してください。
### 暗号化
HTTPS を使用してリクエストを CloudFront に送信するようにビューワーに要求し、ビューワーが使用しているプロトコルを使用してカスタムオリジンにリクエストを転送するように CloudFront に要求することもできます。詳細については、次のディストリビューション設定を参照してください。
+ [ビューワープロトコルポリシー](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [プロトコル (カスタムオリジンのみ)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront は、SSLv3、TLSv1.0、TLSv1.1、TLSv1.2 および TLSv1.3 プロトコルを使用して、HTTPS リクエストをオリジンサーバーに転送します。カスタムオリジンでは、オリジンと通信する際に CloudFront が使用する SSL プロトコルを選択できます。
+ CloudFront コンソールを使用する場合は、[**オリジン SSL プロトコル**] チェックボックスを使用するプロトコルを選択します。詳細については、「[ディストリビューションを作成する](distribution-web-creating-console.md)」を参照してください。
+ CloudFront API を使用する場合は、`OriginSslProtocols` 要素を使用してプロトコルを指定します。詳細については、*Amazon CloudFront API リファレンス*の「[OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)」および「[DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)」を参照してください。
オリジンが Amazon S3 バケットの場合、CloudFront はデフォルトで TLSv1.3 を使用します。
**重要**
SSL と TLS のその他のバージョンはサポートされていません。
CloudFront での HTTPS の使用の詳細については、「[CloudFront で HTTPS を使用する](using-https.md)」を参照してください。ビューワーと CloudFront との間、および CloudFront とオリジンとの間の HTTPS 通信で CloudFront がサポートする暗号のリストについては、[ビューワーと CloudFront との間でサポートされているプロトコルと暗号](secure-connections-supported-viewer-protocols-ciphers.md) を参照してください。
### 本文が含まれている GET リクエスト
ビューワー `GET` のリクエストの本文が含まれている場合、CloudFront はビューワーに HTTP ステータスコード 403 (禁止) を返します。
### HTTP メソッド
サポートするすべての HTTP メソッドを処理するよう CloudFront を構成すると、CloudFront はビューワーからの以下のリクエストを受け入れてカスタムオリジンに転送します。
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront は、`GET` リクエストと `HEAD` リクエストへの応答を常にキャッシュします。`OPTIONS` リクエストへの応答をキャッシュするように CloudFront を設定することもできます。CloudFront はその他のメソッドを使用するリクエストへのレスポンスをキャッシュしません。
カスタムオリジンが上記のメソッドを処理するかどうかを構成する方法の詳細については、オリジンのドキュメントを参照してください。
**重要**
CloudFront がサポートするすべての HTTP メソッドを受け入れてオリジンに転送するように CloudFront を構成する場合、オリジンサーバーがすべてのメソッドを処理するように構成します。たとえば、`POST` を使用するために、上記のメソッドを受け入れて転送するように CloudFront を構成する場合は、`DELETE` リクエストを適切に処理するようオリジンサーバーを構成して、削除すべきでないリソースをビューワーが削除できないようにする必要があります。詳細については、HTTP サーバーのドキュメントを参照してください。
### HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)
次の表は、カスタムオリジンと Amazon S3 オリジンの両方に転送できる HTTP リクエストヘッダーを示しています (例外も注記されています)。この表には、各ヘッダーについて以下に関する情報も含まれています。
+ ヘッダーをオリジンに転送するように CloudFront を設定していない場合の CloudFront の動作。この場合、CloudFront はヘッダー値に基づいてオブジェクトをキャッシュします。
+ そのヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定できるかどうか。
`Date` および `User-Agent` ヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定できますが、これはお勧めできません。これらのヘッダーには可能な値が多数あり、その値に基づいてキャッシュすると、CloudFront がオリジンに転送するリクエストの数が大幅に増加します。
ヘッダー値に基づくキャッシュの詳細については、「[リクエストヘッダーに基づいてコンテンツをキャッシュする](header-caching.md)」を参照してください。
| ヘッダー | ヘッダー値に基づいてキャッシュするように CloudFront を設定しない場合の動作 | ヘッダー値に基づくキャッシュがサポートされている |
| --- | --- | --- |
| 他の定義されたヘッダー | **レガシーキャッシュ設定** – CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Accept` | CloudFront はヘッダーを削除します。 | はい |
| `Accept-Charset` | CloudFront はヘッダーを削除します。 | はい |
| `Accept-Encoding` | 値に `gzip` または `br` が含まれている場合、CloudFront は正規化された `Accept-Encoding` ヘッダーをオリジンに転送します。 詳細については、「[圧縮のサポート](cache-key-understand-cache-policy.md#cache-policy-compressed-objects)」および「[圧縮ファイルを供給する](ServingCompressedFiles.md)」を参照してください。 | はい |
| `Accept-Language` | CloudFront はヘッダーを削除します。 | はい |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | はい |
| `Cache-Control` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `CloudFront-Forwarded-Proto` | CloudFront は、リクエストをオリジンに転送する前にヘッダーを追加しません。 詳細については、「[リクエストのプロトコルに基づいてキャッシュを設定する](header-caching.md#header-caching-web-protocol)」を参照してください。 | はい |
| `CloudFront-Is-Desktop-Viewer` | CloudFront は、リクエストをオリジンに転送する前にヘッダーを追加しません。 詳細については、「[デバイスタイプに基づいてキャッシュを設定する](header-caching.md#header-caching-web-device)」を参照してください。 | はい |
| `CloudFront-Is-Mobile-Viewer` | CloudFront は、リクエストをオリジンに転送する前にヘッダーを追加しません。 詳細については、「[デバイスタイプに基づいてキャッシュを設定する](header-caching.md#header-caching-web-device)」を参照してください。 | はい |
| `CloudFront-Is-Tablet-Viewer` | CloudFront は、リクエストをオリジンに転送する前にヘッダーを追加しません。 詳細については、「[デバイスタイプに基づいてキャッシュを設定する](header-caching.md#header-caching-web-device)」を参照してください。 | はい |
| `CloudFront-Viewer-Country` | CloudFront は、リクエストをオリジンに転送する前にヘッダーを追加しません。 | はい |
| `Connection` | CloudFront は、オリジンにリクエストを転送する前に、このヘッダーを `Connection: Keep-Alive` ヘッダーに置き換えます。 | いいえ |
| `Content-Length` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `Content-MD5` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Content-Type` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Cookie` | Cookie を転送するように CloudFront を設定すると、`Cookie` ヘッダーフィールドがオリジンに転送されます。そうでない場合、CloudFront は `Cookie` ヘッダーフィールドを削除します。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。 | いいえ |
| `Date` | CloudFront はヘッダーをオリジンに転送します。 | はい、ただし推奨されません |
| `Expect` | CloudFront はヘッダーを削除します。 | はい |
| `From` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Host` | CloudFront は、リクエストされたオブジェクトに関連付けられたオリジンのドメイン名に値を設定します。 Amazon S3 または MediaStore オリジンのホストヘッダーに基づいてキャッシュすることはできません。 | はい (カスタム) いいえ (S3 および MediaStore) |
| `If-Match` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `If-Modified-Since` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `If-None-Match` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `If-Range` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `If-Unmodified-Since` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Max-Forwards` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `Origin` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Pragma` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `Proxy-Authenticate` | CloudFront はヘッダーを削除します。 | いいえ |
| `Proxy-Authorization` | CloudFront はヘッダーを削除します。 | いいえ |
| `Proxy-Connection` | CloudFront はヘッダーを削除します。 | いいえ |
| `Range` | CloudFront はヘッダーをオリジンに転送します。詳細については、「[CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法](RangeGETs.md)」を参照してください。 | はい (デフォルト) |
| `Referer` | CloudFront はヘッダーを削除します。 | はい |
| `Request-Range` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `TE` | CloudFront はヘッダーを削除します。 | いいえ |
| `Trailer` | CloudFront はヘッダーを削除します。 | いいえ |
| `Transfer-Encoding` | CloudFront はヘッダーをオリジンに転送します。 | いいえ |
| `Upgrade` | WebSocket 接続が確立されていない限り、CloudFront はヘッダーを削除します。 | いいえ (WebSocket 接続の場合を除く) |
| `User-Agent` | CloudFront はこのヘッダーフィールドの値を `Amazon CloudFront` に置き換えます。ユーザーが使用しているデバイスに基づいて CloudFront でコンテンツをキャッシュする場合は、「[デバイスタイプに基づいてキャッシュを設定する](header-caching.md#header-caching-web-device)」を参照してください。 | はい、ただし推奨されません |
| `Via` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `Warning` | CloudFront はヘッダーをオリジンに転送します。 | はい |
| `X-Amz-Cf-Id` | CloudFront は、リクエストをオリジンに転送する前に、ビューワーリクエストにヘッダーを追加します。ヘッダー値には、リクエストを一意に識別する暗号化された文字列が含められます。 | いいえ |
| `X-Edge-*` | CloudFront はすべての `X-Edge-*` ヘッダーを削除します。 | いいえ |
| `X-Forwarded-For` | CloudFront はヘッダーをオリジンに転送します。詳細については、「[クライアント IP アドレス](#RequestCustomIPAddresses)」を参照してください。 | はい |
| `X-Forwarded-Proto` | CloudFront はヘッダーを削除します。 | いいえ |
| `X-HTTP-Method-Override` | CloudFront はヘッダーを削除します。 | はい |
| `X-Real-IP` | CloudFront はヘッダーを削除します。 | いいえ |
### HTTP バージョン
CloudFront は HTTP/1.1 を使用してカスタムオリジンにリクエストを転送します。
### リクエストの最大長と URL の最大長
パス、クエリ文字列 (ある場合)、ヘッダーを含め、リクエストの最大長は 20480 バイトです。
CloudFront はリクエストから URL を構築します。この URL の最大長は 8192 文字です。
リクエストまたは URL がこの最大制限を超えると、CloudFront は、リクエストヘッダーフィールドが長すぎることを示す HTTP ステータスコード 413 (Request Entity Too Large) をビューワーに返してから、ビューワーへの TCP 接続を終了します。
### OCSP stapling
オブジェクトに対する HTTPS リクエストをビューワーが送信する際には、ドメインの SSL 証明書が無効になっていないことを CloudFront またはビューワーが認証機関 (CA) に対して確認する必要があります。OCSP Stapling を使用すると、CloudFront で証明書を検証して CA からの応答をキャッシュできるため、クライアントが直接 CA に対して証明書を検証する必要がなくなり、証明書の検証速度が向上します。
同一ドメイン内のオブジェクトに対する多数の HTTPS リクエストを CloudFront が受信した場合は、OCSP Stapling によるパフォーマンス向上がさらに顕著になります。CloudFront エッジロケーション内の各サーバーは、別々の検証リクエストを送信する必要があります。同一ドメインに対する多数の HTTPS リクエストを CloudFront が受信するとすぐに、エッジロケーション内のすべてのサーバーが、SSL ハンドシェイクでパケットに「ステープリング」できるという CA からの応答を受信します。証明書が有効であることをビューワーが確認すると、CloudFront はリクエストされたオブジェクトを提供できます。CloudFront エッジロケーション内でディストリビューションが十分なトラフィックを確保できない場合、新しいリクエストは、CA に対して証明書がまだ検証されていないサーバーに誘導される可能性が高くなります。この場合は、ビューワーが検証ステップを別途実行し、CloudFront サーバーがオブジェクトを提供します。この CloudFront サーバーも CA に検証リクエストを送信するため、同じドメイン名が含まれるリクエストを次に受信したときには、CA からの検証応答が既に存在しているということになります。
### 持続的接続
CloudFront がオリジンからレスポンスを取得すると、その期間中に別のリクエストが届くのに備え、数秒間、接続を維持しようとします。持続的接続を維持すると、TCP 接続の再構築に必要な時間と後続のリクエストに対する別の TLS ハンドシェイクの実行に必要な時間を節約できます。
持続的接続の期間を設定する方法など、詳細については、「[キープアライブタイムアウト (カスタムオリジンおよび VPC オリジンのみ)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout)」セクションの「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」を参照してください。
### プロトコル
CloudFront は、以下の項目に基づいて、HTTP または HTTPS リクエストをオリジンサーバーに転送します。
+ ビューワーが CloudFront に送信したリクエストのプロトコル (HTTP または HTTPS)。
+ CloudFront コンソールの [**オリジンプロトコルポリシー**] フィールドの値。または、CloudFront API を使用する場合は、`OriginProtocolPolicy` 複合型の `DistributionConfig` エレメントの値。CloudFront コンソールで使用できるオプションは、[**HTTP のみ**]、[**HTTPS のみ**]、および [**一致ビューワー**] です。
[**HTTP のみ**] または [**HTTPS のみ**] を指定すると、CloudFront では、ビューワーリクエストのプロトコルに関係なく、指定されたプロトコルのみを使用してリクエストをオリジンサーバーに転送します。
[**一致ビューワー**] を指定した場合、CloudFront はビューワーリクエストのプロトコルを使用してリクエストをオリジンサーバーに転送します。ビューワーが HTTP と HTTPS の両方のプロトコルを使用してリクエストを行った場合も、CloudFront がオブジェクトをキャッシュするのは 1 回だけです。
**重要**
CloudFront が HTTPS プロトコルを使用してリクエストをオリジンに転送し、オリジンサーバーから無効な証明書または自己署名証明書が返された場合、CloudFront は TCP 接続を中断します。
CloudFront コンソールを使用してディストリビューションを更新する方法については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。CloudFront API を使用してディストリビューションを更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してくださいCloudFront。
### クエリ文字列
CloudFront でクエリ文字列パラメータをオリジンに転送するかどうかを構成できます。詳細については、「[クエリ文字列パラメータに基づいてコンテンツをキャッシュする](QueryStringParameters.md)」を参照してください。
### オリジン接続のタイムアウトと試行
*オリジン接続タイムアウト*は、オリジンへの接続を確立しようとしたときに CloudFront が待機する秒数です。
*オリジン接続試行*は、CloudFront がオリジンへの接続を試行する回数です。
これらの設定により、セカンダリオリジンにフェイルオーバーするか (オリジングループの場合)、ビューワーにエラーレスポンスを返す前に、CloudFront がオリジンへの接続を試行する時間が決まります。デフォルトでは、CloudFront はセカンダリオリジンへの接続を試行したり、エラーレスポンスを返したりする前に 30 秒 (それぞれ 10 秒間の試行が 3 回) 待機します。接続タイムアウトを短くするか、試行回数を減らすか、その両方を行うことで、この時間を短縮できます。
詳細については、「[オリジンのタイムアウトと試行を制御する](high_availability_origin_failover.md#controlling-attempts-and-timeouts)」を参照してください。
### オリジン応答タイムアウト
*オリジン応答タイムアウト* (*オリジンの読み取りタイムアウト*または*オリジンリクエストタイムアウト*とも呼ばれます) は、次の両方に適用されます。
+ CloudFront がリクエストをオリジンに転送してからレスポンスを受け取るまでの待機時間 (秒)。
+ CloudFront がオリジンからレスポンスのパケットを受け取ってから次のパケットを受け取るまでの待機時間 (秒)。
CloudFront の動作は、ビューワーリクエストの HTTP メソッドによって決まります。
+ `GET` および `HEAD` リクエスト ― 応答タイムアウトの期間内にオリジンが応答しない場合、または応答を停止した場合、CloudFront は接続を中断します。指定された[オリジン接続の試行回数](DownloadDistValuesOrigin.md#origin-connection-attempts)が 1 回を超える場合、CloudFront は完全な応答の取得を再試行します。*オリジン接続の試行回数*設定の値で決められているように、CloudFront は最大 3 回試行します。最後の試行でもオリジンが応答しない場合、CloudFront は同じオリジンのコンテンツに対する別のリクエストを受け取るまで接続を試みません。
+ `DELETE`、`OPTIONS`、`PATCH`、`PUT`、`POST` の各リクエスト – オリジンが読み取りタイムアウトの期間中に応答しない場合、CloudFront は接続を中断し、オリジンへの接続を再試行しません。クライアントは、必要に応じてリクエストを再送信できます。
オリジン応答タイムアウトを設定する方法など、詳細については、「[応答タイムアウト](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)」を参照してください。
### 同一オブジェクトへの同時リクエスト (リクエストを折りたたむ)
CloudFront エッジロケーションがオブジェクトのリクエストを受け取り、オブジェクトが現在キャッシュにないか、有効期限が切れている場合、CloudFront はすぐにオリジンにリクエストを送信します。ただし、同一オブジェクトへの同時リクエストがある場合 (同じキャッシュキーを使用)、CloudFront が最初のリクエストへのレスポンスを受信する前に、同一オブジェクト (同じキャッシュキー) への追加のリクエストがエッジロケーションに届く場合、CloudFront は一時停止してから、追加のリクエストをオリジンに転送します。この短い一時停止により、オリジンでの負荷を減らすことができます。CloudFront は、一時停止中に受け取ったすべてのリクエストに、元のリクエストからのレスポンスを送信します。これは*リクエストの折りたたみ*と呼ばれます。CloudFront ログでは、最初のリクエストは `x-edge-result-type` フィールドで `Miss` と識別され、折りたたまれたリクエストは `Hit` とし識別されます。CloudFront ログの詳細については、「[CloudFront とエッジ関数のログ記録](logging.md)」を参照してください。
CloudFront は、[*キャッシュキー*](understanding-the-cache-key.md)を共有するリクエストのみを折りたたみます。リクエストヘッダーまたはクッキーまたはクエリ文字列に基づいてキャッシュするように CloudFront を設定した場合など、追加のリクエストが同じキャッシュキーを共有しない場合、CloudFront は一意のキャッシュキーを持つすべてのリクエストをオリジンに転送します。
すべてのリクエストの折りたたみを防ぐ場合は、マネージドキャッシュポリシー `CachingDisabled` を使用できます (このポリシーはキャッシュも防ぎます)。詳細については、「[マネージドキャッシュポリシーを使用する](using-managed-cache-policies.md)」を参照してください。
特定のオブジェクトへのリクエストの折りたたみを防ぐ場合は、キャッシュ動作の最小 TTL を 0 に設定し、さらに `Cache-Control: private`、`Cache-Control: no-store`、`Cache-Control: no-cache`、`Cache-Control: max-age=0`、または `Cache-Control: s-maxage=0` を送信するようにオリジンを設定できます。**これらの設定に伴ってオリジンへの負荷が増え、CloudFront が最初のリクエストへのレスポンスを待機中に一時停止される同時リクエストのレイテンシーが高くなります。
**重要**
現在、[キャッシュポリシー](controlling-the-cache-key.md)、[オリジンリクエストポリシー](controlling-origin-requests.md)、またはレガシーキャッシュ設定で Cookie 転送を有効にした場合、CloudFront はリクエストの折りたたみをサポートしません。
### `User-Agent` ヘッダー
ユーザーがコンテンツの表示に使用しているデバイスに基づいて、オブジェクトの異なるバージョンを CloudFront でキャッシュするには、次の 1 つ以上のヘッダーをカスタムオリジンに転送するように 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 を設定する方法の詳細については、「[リクエストヘッダーに基づいてコンテンツをキャッシュする](header-caching.md)」を参照してください。
`User-Agent` ヘッダーの値に基づいてオブジェクトをキャッシュするように CloudFront を設定できますが、これはお勧めできません。`User-Agent` ヘッダーには可能な値が多数あり、その値に基づいてキャッシュすると、CloudFront がオリジンに転送するリクエストの数が大幅に増加します。
CloudFront が `User-Agent` ヘッダーの値に基づいてオブジェクトをキャッシュするように設定しない場合、CloudFront は以下の値を指定した `User-Agent` ヘッダーを追加して、リクエストをオリジンに転送します。
`User-Agent = Amazon CloudFront`
CloudFront は、ビューワーからのリクエストに `User-Agent` ヘッダーが含まれているかどうかに関係なく、このヘッダーを追加します。ビューワーからのリクエストに `User-Agent` ヘッダーが含まれる場合、CloudFront はそのヘッダーを削除します。
## CloudFront がカスタムオリジンからのレスポンスを処理する方法
CloudFront がカスタムオリジンからのレスポンスを処理する方法について説明します。
**Contents**
+ [`100 Continue` 件のレスポンス](#Response100Continue)
+ [キャッシュ](#ResponseCustomCaching)
+ [取り消されたリクエスト](#response-custom-canceled-requests)
+ [コンテンツネゴシエーション](#ResponseCustomContentNegotiation)
+ [Cookie](#ResponseCustomCookies)
+ [中断された TCP 接続](#ResponseCustomDroppedTCPConnections)
+ [CloudFront が削除または置き換える HTTP レスポンスヘッダー](#ResponseCustomRemovedHeaders)
+ [キャッシュ可能なファイルの最大サイズ](#ResponseCustomMaxFileSize)
+ [使用できないオリジン](#ResponseCustomOriginUnavailable)
+ [リダイレクト](#ResponseCustomRedirects)
+ [`Transfer-Encoding` ヘッダー](#ResponseCustomTransferEncoding)
### `100 Continue` 件のレスポンス
オリジンは複数の 100-continue レスポンスを CloudFront に送信することはできません。最初の 100-continue レスポンスの後で、CloudFront は HTTP 200 OK レスポンスを予期します。オリジンが最初のレスポンスの後に別の 100-continue レスポンスを送信すると、CloudFront はエラーを返します。
### キャッシュ
+ オリジンサーバーが `Date` および `Last-Modified` ヘッダーフィールドに有効かつ正確な値を設定していることを確認します。
+ 通常、CloudFront はオリジンからのレスポンスの `Cache-Control: no-cache` ヘッダーを優先します。例外については、「[同一オブジェクトへの同時リクエスト (リクエストを折りたたむ)](#request-custom-traffic-spikes)」を参照してください。
### 取り消されたリクエスト
オブジェクトがエッジキャッシュになく、CloudFront がオブジェクトをオリジンから取得したものの、リクエストされたオブジェクトを配信する前にビューワーがセッションを終了すると (ブラウザを閉じるなど)、CloudFront はそのオブジェクトをエッジロケーションにキャッシュしません。
### コンテンツネゴシエーション
オリジンが応答で `Vary:*` を返し、対応するキャッシュ動作の [**最小 TTL**] の値が [**0**] の場合、CloudFront はオブジェクトをキャッシュしますが、そのオブジェクトの後続のすべてのリクエストをオリジンに転送して、キャッシュにオブジェクトの最新バージョンが含まれていることを確認します。CloudFront には、`If-None-Match` や `If-Modified-Since` などの条件付きヘッダーは含まれません。その結果、オリジンはすべてのリクエストに応じて CloudFront にオブジェクトを返します。
オリジンが応答で `Vary:*` を返し、対応するキャッシュ動作の [**最小 TTL**] の値が別の値になっている場合、CloudFront は「`Vary`」に記述されている方法で [CloudFront が削除または置き換える HTTP レスポンスヘッダー](#ResponseCustomRemovedHeaders) ヘッダーを処理します。
### Cookie
キャッシュ動作の Cookie を有効にしており、オリジンが Cookie とオブジェクトを返す場合、CloudFront はオブジェクトと Cookie の両方をキャッシュします。これにより、オブジェクトのキャッシュ可能性が低下します。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
### 中断された TCP 接続
オリジンがオブジェクトを CloudFront に返している間に CloudFront とオリジン間の TCP 接続が中断した場合、CloudFront の動作は、オリジンが `Content-Length` ヘッダーをレスポンスに含めたかどうかによって異なります。
+ **Content-Length ヘッダーあり** – CloudFront は、オブジェクトをオリジンから取得すると、ビューワーにオブジェクトを返します。ただし、`Content-Length` ヘッダーの値がオブジェクトのサイズに一致しない場合、CloudFront はオブジェクトをキャッシュしません。
+ **Transfer-Encoding: Chunked** – CloudFront は、オブジェクトをオリジンから取得すると、ビューワーにオブジェクトを返します。ただし、チャンクレスポンスが完了していない場合、CloudFront はオブジェクトをキャッシュしません。
+ **Content-Length ヘッダーなし** – CloudFront はオブジェクトをビューワーに返して、オブジェクトをキャッシュしますが、オブジェクトが完全でない場合があります。`Content-Length` ヘッダーがない場合、CloudFront は、TCP 接続が誤って中断されたか、または故意に中断されたかを判断できません。
`Content-Length` ヘッダーを追加して、CloudFront が不完全なオブジェクトをキャッシュしないように HTTP サーバーを設定することをお勧めします。
### CloudFront が削除または置き換える HTTP レスポンスヘッダー
CloudFront は、オリジンからのレスポンスをビューワーに転送する前に、以下のヘッダーフィールドを削除または更新します。
+ `Set-Cookie` – Cookie を転送するように CloudFront を構成している場合、`Set-Cookie` ヘッダーフィールドがクライアントに転送されます。詳細については、「[Cookie に基づいてコンテンツをキャッシュする](Cookies.md)」を参照してください。
+ `Trailer`
+ `Transfer-Encoding` – オリジンがこのヘッダーフィールドを返す場合、CloudFront は値を `chunked` に設定してビューワーにレスポンスを返します。
+ `Upgrade`
+ `Vary` – 次の点に注意してください。
+ デバイス固有のヘッダーのいずれかをオリジン (`CloudFront-Is-Desktop-Viewer`、`CloudFront-Is-Mobile-Viewer`、`CloudFront-Is-SmartTV-Viewer`、`CloudFront-Is-Tablet-Viewer`) に転送するように CloudFront を設定しており、オリジンが `Vary:User-Agent` を CloudFront に返すように設定している場合、CloudFront は `Vary:User-Agent` をビューワーに返します。詳細については、「[デバイスタイプに基づいてキャッシュを設定する](header-caching.md#header-caching-web-device)」を参照してください。
+ `Accept-Encoding` ヘッダーに、`Cookie` または `Vary` のいずれかを含めるよう設定した場合、CloudFront はビューワーへの応答にその値を含めます。
+ オリジンにヘッダーを転送するように CloudFront を設定し、`Vary` ヘッダー (例えば `Vary:Accept-Charset,Accept-Language`) の CloudFront にヘッダー名を返すようにオリジンを設定した場合、CloudFront はこれらの値を持つ `Vary` ヘッダーをビューワーに返します。
+ CloudFront が `*` ヘッダーの `Vary` 値を処理する詳細については、「[コンテンツネゴシエーション](#ResponseCustomContentNegotiation)」を参照してください。
+ `Vary` ヘッダーで他の値を含めるようにオリジンを設定している場合、CloudFront はその値を削除してからビューワーに応答を返します。
+ `Via` – CloudFront は、ビューワーへの応答で値を次のように設定します。
`Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
例えば、値は次のようになります。
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### キャッシュ可能なファイルの最大サイズ
CloudFront がキャッシュに保存するレスポンスボディの最大サイズは 50 GB です。これには、`Content-Length` ヘッダーの値を指定しないチャンク転送レスポンスが含まれます。
それぞれ 50 GB 以下のパートのオブジェクトをリクエストする範囲リクエストを使用して、このサイズを超えるオブジェクトをキャッシュするには、CloudFront を使用します。CloudFront がこれらのパートをキャッシュするのは、それぞれが 50 GB 以下であるためです。ビューワーによって、オブジェクトのすべてのパートを取得した後、元の大きなオブジェクトが再構築されます。詳しくは、「[範囲リクエストを使用して大きなオブジェクトをキャッシュする](RangeGETs.md#cache-large-objects-with-range-requests)」を参照してください。
### 使用できないオリジン
オリジンサーバーが使用できないときに、CloudFront がエッジキャッシュに存在するオブジェクトのリクエストを受け取り、そのオブジェクトが (たとえば、`Cache-Control max-age` ディレクティブに指定された期間が経過しているために) 有効期限切れになっている場合、CloudFront は有効期限切れバージョンのオブジェクトを提供するか、またはカスタムエラーページを提供します。カスタムエラーページを設定したときの CloudFront の動作の詳細については、「[カスタムエラーページが設定されている場合に CloudFront がエラーを処理する方法](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)」を参照してください。
場合によって、要求頻度の低いオブジェクトは削除されてエッジキャッシュで使用できなくなることがあります。CloudFront は、削除されたオブジェクトを提供することはできません。
### リダイレクト
オリジンサーバーでオブジェクトの場所を変更した場合、リクエストを新しい場所にリダイレクトするようにウェブサーバーを設定できます。リダイレクトを設定すると、ビューワーがオブジェクトに対するリクエストを最初に送信したときに、CloudFront はリクエストをオリジンに送信し、オリジンはリダイレクトで応答します (例: `302 Moved Temporarily`)。CloudFront はリダイレクトをキャッシュし、ビューワーにリダイレクトを返します。CloudFront はリダイレクトには従いません。
リクエストを以下のどちらかの場所にリダイレクトするようにウェブサーバーを構成できます。
+ オリジンサーバーのオブジェクトの新しい URL。ビューワーが新しい URL へのリダイレクトに従う場合、ビューワーは CloudFront をバイパスし、オリジンに直接アクセスします。したがって、オリジンにあるオブジェクトの新しい URL にリクエストをリダイレクトしないようお勧めします。
+ オブジェクトの新しい CloudFront URL。新しい CloudFront URL を含むリクエストがビューワーから送信されると、CloudFront は、オリジンの新しい場所からオブジェクトを取得し、エッジロケーションにキャッシュした後、ビューワーにオブジェクトを返します。オブジェクトに対する以降のリクエストはエッジロケーションによって処理されます。これにより、オリジンのオブジェクトを要求するビューワーに関連するレイテンシーと負荷が回避されます。ただし、オブジェクトに対する新しいリクエストごとに、CloudFront への 2 つのリクエストに対する料金がかかります。
### `Transfer-Encoding` ヘッダー
CloudFront は、`chunked` ヘッダーの `Transfer-Encoding` 値のみをサポートします。オリジンが `Transfer-Encoding: chunked` を返した場合、CloudFront は、エッジロケーションで受け取ったオブジェクトをクライアントに返し、そのオブジェクトをチャンク形式でキャッシュして後続のリクエストに備えます。
ビューワーが `Range GET` をリクエストし、オリジンが `Transfer-Encoding: chunked` を返す場合、CloudFront はリクエストされた範囲ではなくオブジェクト全体をビューワーに返します。
レスポンスのコンテンツ長を事前に決定できない場合は、チャンクエンコーディングを使用することをお勧めします。詳細については、「[中断された TCP 接続](#ResponseCustomDroppedTCPConnections)」を参照してください。
# オリジングループに対するリクエストとレスポンスの動作
オリジングループへのリクエストは、オリジングループとして設定されていないオリジンへのリクエストと同じように機能します。ただし、オリジンフェイルオーバーがある場合を除きます。他のオリジンと同様に、CloudFront がリクエストを受信し、コンテンツがすでにエッジロケーションにキャッシュされている場合、コンテンツはキャッシュからビューワーに配信されます。キャッシュミスがあり、オリジンがオリジングループである場合、ビューワーリクエストはオリジングループ内のプライマリオリジンに転送されます。
プライマリオリジンのリクエストとレスポンスの動作は、オリジングループにないオリジンの場合と同じです。詳細については、「[Amazon S3 オリジンに対するリクエストとレスポンスの動作](RequestAndResponseBehaviorS3Origin.md)」および「[カスタムオリジンの場合のリクエストおよびレスポンスの動作](RequestAndResponseBehaviorCustomOrigin.md)」を参照してください。
以下にプライマリオリジンが特定の HTTP ステータスコードを返す場合のオリジンフェイルオーバーの動作を示します。
+ HTTP 2xx ステータスコード (成功): CloudFront は、ファイルをキャッシュしてビューワーに返します。
+ HTTP 3xx ステータスコード (リダイレクト): CloudFront は、ステータスコードをビューワーに返します。
+ HTTP 4xx または 5xx ステータスコード (クライアント/サーバーエラー): 返されたステータスコードがフェイルオーバー用に設定されている場合、CloudFront はオリジングループのセカンダリオリジンに同じリクエストを送信します。
+ HTTP 4xx または 5xx ステータスコード (クライアント/サーバーエラー): 返されたステータスコードがフェイルオーバー用に設定されていない場合、CloudFront はビューワーにエラーを返します。
CloudFront は、ビューワーリクエストの HTTP メソッドが `GET`、`HEAD`、または `OPTIONS` の場合にのみ、セカンダリオリジンにフェイルオーバーします。ビューワーが別の HTTP メソッド (たとえば `POST` や `PUT` など) を送信しても、CloudFront はフェイルオーバーしません。
CloudFront がセカンダリオリジンにリクエストを送信する場合、レスポンスの動作は、オリジングループにない CloudFront オリジンの場合と同じです。
オリジングループの詳細については、「[CloudFront オリジンフェイルオーバーを使用して高可用性を最適化する](high_availability_origin_failover.md)」を参照してください。
# オリジンリクエストにカスタムヘッダーを追加する
オリジンに送信するリクエストにカスタムヘッダーを追加するように CloudFront を設定できます。カスタムヘッダーを使用すると、一般的なビューワーリクエストでは得られない情報をオリジンから送信および収集できます。ヘッダーは、オリジンごとにカスタマイズすることもできます。CloudFront は、カスタムオリジンと Amazon S3 オリジンの両方でカスタムヘッダーをサポートしています。
**Contents**
+ [ユースケース](#add-origin-custom-headers-use-cases)
+ [オリジンリクエストにカスタムヘッダーを追加するように CloudFront を設定する](#add-origin-custom-headers-configure)
+ [CloudFront でオリジンリクエストに追加できないカスタムヘッダー](#add-origin-custom-headers-denylist)
+ [`Authorization` ヘッダーを転送するように CloudFront を設定する](#add-origin-custom-headers-forward-authorization)
## ユースケース
カスタムヘッダーは、以下の例に示すように使用できます。
**CloudFront からのリクエストの識別**
オリジンが CloudFront から受け取るリクエストを識別できます。これは、ユーザーが CloudFront をバイパスするかどうかを知りたい場合、または複数の CDN を使用してどのリクエストが CDN から来ているのかを知りたい場合に役立つ可能性があります。
Amazon S3 オリジンを使用して、[Amazon S3 サーバーアクセスログ](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)を有効にした場合、ログにヘッダー情報は含まれません。
**特定のディストリビューションから送信されたリクエストの判断**
同じオリジンを使用するように複数の CloudFront ディストリビューションを設定する場合は、ディストリビューションごとに異なるカスタムヘッダーを追加できます。その後、オリジンからのログを使用して、どのリクエストがどの CloudFront ディストリビューションから来たのかを判断できます。
**Cross-Origin Resource Sharing (CORS) の有効化**
ビューワーの一部が Cross-Origin Resource Sharing (CORS) をサポートしていない場合は、オリジンに送信されるリクエストに `Origin` ヘッダーを常に追加するように CloudFront を設定できます。次に、リクエストごとに `Access-Control-Allow-Origin` ヘッダーを返すようにオリジンを設定できます。[CORS 設定を適用するように CloudFront を設定する](header-caching.md#header-caching-web-cors)必要もあります。
**コンテンツへのアクセス制御**
カスタムヘッダーを使用して、コンテンツへのアクセスを制御できます。CloudFront によって追加されたカスタムヘッダーが含まれている場合にのみリクエストに応答するようオリジンを設定することで、ユーザーが CloudFront をバイパスして、オリジンで直接コンテンツにアクセスすることを防ぐことができます。詳細については、「[カスタムオリジンのファイルへのアクセスを制限する](private-content-overview.md#forward-custom-headers-restrict-access)」を参照してください。
## オリジンリクエストにカスタムヘッダーを追加するように CloudFront を設定する
オリジンに送信されるリクエストにカスタムヘッダーを追加するようディストリビューションを設定するには、次のいずれかの方法を使用してオリジン設定を更新します。
+ **CloudFront コンソール** – ディストリビューションを作成または更新する場合、**[カスタムヘッダーを追加]** 設定でヘッダー名と値を指定します。詳細については、「[カスタムヘッダーを追加する](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders)」を参照してください。
+ **CloudFront API** – カスタムヘッダーを追加するオリジンごとに、`Origin` 内の `CustomHeaders` フィールドでヘッダー名と値を指定します。詳細については、「Amazon CloudFront API リファレンス」の「[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)」または「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。**
指定するヘッダーの名前と値がまだビューワーのリクエストに存在しない場合、CloudFront がそれらをオリジンリクエストに追加します。ヘッダーが存在する場合、CloudFront はリクエストをオリジンに転送する前にヘッダー値を上書きします。
オリジンカスタムヘッダーに適用されるクォータについては、「[ヘッダーのクォータ](cloudfront-limits.md#limits-custom-headers)」を参照してください。
## CloudFront でオリジンリクエストに追加できないカスタムヘッダー
オリジンに送信されるリクエストに以下のヘッダーを追加するように CloudFront を設定することはできません。
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ `X-Amz-` で始まるヘッダー
+ `X-Edge-` で始まるヘッダー
+ `X-Real-Ip`
## `Authorization` ヘッダーを転送するように CloudFront を設定する
ビューワーリクエストをオリジンに転送する際、CloudFront はデフォルトで一部のビューワーヘッダー (`Authorization` ヘッダーを含む) を削除します。オリジンがオリジンリクエストの `Authorization` ヘッダーを常に受け取るようにするには、次のオプションがあります。
+ キャッシュポリシーを使用して、`Authorization` ヘッダーをキャッシュキーに追加します。キャッシュキー内のすべてのヘッダーは、オリジンリクエストに自動的に含まれます。詳細については、「[ポリシーを使用してキャッシュキーを制御する](controlling-the-cache-key.md)」を参照してください。
+ オリジンリクエストポリシーを使用し、すべてのビューワーヘッダーをオリジンに転送します。オリジンリクエストポリシーで `Authorization` ヘッダーを個別に転送することはできません。ただし、ビューワーヘッダーをすべて転送する場合には、`Authorization` ヘッダーが CloudFront によりビューワーリクエストに含められます。CloudFront では、このユースケースのために、**Managed-AllViewer** と呼ばれるマネージド型のオリジンリクエストポリシーが提供されています。詳細については、「[マネージドオリジンリクエストポリシーを使用する](using-managed-origin-request-policies.md)」を参照してください。
# CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法
大きなオブジェクトの場合、ビューワー (ウェブブラウザまたはその他のクライアント) は、複数の`GET` リクエストを実行し、`Range` リクエストヘッダーを使用して、小さいパートでオブジェクトをダウンロードできます。`Range GET` リクエストとも呼ばれるこのバイト範囲のリクエストでは、部分的なダウンロードの効率、および部分的に失敗した転送からの回復の効率が向上します。
CloudFront は `Range GET` リクエストを受け取ると、そのリクエストを受け取ったエッジロケーションのキャッシュをチェックします。そのエッジロケーションのキャッシュに、オブジェクト全体またはオブジェクトの要求されたパートがすでに含まれている場合、CloudFront は要求された範囲をキャッシュから直ちに提供します。
要求された範囲がキャッシュに含まれていない場合、CloudFront はリクエストをオリジンに転送します。(パフォーマンスを最適化するために、CloudFront は、`Range GET` でクライアントから要求された範囲よりも大きい範囲を要求する場合があります)。次に実行される処理は、オリジンが `Range GET` リクエストをサポートするかどうかによって異なります。
+ **オリジンが `Range GET` リクエストをサポートする場合:** 要求した範囲が返されます。CloudFront は要求された範囲を提供し、今後のリクエストのためにその範囲をキャッシュします。(Amazon S3 も多くの HTTP サーバーも `Range GET` リクエストをサポートしています)。
+ **オリジンが `Range GET` リクエストをサポートしない場合:** オブジェクト全体が返されます。CloudFront は、オブジェクト全体を送信して現在のリクエストを処理し、今後のリクエストのためにオブジェクトをキャッシュします。CloudFront はオブジェクト全体をエッジキャッシュにキャッシュした後、要求された範囲を提供することで新しい `Range GET` リクエストに応答します。
どちらの場合も、CloudFront は、オリジンから 1 バイト目が到着した直後に、要求された範囲またはオブジェクトをエンドユーザーに供給します。
**注記**
ビューワーが `Range GET` をリクエストし、オリジンが `Transfer-Encoding: chunked` を返す場合、CloudFront はリクエストされた範囲ではなくオブジェクト全体をビューワーに返します。
通常、CloudFront は、`Range` ヘッダーの RFC 仕様に準拠します。ただし、`Range` ヘッダーが以下の要件に準拠しない場合、CloudFront は、指定された範囲とステータスコード `200` を返す代わりに、完全なオブジェクトと HTTP ステータスコード `206` を返します。
+ 範囲は昇順に指定されている必要があります。たとえば、`100-200,300-400` は有効で、`300-400,100-200` は無効です。
+ 範囲は重複できません。たとえば、`100-200,150-250` は無効です。
+ すべての範囲指定が有効である必要があります。たとえば、範囲の一部に負の値を指定することはできません。
`Range`リクエストヘッダーの詳細については、RFC 7233 の「[範囲リクエスト](https://httpwg.org/specs/rfc7233.html#range.requests)」または MDN Web ドキュメントの「[範囲](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range)」を参照してください。
## 範囲リクエストを使用して大きなオブジェクトをキャッシュする
キャッシュが有効になっている場合、CloudFront では 50 GB を超えるオブジェクトは取得またはキャッシュされません。オリジンによって、オブジェクトがこのサイズを超えていることが示される場合 (`Content-Length`レスポンスヘッダーで)、CloudFront はオリジンへの接続を閉じて、ビューワーにエラーを返します。(キャッシュを無効にすることで、CloudFront はオリジンからこのサイズを超えるオブジェクトを取得し、それをビューワーに転送できます。ただし、CloudFront でオブジェクトはキャッシュされません)。
ただし、範囲リクエストで CloudFront を使用して[キャッシュ可能な最大ファイルサイズ](cloudfront-limits.md#limits-web-distributions)を超えるサイズのオブジェクトをキャッシュできます。
**Example 例**
1. 100 GB のオブジェクトを持つオリジンについて考えてみます。キャッシュが有効になっている場合、CloudFront では、オブジェクトはこの大きさで取得またはキャッシュされません。ただし、ビューワーは複数の範囲リクエストを送信することにより、それぞれサイズが 50 GB 未満のパートを使用して、このパートのオブジェクトを取得できます。
1. ビューワーは、オブジェクトを 20 GB のパートに分けてリクエストする場合、ヘッダー `Range: bytes=0-21474836480` を使用したリクエストを送信して最初のパートを取得し、次にヘッダー `Range: bytes=21474836481-42949672960` を使用した別のリクエストで次のパートを取得できます。以下同様です。
1. ビューワーがすべてのパートを受信すると、それらを組み合わせて元の 100 GB のオブジェクトを構築できます。
1. この場合、CloudFront はそれぞれ 20 GB のパートのオブジェクトをキャッシュし、キャッシュの同じパートの後続リクエストに対応できます。
圧縮されたオブジェクトに対する範囲リクエストの場合、バイト範囲リクエストはオブジェクトの元のサイズではなく、圧縮されたサイズに基づいています。ファイルの圧縮に関する詳細については、「[圧縮ファイルを供給する](ServingCompressedFiles.md)」を参照してください。
# CloudFront がオリジンからの HTTP 3xx ステータスコードを処理する方法
CloudFront が Amazon S3 バケットまたはカスタムオリジンサーバーのオブジェクトをリクエストすると、オリジンサーバーは HTTP 3xx ステータスコードを返すことがあります。これは、次のいずれかを示しています。
+ オブジェクトの URL が変更された (たとえば、ステータスコード 301、302、307、308)
+ 前回 CloudFront がリクエストしてからオブジェクトが変更されていない (ステータスコード 304)
CloudFront は、CloudFront ディストリビューションの設定とレスポンスのヘッダーに従って 3xx レスポンスをキャッシュします。CloudFront は、オリジンからの応答に `Cache-Control` ヘッダーを含めた場合のみ、307 応答と 308 応答をキャッシュします。詳細については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
オリジンからリダイレクトステータスコード (301 や 307 など) が返された場合、CloudFront はリダイレクトに従いません。CloudFront は、301 または 307 レスポンスをビューワーに渡します。ビューワーは、新しいリクエストを送信することでリダイレクトに従うことができます。
# CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理する方法
CloudFront が Amazon S3 バケットまたはカスタムオリジンサーバーのオブジェクトをリクエストすると、オリジンサーバーは HTTP 4xx または 5xx ステータスコードを返すことがあります。このステータスコードは、エラーが発生したことを示します。CloudFront の動作は、以下の条件によって左右されます。
+ カスタムエラーページを設定しているかどうか
+ オリジンからのエラーレスポンスを CloudFront がキャッシュする期間 (エラーキャッシュの最小 TTL) を設定しているかどうか
+ ステータスコード
+ 5xx ステータスコードの場合、リクエストされたオブジェクトが現在 CloudFront エッジキャッシュにあるかどうか
+ 一部の 4xx ステータスコードの場合、オリジンが `Cache-Control max-age` または `Cache-Control s-maxage` ヘッダーを返すかどうか
CloudFront は、`GET` リクエストと `HEAD` リクエストへの応答を常にキャッシュします。`OPTIONS` リクエストへの応答をキャッシュするように CloudFront を設定することもできます。CloudFront はその他のメソッドを使用するリクエストへのレスポンスをキャッシュしません。
オリジンが応答しない場合、オリジンへの CloudFront リクエストはタイムアウトし、オリジンからの HTTP 5xx エラーと見なされます。これは、オリジンからそのエラーが返されなくても同様です。そのシナリオでは、CloudFront はキャッシュされたコンテンツを引き続き提供します。詳細については、「[使用できないオリジン](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable)」を参照してください。
ログ作成を有効にしている場合、CloudFront は、HTTP ステータスコードに関係なく結果をログに書き込みます。
CloudFront から返されるエラーメッセージに関連する機能とオプションの詳細については、以下を参照してください。
+ CloudFront コンソールでのカスタムエラーページの設定の詳細については、「[カスタムエラーページとエラーキャッシュ](DownloadDistValuesErrorPages.md)」を参照してください。
+ CloudFront コンソールでのエラーキャッシュ最小 TTL の詳細については、「[Error caching minimum TTL (seconds) (エラーキャッシュ最小 TTL (秒))](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)」を参照してください。
+ CloudFront がキャッシュする HTTP ステータスコードのリストについては、「[CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード](#HTTPStatusCodes-cached-errors)」を参照してください。
**Topics**
+ [カスタムエラーページが設定されている場合に CloudFront がエラーを処理する方法](#HTTPStatusCodes-custom-error-pages)
+ [カスタムエラーページが設定されていない場合に CloudFront がエラーを処理する方法](#HTTPStatusCodes-no-custom-error-pages)
+ [CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード](#HTTPStatusCodes-cached-errors)
## カスタムエラーページが設定されている場合に CloudFront がエラーを処理する方法
カスタムエラーページを設定している場合、CloudFront の動作は、リクエストされたオブジェクトがエッジキャッシュにあるかどうかによって異なります。
### リクエストされたオブジェクトがエッジキャッシュにない場合
CloudFront は、以下のすべてが該当する場合に、オリジンからリクエストされたオブジェクトの取得を試行し続けます。
+ ビューワーがオブジェクトを要求する
+ オブジェクトがエッジキャッシュにない
+ オリジンが HTTP 4xx または 5xx ステータスコードを返して、以下のいずれかに該当する:
+ オリジンがステータスコード 304 (変更なし) またはオブジェクトの更新バージョンを返す代わりに HTTP 5xx ステータスコードを返す
+ オリジンが、キャッシュコントロールヘッダーによって制限されておらず、以下のステータスコードのリストに含まれている HTTP 4xx ステータスコードを返す: [CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード](#HTTPStatusCodes-cached-errors)。
+ オリジンが `Cache-Control max-age` ヘッダーまたは `Cache-Control s-maxage` ヘッダーで HTTP 4xx ステータスコードを返す。ステータスコードは、次のステータスコードの一覧に含まれる: コントロール [CloudFront が `Cache-Control` ヘッダーに基づいてキャッシュする HTTP 4xx ステータスコード](#HTTPStatusCodes-cached-errors-with-cache-control)。
**CloudFront は以下の処理を行います。**
1. ビューワーからリクエストを受け取った CloudFront エッジキャッシュで、CloudFront はディストリビューション設定を確認し、オリジンから返されたステータスコードに対応するカスタムエラーページのパスを取得します。
1. CloudFront は、カスタムエラーページのパスと一致するパスパターンを持つ、ディストリビューション内の最初のキャッシュ動作を検索します。
1. CloudFront エッジロケーションは、キャッシュ動作に指定されているオリジンに、カスタムエラーページのリクエストを送信します。
1. オリジンはカスタムエラーページをエッジロケーションに返します。
1. CloudFront は、リクエストを送信したビューワーにカスタムエラーページを返します。また、最大で次の値になるようにカスタムエラーページをキャッシュします。
+ エラーキャッシュ最小 TTL で指定された時間の長さ (デフォルトでは 10 秒)
+ `Cache-Control max-age` ヘッダー、または最初のリクエストがエラーを生成したときに発信元から返された `Cache-Control s-maxage` ヘッダーで指定された時間
1. キャッシュ時間 (ステップ 5 で決定されます) が経過すると、CloudFront はオリジンに別のリクエストを転送して、リクエストされたオブジェクトの取得を再試行します。CloudFront は、エラーキャッシュ最小 TTL に指定された間隔で再試行し続けます。
**注記**
同じカスタムエラーページにキャッシュ動作も設定した場合、CloudFront は代わりにキャッシュ動作 TTL を使用します。この場合、CloudFront はステップ 5 と 6 で以下を実行します。
CloudFront がリクエストを行ったビューワーにカスタムエラーページを返した後、CloudFront はキャッシュ動作 TTL をチェックします (例えば、デフォルトの TTL を 5 秒に設定した場合)。その後、CloudFront はカスタムエラーページをその最大値までキャッシュします。
5 秒経過すると、CloudFront はオリジンからカスタムエラーページを再度取得します。CloudFront は、キャッシュ動作 TTL に指定された間隔で再試行し続けます。
詳細については、「キャッシュ動作 [TTL 設定](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)」を参照してください。
### リクエストされたオブジェクトがエッジキャッシュにある場合
CloudFront は、以下のすべてに該当する場合に、現在エッジキャッシュに存在するオブジェクトを引き続き提供します。
+ ビューワーがオブジェクトを要求する
+ オブジェクトがエッジキャッシュに存在するが有効期限が切れている
+ オリジンがステータスコード 304 (変更なし) またはオブジェクトの更新バージョンを返す代わりに HTTP 5xx ステータスコードを返す
**CloudFront は以下の処理を行います。**
1. オリジンが 5xx ステータスコードを返した場合、CloudFront はオブジェクトの有効期限が切れていても、そのオブジェクトを返します。エラーキャッシュ最小 TTL の期間、CloudFront は、エッジキャッシュからオブジェクトを提供することで、ビューワーリクエストに対して応答し続けます。
オリジンが 4xx ステータスコードを返した場合、CloudFront はリクエストされたオブジェクトではなく、ステータスコードをビューワーに返します。
1. エラーキャッシュ最小 TTL が経過すると、CloudFront はオリジンに別のリクエストを転送して、リクエストされたオブジェクトの取得を再試行します。オブジェクトが頻繁にリクエストされない場合、CloudFront はそのオブジェクトをエッジキャッシュから削除することがありますが、オリジンサーバーは引き続き 5xx レスポンスを返します。オブジェクトが CloudFront エッジキャッシュに保持される期間については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
## カスタムエラーページが設定されていない場合に CloudFront がエラーを処理する方法
カスタムエラーページを設定していない場合、CloudFront の動作は、リクエストされたオブジェクトがエッジキャッシュにあるかどうかによって異なります。
**Topics**
+ [リクエストされたオブジェクトがエッジキャッシュにない場合](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [リクエストされたオブジェクトがエッジキャッシュにある場合](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### リクエストされたオブジェクトがエッジキャッシュにない場合
CloudFront は、以下のすべてが該当する場合に、オリジンからリクエストされたオブジェクトの取得を試行し続けます。
+ ビューワーがオブジェクトを要求する
+ オブジェクトがエッジキャッシュにない
+ オリジンが HTTP 4xx または 5xx ステータスコードを返して、以下のいずれかに該当する:
+ オリジンがステータスコード 304 (変更なし) またはオブジェクトの更新バージョンを返す代わりに HTTP 5xx ステータスコードを返す
+ オリジンがキャッシュコントロールヘッダーによって制限されておらず、以下のステータスコードのリストに含まれている HTTP 4xx ステータスコードを返す: [CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード](#HTTPStatusCodes-cached-errors)。
+ オリジンが `Cache-Control max-age` ヘッダーまたは `Cache-Control s-maxage` ヘッダーで HTTP 4xx ステータスコードを返す。ステータスコードは、次のステータスコードの一覧に含まれる: コントロール [CloudFront が `Cache-Control` ヘッダーに基づいてキャッシュする HTTP 4xx ステータスコード](#HTTPStatusCodes-cached-errors-with-cache-control)。
CloudFront は以下の処理を行います。
1. CloudFront は 4xx または 5xx のステータスコードをビューワーに返します。また、次の最大値のリクエストを受け取ったエッジキャッシュにステータスコードをキャッシュします。
+ エラーキャッシュ最小 TTL で指定された時間の長さ (デフォルトでは 10 秒)
+ `Cache-Control max-age` ヘッダー、または最初のリクエストがエラーを生成したときに発信元から返された `Cache-Control s-maxage` ヘッダーで指定された時間
1. キャッシュ時間の期間 (ステップ 1 で決定されます) では、CloudFront はキャッシュされた 4xx または 5xx のステータスコードを使用して、同じオブジェクトに対する後続のビューワーリクエストに応答します。
1. キャッシュ時間 (ステップ 1 で決定されます) が経過すると、CloudFront はオリジンに別のリクエストを転送して、リクエストされたオブジェクトの取得を再試行します。CloudFront は、エラーキャッシュ最小 TTL に指定された間隔で再試行し続けます。
### リクエストされたオブジェクトがエッジキャッシュにある場合
CloudFront は、以下のすべてに該当する場合に、現在エッジキャッシュに存在するオブジェクトを引き続き提供します。
+ ビューワーがオブジェクトを要求する
+ オブジェクトがエッジキャッシュに存在するが有効期限が切れている これは、オブジェクトが*古く*なっていることを意味します。
+ オリジンがステータスコード 304 (変更なし) またはオブジェクトの更新バージョンを返す代わりに HTTP 5xx ステータスコードを返す
CloudFront は以下の処理を行います。
1. オリジンが 5xx のエラーコードを返した場合、CloudFront は、オブジェクトの有効期限が切れていても、そのオブジェクトを返します。エラーキャッシュ最小 TTL 時間 (デフォルトでは 10 秒) の間、CloudFront は、エッジキャッシュからオブジェクトを提供することで、ビューワーからのリクエストに応答し続けます。
オリジンが 4xx ステータスコードを返した場合、CloudFront はリクエストされたオブジェクトではなく、ステータスコードをビューワーに返します。
1. エラーキャッシュ最小 TTL が経過すると、CloudFront はオリジンに別のリクエストを転送して、リクエストされたオブジェクトの取得を再試行します。オブジェクトが頻繁にリクエストされていない場合、オリジンサーバーがまだ 5xx レスポンスを返している間に、CloudFront がエッジキャッシュからオブジェクトを削除することがあります。詳細については、「[コンテンツをキャッシュに保持する期間 (有効期限) を管理する](Expiration.md)」を参照してください。
**ヒント**
`stale-if-error` または `Stale-While-Revalidate` ディレクティブを設定する場合は、古いオブジェクトをエッジキャッシュで使用できる期間を指定できます。これにより、オリジンが使用できない場合でも、ビューワーにコンテンツを提供し続けることができます。詳細については、「[古い (期限切れの) コンテンツを提供する](Expiration.md#stale-content)」を参照してください。
CloudFront は、指定された[最大 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 値まで古いオブジェクトのみを提供します。この期間を過ぎると、オブジェクトはエッジキャッシュから使用できなくなります。
## CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード
CloudFront は、返された特定のステータスコードと、オリジンがレスポンスで特定のヘッダーを返すかどうかに応じて、オリジンから返された HTTP 4xx と 5xx ステータスコードをキャッシュします。
CloudFront は、オリジンから返される以下の HTTP 4xx および 5xx ステータスコードを常にキャッシュします。HTTP ステータスコードのカスタムエラーページを設定している場合、CloudFront はカスタムエラーページをキャッシュします。
**注記**
[CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) マネージドキャッシュポリシーを仕様している場合、CloudFront はこのようなステータスコードやカスタムエラーページをキャッシュしません。
| | |
| --- |--- |
| 404 | Not Found |
| 414 | Request-URI Too Large |
| 500 | Internal Server Error |
| 501 | Not Implemented |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
| 504 | Gateway Time-out |
### CloudFront が `Cache-Control` ヘッダーに基づいてキャッシュする HTTP 4xx ステータスコード
オリジンが `Cache-Control max-age` または `Cache-Control s-maxage` ヘッダーを返す場合、CloudFront は以下の HTTP 4 xx ステータスコードのみをキャッシュします。これらの HTTP ステータスコードのいずれかについてカスタムエラーページを設定しており、オリジンがキャッシュコントロールヘッダーのいずれかを返す場合、CloudFront はカスタムエラーページをキャッシュします。
| | |
| --- |--- |
| 400 | Bad Request |
| 403 | Forbidden |
| 405 | Method Not Allowed |
| 412¹ | Precondition Failed |
| 415¹ | Unsupported Media Type |
¹CloudFront は、これらの HTTP ステータスコードに対するカスタムエラーページの作成をサポートしていません。
# カスタムエラーレスポンスを生成する
CloudFront から配信されているオブジェクトが何らかの理由で使用できなくなった場合、これを伝えるために、通常はウェブサーバーから、関連する HTTP ステータスコードが CloudFront に返されます。例えば、ビューワーが無効な URL をリクエストした場合、HTTP 404 (Not Found) ステータスコードがウェブサーバーから CloudFront に返され、さらに CloudFront からビューワーに返されます。このデフォルトのエラーレスポンスを使用する代わりに、カスタムレスポンスを作成して CloudFront からビューワーに返すことができます。
HTTP ステータスコードの代わりにカスタムエラーページを返すように CloudFront を構成していても、カスタムエラーページが利用できない場合には、CloudFront は、カスタムエラーページを持つオリジンから受信したステータスコードをビューワーに返します。たとえば、カスタムオリジンから 500 ステータスコードが返され、500 ステータスコードのためのカスタムエラーページを Amazon S3 バケットから取得するように CloudFront を構成してあるとします。しかし、誰かが間違えてカスタムエラーページを Amazon S3 バケットから削除してしまいました。この場合 CloudFront は、そのオブジェクトをリクエストしたビューワーに対して、HTTP 404 ステータスコード (Not found) を返します。
CloudFront がカスタムエラーページをビューワーに返したときに、リクエストしたオブジェクトの料金ではなく、カスタムエラーページの標準 CloudFront 料金を支払います。CloudFront の料金の詳細については、「[Amazon CloudFront 料金表](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
**Topics**
+ [エラーレスポンスの動作を設定する](custom-error-pages-procedure.md)
+ [HTTP ステータスコード別のカスタムエラーページを作成する](creating-custom-error-pages.md)
+ [オブジェクトとカスタムエラーページを別々の場所に保存する](custom-error-pages-different-locations.md)
+ [CloudFront から返されるレスポンスコードを変更する](custom-error-pages-response-code.md)
+ [CloudFront がエラーをキャッシュする時間を制御する](custom-error-pages-expiration.md)
# エラーレスポンスの動作を設定する
エラーが発生した場合に CloudFront がどのように対応するかを管理するための、いくつかのオプションがあります。カスタムエラーレスポンスの設定は、CloudFront コンソール、CloudFront API、または から行えますCloudFormation これらの内どれにより設定を更新する場合でも、次に挙げるヒントと推奨事項を参考にしてください。
+ カスタムエラーページは、CloudFront からのアクセスが可能な場所に保存します。これらのページの保存先は、Amazon S3 バケットにすることを推奨します。また、[ウェブサイトやアプリケーションなど、他のコンテンツと同じ場所には保存しないようにしてください](custom-error-pages-different-locations.md)。カスタムエラーページが、ウェブサイトやアプリケーションと同じオリジンに保存されている場合、オリジンのサーバーが使用不能になり 5xx エラーが返信されるようになると、CloudFront は、その使用不能なオリジンからカスタムエラーページを取得できなくなります。詳細については、「」を参照してください[オブジェクトとカスタムエラーページを別々の場所に保存する](custom-error-pages-different-locations.md)
+ CloudFront にカスタムエラーページを取得するための権限があることを確認します。カスタムエラーページを Amazon S3 に保存している場合、そのページがパブリックにアクセスが可能であるか、CloudFront の[オリジンアクセスコントロール (OAI)](private-content-restricting-access-to-s3.md) を設定する必要があります。カスタムエラーページをカスタムオリジンに格納する場合には、そのページはパブリックにアクセス可能である必要があります。
+ (オプション) 必要に応じてオリジンを設定し、カスタムエラーページに `Cache-Control` または `Expires` ヘッダーを追加します。また、**エラーキャッシュ最小 TTL** 設定を使用して、CloudFront がカスタムエラーページをキャッシュに保持する時間を制御することもできます。詳細については、「[CloudFront がエラーをキャッシュする時間を制御する](custom-error-pages-expiration.md)」を参照してください。
## カスタムエラーレスポンスを設定する
CloudFront コンソールからカスタムエラーレスポンスを設定するには、CloudFront ディストリビューションが必要です。コンソールからカスタムエラーレスポンスの構成を設定する際には、ディストリビューションが既に用意されている必要があります。ディストリビューションの作成方法については、「[CloudFront 標準ディストリビューションの開始方法](GettingStarted.SimpleDistribution.md)」を参照してください。
------
#### [ Console ]
**カスタムエラーレスポンスを設定するには (コンソール)**
1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions)の CloudFront コンソールで [**ディストリビューション**] ページを開きます。
1. ディストリビューションの一覧で、更新するディストリビューションを選択します。
1. [**エラーページ**] タブを開き、[**カスタムエラーレスポンスの作成**] をクリックします。
1. 適切な値を入力します。詳細については、「[カスタムエラーページとエラーキャッシュ](DownloadDistValuesErrorPages.md)」を参照してください。
1. 必要な値を入力したら、[**作成**] をクリックします。
------
#### [ CloudFront API or CloudFormation ]
CloudFront API または CloudFormation でカスタムエラーレスポンスを設定するには、`CustomErrorResponse` タイプのディストリビューションを使用します。詳細については、以下を参照してください。
+ [AWS:: CloudFront:: ディストリビューション CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) (*AWS CloudFormation ユーザーガイド*)
+ *Amazon CloudFront API リファレンス*の「[CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)」
------
# HTTP ステータスコード別のカスタムエラーページを作成する
デフォルト (ウェブサイト内の他のページと同じ書式設定) のメッセージではなく、カスタムエラーメッセージを表示させたい場合は、そのカスタムエラーメッセージを含むオブジェクト (HTML ファイルなど) を、CloudFront からビューワーに返すようにもできます。
返信させたい特定のファイルや、ファイルの返信の対象となるエラーを指定するには、CloudFront ディストリビューションを更新してそれらの値を指定します。詳細については、「」を参照してください[エラーレスポンスの動作を設定する](custom-error-pages-procedure.md)
例として、カスタムエラーページは次のようなものになります。
![\[カスタム AWS 404 ページの例のスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
サポートされている HTTP ステータスコードごとに異なるオブジェクトを指定することができます。または、サポートされているすべてのステータスコードに同じオブジェクトを使用することもできます。一部のステータスコードにカスタムエラーページを指定し、他のステータスコードには指定しないようにもできます。
CloudFront を通して供給されているオブジェクトは、様々な理由で使用できなくなることがあります。理由は、大きく 2 つに分類できます。以下にそれぞれを説明します。
+ *クライアントエラー*は、リクエストに問題があることを示します。たとえば、指定した名前のオブジェクトが使用不能である場合や、Amazon S3 バケット内のオブジェクトを取得するために必要な権限がユーザーにない場合などです。クライアントエラーが発生すると、オリジンは 400 番台の HTTP ステータスコードを CloudFront に返します。
+ *サーバーエラー*の場合は、オリジンサーバーに問題があります。たとえば、HTTP サーバーが混雑していたり使用不能であったりする場合です。サーバーエラーが発生すると、オリジンサーバーから 500 番台の HTTP ステータスコードが CloudFront に返されます。あるいは、オリジンサーバーから一定の時間内で CloudFront にレスポンスが届かないということで、504 ステータスコード (ゲートウェイタイムアウト) として処理されます。
CloudFront がカスタムエラーページを返すことのできる HTTP ステータスコードは、以下のとおりです。
+ 400、403、404、405、414、416
+ 500、501、502、503、504
**注意事項**
CloudFront は、リクエストが安全でない可能性があることを検出した場合、カスタムエラーページの代わりに 400 (不正なリクエスト) エラーを返します。
リクエストされた範囲は不適格であることを示す HTTP ステータスコード 416 (Requested Range Not Satisfiable) のカスタムエラーページを作成したり、オリジンが CloudFront にステータスコード 416 を返すと CloudFront がビューワーに返す HTTP ステータスコードを変更したりできます。詳細については、「[CloudFront から返されるレスポンスコードを変更する](custom-error-pages-response-code.md)」を参照してください。ただし、CloudFront はステータスコード 416 のレスポンスをキャッシュしないため、ステータスコード 416 に対して **[Error Caching Minimum TTL]** (エラーキャッシュの最小 TTL) の値を指定しても、CloudFront はそれを使用しません。
また、CloudFront で HTTP 503 ステータスコードのカスタムエラーページを設定していても、それが返されないケースもあり得ます。CloudFront エラーコードが `Capacity Exceeded` または `Limit Exceeded` の場合、CloudFront はカスタムエラーページを使用せずに 503 ステータスコードをビューワーに返します。
カスタムエラーページを作成した場合、CloudFront は以下のレスポンスコードに対して `Connection: close` または `Connection: keep-alive` を返します。
CloudFront は、ステータスコード 400、405、414、416、500、501 に対して `Connection: close` を返す。
CloudFront は、ステータスコード 403、404、502、503、504 に対して `Connection: keep-alive` を返す。
CloudFront がオリジンからのエラーレスポンスを処理する方法の詳細な説明は、「[CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理する方法](HTTPStatusCodes.md)」を参照してください。
# オブジェクトとカスタムエラーページを別々の場所に保存する
オブジェクトとカスタムエラーページを別の場所に保存する場合は、次の状況に該当するときに適用されるキャッシュ動作をディストリビューションに組み込む必要があります。
+ [**Path Pattern (パスパターン)**] の値が、カスタムエラーメッセージのパスと一致している。たとえば、4xx エラーのカスタムエラーページを `/4xx-errors` というディレクトリの Amazon S3 バケットに保存したとします。このとき、パスパターンによってカスタムエラーページのリクエストがルーティングされる場所のキャッシュ動作を、ディストリビューションに組み込む必要があります (`/4xx-errors/*` など)。
+ [**Origin (オリジン)**] の値は、カスタムエラーページが含まれているオリジンの [**Origin ID (オリジン ID)**] の値を指定しています。
詳細については、「[キャッシュ動作の設定](DownloadDistValuesCacheBehavior.md)」を参照してください。
# CloudFront から返されるレスポンスコードを変更する
CloudFront がオリジンから受信したものとは異なる HTTP ステータスコードを、ビューワーに返すように CloudFront を設定できます。たとえば、オリジンから 500 ステータスコードが CloudFront に返されるときに、CloudFront からカスタムエラーページと 200 ステータスコード (OK) がビューワーに返されるようにしたいことがあります。さまざまな理由で、オリジンから CloudFront に返されるステータスコードとは異なるステータスコードが CloudFront からビューワーに返されることが必要になる場合があります。
+ インターネットデバイス (一部のファイアウォールやコーポレートプロキシなど) の中には、HTTP 400 番台と 500 番台のステータスコードを遮断して、このレスポンスがビューワーに返信されないようするものがあります。このシナリオの場合、`200` に置換することで、応答は遮断されなくなります。
+ クライアントエラーとサーバーエラーの種類による区別が必要ない場合、CloudFront が返す 4xx および 5xx のステータスコードのすべてで、値を `400` または `500` とするようにも指定できます。
+ `200` ステータスコード (OK) と静的ウェブサイトを返すことにより、ウェブサイトが停止していることをユーザーが気づかないようにもできます。
[CloudFront 標準ログ](AccessLogs.md)を有効にし、レスポンスの HTTP ステータスコードを変更するように CloudFront を設定すると、ログの `sc-status` 列の値には指定したステータスコードが記述されます。ただし、`x-edge-result-type` 列の値は影響を受けません。この列には、オリジンから返された結果タイプが記述されます。例えば、オリジンが `200` (見つかりません) を CloudFront に返す場合、`404` のステータスコードをビューワーに返すように CloudFront を設定するとします。オリジンが `404` ステータスコードでリクエストに応答すると、ログ内の `sc-status` 列の値は `200` になりますが、`x-edge-result-type` 列の値は `Error` になります。
カスタムエラーページと共に以下の HTTP ステータスコードのいずれかを返すように、CloudFront を設定できます。
+ 200
+ 400、403、404、405、414、416
+ 500、501、502、503、504
# CloudFront がエラーをキャッシュする時間を制御する
CloudFront は、エラーレスポンスをデフォルト時間の 10 秒だけキャッシュします。その後、CloudFront はオブジェクトへの次のリクエストをオリジンに送信し、エラーの原因となった問題が解決されているかどうかと、リクエストしたオブジェクトが利用可能であるかどうかを確認します。
CloudFront がキャッシュする 4xx および 5xx ステータスコードそれぞれに対して、エラーキャッシュ期間 (**エラーキャッシュ最小 TTL**) を指定することができます。(詳しくは、[CloudFront がキャッシュする HTTP 4xx および 5xx ステータスコード](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors) を参照してください)。期間を指定する場合は、以下の点に注意してください。
+ 短いエラーキャッシュ期間を指定すると、長い期間を指定した場合に比べて CloudFront からオリジンに転送されるリクエストの数が多くなります。この構成で 5xx エラーが発生すると、エラーの返信処理のために、オリジンで障害を起こした問題が悪化する可能性があります。
+ オリジンがオブジェクトに関するエラーを返すと、CloudFront は、エラーキャッシュ期間が終了するまで、オブジェクトのリクエストにエラーレスポンスで応答するか、またはカスタムエラーページで応答します。長いエラーキャッシュ期間を指定するなら、オブジェクトが再び利用可能になった後も、CloudFront は長い間、リクエストにエラーレスポンスまたはカスタムエラーページで引き続き応答するかもしれません。
**注記**
リクエストされた範囲は不適格であることを示す HTTP ステータスコード 416 (Requested Range Not Satisfiable) のカスタムエラーページを作成したり、オリジンが CloudFront にステータスコード 416 を返すと CloudFront がビューワーに返す HTTP ステータスコードを変更したりできます。(詳しくは、[CloudFront から返されるレスポンスコードを変更する](custom-error-pages-response-code.md) を参照してください)。ただし、CloudFront はステータスコード 416 のレスポンスをキャッシュしないため、ステータスコード 416 に対して **[Error Caching Minimum TTL]** (エラーキャッシュの最小 TTL) の値を指定しても、CloudFront はそれを使用しません。
CloudFront でエラーをキャッシュする時間をオブジェクトごとに制御したい場合は、そのオブジェクトのエラーレスポンスに適切なヘッダーを追加するようにオリジンサーバーを設定できます。
オリジンが `Cache-Control: max-age` ディレクティブ、`Cache-Control: s-maxage` ディレクティブ、または `Expires` ヘッダーを追加した場合、CloudFront は、ヘッダーの値と **[Error Caching Minimum TTL]** (エラーキャッシュの最小 TTL) の値を比較してより大きい値の時間だけ、エラーレスポンスをキャッシュします。
**注記**
`Cache-Control: max-age` および `Cache-Control: s-maxage` の値は、エラーページをフェッチするキャッシュ動作に設定されている **[Maximum TTL]** (最大 TTL) の値以下にする必要があります。
オリジンがエラーコード 404、410、414、または 501 に `Cache-Control: no-store`、`Cache-Control: no-cache`、または `Cache-Control: private` ディレクティブを追加する場合、CloudFront はエラーレスポンスをキャッシュしません。他のすべてのエラーコードの場合、CloudFront は `no-store`、`no-cache`、および `private` ディレクティブを無視し、**エラーキャッシュ最小 TTL** の値のエラーレスポンスをキャッシュします。
オリジンが他の `Cache-Control` ディレクティブまたはヘッダーを追加した場合、CloudFront は **[Error Caching Minimum TTL]** (エラーキャッシュの最小 TTL) の値の時間だけ、エラーレスポンスをキャッシュします。
オブジェクトに対する 4xx または 5xx ステータスコードの有効期限が、設定した待機時間よりも長く、さらにオブジェクトが使用可能状態に復帰した場合は、リクエストされたオブジェクトの URL を使ってそのステータスコードを無効化できます。オリジンが複数のオブジェクトに対してエラーレスポンスを返している場合は、各オブジェクトについて個別に無効化する必要があります。オブジェクトの無効化については、「[ファイルを無効化してコンテンツを削除する](Invalidation.md)」を参照してください。
S3 バケットオリジンでキャッシュを有効にして、CloudFront ディストリビューションのエラーキャッシュの最小 TTL を 0 秒に設定しても、S3 オリジンエラーのエラーキャッシュの最小 TTL は 1 秒になります。これは、CloudFront が DDoS 攻撃からオリジンを保護するために行います。他のタイプのオリジンには適用されません。