メニュー
Amazon CloudFront
開発者ガイド (API Version 2016-09-29)

Amazon S3 オリジンにおけるリクエストとレスポンスの動作

CloudFront がリクエストを処理して Amazon S3 オリジンサーバーに転送する方法

CloudFront がビューアリクエストを処理して Amazon S3 オリジンに転送する方法については、該当するトピックを参照してください。

キャッシュ期間および最小 TTL

ウェブディストリビューションでは、CloudFront が別のリクエストをオリジンに転送するまでにオブジェクトを CloudFront キャッシュに保持する時間を制御できます。これを行うには、次の手順を実行します。

  • Cache-Control または Expires ヘッダーフィールドを各オブジェクトに追加するようにオリジンを構成します。

  • CloudFront キャッシュ動作で、最小 TTL の値を指定します。

  • デフォルト値の 24 時間を使用します。

詳細については、「CloudFront エッジキャッシュにオブジェクトを保持する時間の指定(有効期限切れ)」を参照してください。

クライアント 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

Note

X-Forwarded-For ヘッダーには、必要に応じて IPv4 アドレス (192.0.2.44 など) および IPv6 アドレス (2001:0db8:85a3:0000:0000:8a2e:0370:7334 など) が含まれます。

条件付きの GET

CloudFront は、エッジキャッシュで有効期限切れになっているオブジェクトに対するリクエストを受け取ると、リクエストを Amazon S3 オリジンに転送し、オブジェクトの最新バージョンを取得するか、CloudFront エッジキャッシュに最新バージョンがすでに存在することを Amazon S3 に確認します。Amazon S3 はオブジェクトを CloudFront に最初に送信するときに、ETag 値と LastModified 値をレスポンスに含めます。CloudFront は、CloudFront が Amazon S3 に転送する新しいリクエストには、次のどちらかまたは両方を追加します。

  • オブジェクトの有効期限切れバージョンの ETag 値が含まれる If-Match または If-None-Match ヘッダー。

  • オブジェクトの有効期限切れバージョンの LastModified 値が含まれる If-Modified-Since ヘッダー。

Amazon S3 は、この情報を使用して、オブジェクトが更新されているかどうかを判別します。つまり、オブジェクト全体を CloudFront に返すか、または HTTP 304 ステータスコード(変更なし)のみを返すかを判別します。

Cookie

Amazon S3 は Cookie を処理しません。Cookie を Amazon S3 オリジンに転送するようにキャッシュ動作を構成した場合、CloudFront は Cookie を転送しますが、Amazon S3 は Cookie を無視します。

Cross-Origin Resource Sharing (CORS)

CloudFront で Amazon S3 の Cross-Origin Resource Sharing 設定を尊重する場合は、選択したヘッダーを Amazon S3 に転送するように CloudFront を設定します。詳細については、「リクエストヘッダーに基づいてオブジェクトをキャッシュするように CloudFront を設定する」を参照してください。

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 オリジンアクセスアイデンティティを使用する場合、POST リクエストは一部の Amazon S3 リージョンでサポートされず、これらリージョンの PUT リクエストでは追加のヘッダーが必要です。詳細については、「署名バージョン 4 のみをサポートする Amazon S3 リージョンでのオリジンアクセスアイデンティティの使用」を参照してください。

マルチパートアップロードを使用してオブジェクトを Amazon S3 バケットに追加する場合は、CloudFront オリジンアクセスアイデンティティをディストリビューションに追加して、そのオリジンアクセスアイデンティティに適切な許可を付与する必要があります。詳細については、「オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する」を参照してください。

Caution

CloudFront がサポートするすべての HTTP メソッドを受け入れて Amazon S3 に転送するように CloudFront を構成する場合、お客様の Amazon S3 コンテンツへのアクセスを制限する CloudFront オリジンアクセスアイデンティティを作成して、そのオリジンアクセスアイデンティティに適切な許可を付与する必要があります。たとえば、PUT を使用したいので、上記のメソッドを受け入れて転送するように CloudFront を構成するという場合は、削除すべきでないリソースをビューアが削除できないようにするために、DELETE リクエストを適切に処理する Amazon S3 バケットポリシーまたは ACL を構成する必要があります。詳細については、「オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する」を参照してください。

Amazon S3 がサポートする操作の詳細については、「Amazon S3 ドキュメント」を参照してください。

CloudFront が削除または更新する HTTP リクエストヘッダー

CloudFront は、リクエストを Amazon S3 オリジンに転送する前に、以下のヘッダーフィールドを削除または更新します。

  • Accept

  • Accept-Charset

  • Accept-Encoding – 値が gzip を含む場合、CloudFront は Amazon S3 オリジンに Accept-Encoding: gzip を転送します。値が gzip含まない場合、CloudFront はリクエストをオリジンに転送する前に Accept-Encoding ヘッダーフィールドを削除します。

  • Accept-Language

  • Authorization:

    • GETHEAD の各リクエスト: CloudFront は、リクエストをオリジンに転送する前に Authorization ヘッダーフィールドを削除します。

    • OPTIONS リクエスト: OPTIONS リクエストへの応答をキャッシュするように CloudFront を設定した場合、CloudFront は、リクエストをオリジンに転送する前に、Authorization ヘッダーフィールドを削除します。

      OPTIONS リクエストへの応答をキャッシュするように CloudFront を設定しなかった場合、CloudFront は、Authorization ヘッダーフィールドをオリジンに転送します。

    • DELETEPATCHPOSTPUT の各リクエスト: CloudFront は、リクエストをオリジンに転送する前にヘッダーフィールドを削除しません。

  • Connection – CloudFront は、Amazon S3 オリジンにリクエストを転送する前にこのヘッダーを Connection: Keep-Alive ヘッダーに置き換えます。

  • Cookie – Cookie を転送するように CloudFront を構成している場合、Amazon S3 オリジンに Cookie ヘッダーフィールドが転送されます。そうでない場合、CloudFront は Cookie ヘッダーフィールドを削除します。詳細については、「Cookie に基づいてオブジェクトをキャッシュするように CloudFront を設定する」を参照してください。

  • Expect

  • Host – CloudFront は、リクエストされたオブジェクトに関連付けられた Amazon S3 バケットの名前に値を設定します。

  • Proxy-Authorization

  • Referer

  • TE

  • Upgrade

  • User-Agent – CloudFront はこのヘッダーフィールドの値を Amazon CloudFront に置き換えます。

リクエストの最大長と URL の最大長

パス、クエリ文字列(ある場合)、ヘッダーを含め、リクエストの最大長は 20480 バイトです。

CloudFront はリクエストから URL を構築します。この URL の最大長は 8192 文字です。

リクエストまたは URL がこの制限を超えると、CloudFront は、リクエストヘッダーフィールドが長すぎることを示す HTTP ステータスコード 413(Request Header Fields 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 は、ビューアリクエストのプロトコル(HTTP または HTTPS)に基づいて、HTTP または HTTPS リクエストをオリジンサーバーに転送します。

Important

Amazon S3 バケットがウェブサイトエンドポイントとして構成されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を構成することはできません。Amazon S3 はその構成で HTTPS 接続をサポートしていないためです。

クエリ文字列

ウェブディストリビューションでは、CloudFront でクエリ文字列パラメーターを Amazon S3 オリジンに転送するかどうかを構成できます。RTMP ディストリビューションでは、CloudFront はクエリ文字列パラメーターを転送しません。詳細については、「クエリ文字列パラメーターに基づいてキャッシュするように CloudFront を設定する」を参照してください。

リクエストのタイムアウト

CloudFront のリクエストのタイムアウトは、HTTP メソッドによって決まります。

  • GET および HEAD リクエスト – Amazon S3 が 30 秒以内に応答しない場合、CloudFront は接続を中断して、オリジンに対する接続をさらに 2 回試みます。3 回目の試みでもオリジンが応答しない場合、CloudFront は同じオリジンのコンテンツに対する別のリクエストを受け取るまで接続を試みません。

  • DELETEOPTIONSPATCHPOSTPUT リクエスト – Amazon S3 が 30 秒以内に応答しない場合、CloudFront は接続を中断し、オリジンへの接続を再試行しません。クライアントは、必要に応じてリクエストを再送信できます。

リクエストのタイムアウトは変更できません。

同じオブジェクト(トラフィックスパイク)の同時リクエスト

CloudFront エッジロケーションがオブジェクトのリクエストを受け取り、オブジェクトが現在キャッシュにないか、有効期限が切れている場合、CloudFront はすぐに Amazon S3 オリジンにリクエストを送信します。トラフィックスパイクがある—同じオブジェクトへの追加のリクエストが、Amazon S3 が最初のリクエストに応答する前にエッジロケーションに届く—場合、CloudFront は短時間一時停止してから、オブジェクトへの追加のリクエストをオリジンに転送します。通常、最初のリクエストへのレスポンスは、それ以降のリクエストに対するレスポンスの前に、CloudFront エッジロケーションに届きます。この短い一時停止により、Amazon S3 の不要な負荷を減らすことができます。リクエストヘッダーやクエリ文字列に基づいてキャッシュするように CloudFront を設定した場合など、追加のリクエストが同じでない場合、CloudFront はすべての一意のリクエストをオリジンに転送します。

オリジンからのレスポンスに Cache-Control: no-cache ヘッダーが含まれている場合、通常 CloudFront は同じオブジェクトの次のリクエストをオリジンに転送し、オブジェクトが更新されたかどうかを判断します。ただし、トラフィックスパイクがあり、CloudFront が最初のリクエストをオリジンに転送した後で一時停止する場合、CloudFront がオリジンからレスポンスを受け取る前に、複数のビューアリクエストが届くことがあります。CloudFront は、Cache-Control: no-cache ヘッダーを含むレスポンスを受け取ると、元のリクエストを作成したビューアと、一時停止中にオブジェクトをリクエストしたすべてのビューアへのレスポンスでオブジェクトを送信します。オリジンからレスポンスがあると、CloudFront は同じオブジェクトに対する次のビューアリクエストをオリジンに転送します。CloudFront アクセスログでは、最初のリクエストが x-edge-result-type 列で Miss として識別され、CloudFront が受け取ったそれ以降のすべてのリクエストは、Hit として識別されます。アクセスログファイル形式の詳細については、「ウェブディストリビューションのログファイル形式」を参照してください。

CloudFront が Amazon S3 オリジンサーバーからのレスポンスを処理する方法

取り消されたリクエスト

オブジェクトがエッジキャッシュになく、CloudFront がオブジェクトをオリジンから取得したものの、リクエストされたそのオブジェクトを配信する前にビューアがセッションを終了すると(ブラウザを閉じるなど)、CloudFront はそのオブジェクトをエッジロケーションにキャッシュしません。

CloudFront が削除または更新する HTTP レスポンスヘッダー

CloudFront は、Amazon S3 オリジンからのレスポンスをビューアに転送する前に、以下のヘッダーフィールドを削除または更新します。

  • Set-Cookie – Cookie を転送するように CloudFront を構成している場合、Set-Cookie ヘッダーフィールドがクライアントに転送されます。詳細については、「Cookie に基づいてオブジェクトをキャッシュするように CloudFront を設定する」を参照してください。

  • Trailer

  • Transfer-Encoding – Amazon S3 オリジンがこのヘッダーフィールドを返す場合、CloudFront は値を chunked に設定してビューアにレスポンスを返します。

  • Upgrade

  • Via – CloudFront は値を次のように設定します。

    Via: 1.1 alphanumeric-string.cloudfront.net (CloudFront)

    その後、ビューアにこのレスポンスを返します。以下に例を示します。

    Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

最大ファイルサイズ

CloudFront がビューアに返すレスポンス本文の最大サイズは 20 GB です。これには、Content-Length ヘッダーの値を指定しないチャンク転送レスポンスが含まれます。

リダイレクト

すべてのリクエストを別のホスト名にリダイレクトするように Amazon S3 バケットを構成できます。別のホスト名には、別の Amazon S3 バケットまたは HTTP サーバーを使用できます。すべてのリクエストをリダイレクトするようにバケットを構成しており、バケットが CloudFront ディストリビューションのオリジンの場合、ディストリビューションのドメイン名(例: d111111abcdef8.cloudfront.net)またはディストリビューションに関連付けられた代替ドメイン名(CNAME)(例: example.com)を使用してすべてのリクエストを CloudFront ディストリビューションにリダイレクトするようにバケットを構成することをお勧めします。このように構成しない場合、ビューアリクエストは CloudFront をバイパスし、オブジェクトは新しいオリジンから直接提供されます。

Note

代替ドメイン名にリクエストをリダイレクトする場合は、CNAME レコードを追加してドメインの DNS サービスを更新する必要もあります。詳細については、「代替ドメイン名(CNAME)を使用する」を参照してください。

すべてのリクエストをリダイレクトするようにバケットを構成した場合の動作を以下に示します。

  1. ビューア(例: ブラウザ)が CloudFront にオブジェクトを要求します。

  2. CloudFront は、ディストリビューションのオリジンである Amazon S3 バケットにリクエストを転送します。

  3. Amazon S3 は、HTTP ステータスコード 301(Moved Permanently)と新しい場所を返します。

  4. CloudFront は、リダイレクトのステータスコードと場所をキャッシュし、ビューアに値を返します。CloudFront がリダイレクトに従って新しい場所からオブジェクトを取得することはありません。

  5. ビューアはオブジェクトに対する別のリクエストを送信しますが、今回は、CloudFront から取得した新しい場所を指定します。

    • Amazon S3 バケットがディストリビューションのドメイン名または代替ドメイン名を使用してすべてのリクエストを CloudFront ディストリビューションにリダイレクトする場合、CloudFront は新しい場所にある Amazon S3 バケットまたは HTTP サーバーのオブジェクトを要求します。新しい場所からオブジェクトが返されると、CloudFront はオブジェクトをビューアに返し、エッジロケーションにオブジェクトをキャッシュします。

    • Amazon S3 バケットがリクエストを別の場所にリダイレクトする場合、2 番目のリクエストは CloudFront をバイパスします。新しい場所にある Amazon S3 バケットまたは HTTP サーバーがオブジェクトをビューアに直接返すので、オブジェクトは CloudFront エッジキャッシュに一切キャッシュされません。