Amazon S3 オリジンに対するリクエストとレスポンスの動作 - Amazon CloudFront
CloudFront がリクエストを処理して Amazon S3 オリジンに転送する方法CloudFront が Amazon S3 オリジンからのレスポンスを処理する方法

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

オリジンとして Amazon S3 を使用している場合に、CloudFront がリクエストとレスポンスを処理する方法については、以下のセクションを参照してください。

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

CloudFront がビューワーのリクエストを処理して Amazon S3 オリジンに転送する方法について説明します。

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

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

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

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

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

詳細については、「コンテンツをキャッシュに保持する期間 (有効期限) を管理する」を参照してください。

クライアント 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 を変更するかどうかに関わらず、キャッシュ内の既存のオブジェクトから処理されます。

クロスオリジンリソース共有 (CORS)

CloudFront で Amazon S3 の Cross-Origin Resource Sharing 設定を尊重する場合は、選択したヘッダーを Amazon S3 に転送するように 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 オリジンアクセスコントロール (OAC) をディストリビューションに追加して、その OAC に必要な許可を付与する必要があります。詳細については、「Amazon Simple Storage Service オリジンへのアクセスを制限する」を参照してください。

重要

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

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

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

CloudFront は、リクエストを Amazon S3 オリジンに転送する前に、一部のヘッダーを削除または更新します。ほとんどのヘッダーで、この動作はカスタムオリジンの場合と同じです。すべての HTTP リクエストヘッダーの一覧と、CloudFront がそれを処理する方法については、「HTTP リクエストヘッダーと CloudFront の動作 (カスタムオリジンおよび Amazon S3 オリジン)」を参照してください。

リクエストの最大長と 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 オリジンに転送するかどうかを設定できます。詳細については、「クエリ文字列パラメータに基づいてコンテンツをキャッシュする」を参照してください。

オリジン接続のタイムアウトと試行

オリジン接続タイムアウトは、オリジンへの接続を確立しようとしたときに CloudFront が待機する秒数です。

オリジン接続試行は、CloudFront がオリジンへの接続を試行する回数です。

これらの設定により、セカンダリオリジンにフェイルオーバーするか (オリジングループの場合)、ビューワーにエラーレスポンスを返す前に、CloudFront がオリジンへの接続を試行する時間が決まります。デフォルトでは、CloudFront はセカンダリオリジンへの接続を試行したり、エラーレスポンスを返したりする前に 30 秒 (それぞれ 10 秒間の試行が 3 回) 待機します。接続タイムアウトを短くするか、試行回数を減らすか、その両方を行うことで、この時間を短縮できます。

詳細については、「オリジンのタイムアウトと試行を制御する」を参照してください。

オリジン応答タイムアウト

オリジン応答タイムアウト (オリジンの読み取りタイムアウトまたはオリジンリクエストタイムアウトとも呼ばれます) は、次の両方に適用されます。

  • CloudFront がリクエストをオリジンに転送してからレスポンスを受け取るまでの待機時間 (秒)。

  • CloudFront がオリジンからレスポンスのパケットを受け取ってから次のパケットを受け取るまでの待機時間 (秒)。

CloudFront の動作は、ビューワーリクエストの HTTP メソッドによって決まります。

  • GET および HEAD リクエスト – オリジンが 30 秒以内に応答しない場合、または 30 秒間応答を停止する場合は、CloudFront は接続を中断します。指定されたオリジン接続の試行回数が 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 とエッジ関数のログ記録」を参照してください。

CloudFront は、キャッシュキーを共有するリクエストのみを折りたたみます。リクエストヘッダーまたはクッキーまたはクエリ文字列に基づいてキャッシュするように CloudFront を設定した場合など、追加のリクエストが同じキャッシュキーを共有しない場合、CloudFront は一意のキャッシュキーを持つすべてのリクエストをオリジンに転送します。

すべてのリクエストの折りたたみを防ぐ場合は、マネージドキャッシュポリシー CachingDisabled を使用できます (このポリシーはキャッシュも防ぎます)。詳細については、「マネージドキャッシュポリシーを使用する」を参照してください。

特定のオブジェクトでのリクエストの折りたたみを防ぐ場合は、キャッシュ動作の最小 TTL を 0 に設定し、さらに Cache-Control: private、Cache-Control: no-store、Cache-Control: no-cache、Cache-Control: max-age=0、または Cache-Control: s-maxage=0 を送信するようにオリジンを設定できます。これらの設定に伴ってオリジンへの負荷が増え、CloudFront が最初のリクエストへのレスポンスを待機中に一時停止される同時リクエストのレイテンシーが高くなります。

重要

現在、キャッシュポリシー、オリジンリクエストポリシー、またはレガシーキャッシュ設定で Cookie 転送を有効にした場合、CloudFront はリクエストの折りたたみをサポートしません。

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

CloudFront が Amazon S3 オリジンからのレスポンスを処理する方法について説明します。

取り消されたリクエスト

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

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

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

  • X-Amz-Id-2

  • X-Amz-Request-Id

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

  • 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 以下であるためです。ビューワーによって、オブジェクトのすべてのパートを取得した後、元の大きなオブジェクトが再構築されます。詳しくは、「範囲リクエストを使用して大きなオブジェクトをキャッシュする」を参照してください。

リダイレクト

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

注記

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

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

  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 エッジキャッシュに一切キャッシュされません。