カスタムエラーレスポンスの生成 - Amazon CloudFront

カスタムエラーレスポンスの生成

CloudFront から配信されているオブジェクトが何らかの理由で使用できなくなった場合、これを伝えるために、通常はウェブサーバーから、関連する HTTP ステータスコードが CloudFront に返されます。例えば、ビューワーリクエストが無効な URL を指定している場合、ウェブサーバーからは 404 (Not Found) ステータスコードが CloudFront に返されます。さらに、そのステータスコードが、CloudFront からビューワーに返されます。

必要であれば、CloudFront を設定し、このコードの代わりにカスタムエラーレスポンスをビューワーに返信するようにできます。また、エラーが発生した場合に CloudFront がどのように応答するかを指定するための、いくつかのオプションもあります。カスタムエラーメッセージのオプションを指定するには、CloudFront ディストリビューションを更新して、その値を指定します。詳細については、「エラーレスポンス動作を設定する」 を参照してください。

HTTP ステータスコードの代わりにカスタムエラーページを返すように CloudFront を構成していても、カスタムエラーページが利用できない場合には、CloudFront は、カスタムエラーページを持つオリジンから受信したステータスコードをビューワーに返します。たとえば、カスタムオリジンから 500 ステータスコードが返され、500 ステータスコードのためのカスタムエラーページを Amazon S3 バケットから取得するように CloudFront を構成してあるとします。ところが、だれかがうっかりカスタムエラーページをバケットから削除してしまいました。この場合 CloudFront は、そのオブジェクトをリクエストしたビューワーに対して、HTTP 404 ステータスコード (Not found) を返します。

CloudFront がカスタムエラーページをビューワーに返したときに、リクエストしたオブジェクトの料金ではなく、カスタムエラーページの標準 CloudFront 料金を支払います。CloudFront の料金の詳細については、「Amazon CloudFront 料金表」を参照してください。

エラーレスポンス動作を設定する

カスタムエラーレスポンスの設定は、CloudFront コンソール、CloudFront API、または AWS CloudFormation から行えます。これらの内どれにより設定を更新する場合でも、次に挙げるヒントと推奨事項を参考にしてください。

  • カスタムエラーページは、CloudFront からのアクセスが可能な場所に保存します。これらのページの保存先は、Amazon S3 バケットにすることを推奨します。また、ウェブサイトやアプリケーションなど、他のコンテンツと同じ場所には保存しないようにしてください。カスタムエラーページが、ウェブサイトやアプリケーションと同じオリジンに保存されている場合、オリジンのサーバーが使用不能になり 5xx エラーが返信されるようになると、CloudFront は、その使用不能なオリジンからカスタムエラーページを取得できなくなります。詳細については、「オブジェクトとカスタムエラーページを別の場所に格納する」を参照してください。

  • CloudFront にカスタムエラーページを取得するための権限があることを確認します。カスタムエラーページを Amazon S3 に保存している場合、そのページがパブリックにアクセスが可能であるか、CloudFront のオリジンアクセスアイデンティティ (OAI) が設定されている必要があります。カスタムエラーページをカスタムオリジンに格納する場合には、そのページはパブリックにアクセス可能である必要があります。

  • (オプション) 必要に応じてオリジンを設定し、カスタムエラーページに Cache-Control または Expires ヘッダーを追加します。また、エラーキャッシュ最小 TTL 設定を使用して、CloudFront がカスタムエラーページをキャッシュに保持する時間を制御することもできます。詳細については、「CloudFront がエラーをキャッシュする時間の制御」を参照してください。

カスタムエラーレスポンスの設定 (CloudFront コンソール)

CloudFront コンソールからカスタムエラーレスポンスを設定するには、CloudFront ディストリビューションが必要です。コンソールからカスタムエラーレスポンスの構成を設定する際には、ディストリビューションが既に用意されている必要があります。ディストリビューションの作成方法については、「簡単な CloudFront ディストリビューションの開始方法」を参照してください。

カスタムエラーレスポンスを設定するには (コンソール)

  1. AWS Management Consoleにサインインし、https://console.aws.amazon.com/cloudfront/home?#distributions: の CloudFront コンソールで [ディストリビューション] ページを開きます。

  2. ディストリビューションの一覧で、更新するディストリビューションを選択します。

  3. [エラーページ] タブを開き、[カスタムエラーレスポンスの作成] をクリックします。

  4. 適切な値を入力します。詳細については、「ディストリビューションを作成または更新する場合に指定する値」の「Custom Error Pages (カスタムエラーページ) と Error Caching (エラーキャッシュ)」を参照してください。

  5. 必要な値を入力したら、[作成] をクリックします。

カスタムエラーレスポンスの設定 (CloudFront API または AWS CloudFormation)

CloudFront API または AWS CloudFormation でカスタムエラーレスポンスを設定するには、CustomErrorResponse タイプのディストリビューションを使用します。詳細については、以下を参照してください。

特定の HTTP ステータスコードに対応するカスタムエラーページの作成

デフォルト (ウェブサイト内の他のページと同じ書式設定) のメッセージではなく、カスタムエラーメッセージを表示させたい場合は、そのカスタムエラーメッセージを含むオブジェクト (HTML ファイルなど) を、CloudFront からビューワーに返すようにもできます。

返信させたい特定のファイルや、ファイルの返信の対象となるエラーを指定するには、CloudFront ディストリビューションを更新してそれらの値を指定します。詳細については、「エラーレスポンス動作を設定する」 を参照してください。

例として、カスタムエラーページは次のようなものになります。


				AWS 404 page

サポートされている HTTP ステータスコードごとに異なるオブジェクトを指定することができます。または、サポートされているすべてのステータスコードに同じオブジェクトを使用することもできます。一部のステータスコードにカスタムエラーページを指定し、他のステータスコードには指定しないようにもできます。

CloudFront を通して供給されているオブジェクトは、様々な理由で使用できなくなることがあります。理由は、大きく 2 つに分類できます。以下にそれぞれを説明します。

  • クライアントエラーは、リクエストに問題があることを示します。たとえば、指定した名前のオブジェクトが使用不能である場合や、Amazon S3 バケット内のオブジェクトを取得するために必要な権限がユーザーにない場合などです。クライアントエラーが発生すると、オリジンは 400 番台の HTTP ステータスコードを CloudFront に返します。

  • サーバーエラーの場合は、オリジンサーバーに問題があります。たとえば、HTTP サーバーが混雑していたり使用不能であったりする場合です。サーバーエラーが発生すると、オリジンサーバーから 500 番台の HTTP ステータスコードが CloudFront に返されます。あるいは、オリジンサーバーから一定の時間内で CloudFront にレスポンスが届かないということで、504 ステータスコード (ゲートウェイタイムアウト) として処理されます。

CloudFront がカスタムエラーページを返すことのできる HTTP ステータスコードは、以下のとおりです。

  • 400、403、404、405、414、416

    注記

    リクエストされた範囲は不適格であることを示す HTTP ステータスコード 416 (Requested Range Not Satisfiable) のカスタムエラーページを作成したり、オリジンが CloudFront にステータスコード 416 を返すと CloudFront がビューワーに返す HTTP ステータスコードを変更したりできます。(詳しくは、CloudFront より返されるレスポンスコードの変更 を参照してください)。 ただし、CloudFront はステータスコード 416 によるレスポンスをキャッシュしないため、ステータスコード 416 に対し [エラーキャッシュ最小 TT)] の値を指定することはできますが、CloudFront はそれを使用しません。

  • 500、501、502、503、504

    注記

    また、CloudFront で HTTP 503 ステータスコードのカスタムエラーページを設定していても、それが返されないケースもあり得ます。CloudFront エラーコードが Capacity Exceeded または Limit Exceeded の場合、CloudFront はカスタムエラーページを使用せずに 503 ステータスコードをビューワーに返します。

CloudFront がオリジンからのエラーレスポンスを処理する方法の詳細な説明は、「CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理してキャッシュする方法」を参照してください。

オブジェクトとカスタムエラーページを別の場所に格納する

オブジェクトとカスタムエラーページを別の場所に保存する場合は、次の状況に該当するときに適用されるキャッシュ動作をディストリビューションに組み込む必要があります。

  • [Path Pattern (パスパターン)] の値が、カスタムエラーメッセージのパスと一致している。たとえば、4xx エラーのカスタムエラーページを /4xx-errors というディレクトリの Amazon S3 バケットに保存したとします。このとき、パスパターンによってカスタムエラーページのリクエストがルーティングされる場所のキャッシュ動作を、ディストリビューションに組み込む必要があります (/4xx-errors/* など)。

  • [Origin (オリジン)] の値は、カスタムエラーページが含まれているオリジンの [Origin ID (オリジン ID)] の値を指定しています。

詳細については、トピック「キャッシュ動作の設定」の「ディストリビューションを作成または更新する場合に指定する値」を参照してください。

CloudFront より返されるレスポンスコードの変更

CloudFront がオリジンから受信したものとは異なる HTTP ステータスコードを、ビューワーに返すように CloudFront を設定できます。たとえば、オリジンから 500 ステータスコードが CloudFront に返されるときに、CloudFront からカスタムエラーページと 200 ステータスコード (OK) がビューワーに返されるようにしたいことがあります。さまざまな理由で、オリジンから CloudFront に返されるステータスコードとは異なるステータスコードが CloudFront からビューワーに返されることが必要になる場合があります。

  • インターネットデバイス (一部のファイアウォールやコーポレートプロキシなど) の中には、HTTP 400 番台と 500 番台のステータスコードを遮断して、このレスポンスがビューワーに返信されないようするものがあります。このシナリオの場合、200 に置換することで、応答は遮断されなくなります。

  • クライアントエラーとサーバーエラーの種類による区別が必要ない場合、CloudFront が返す 4xx および 5xx のステータスコードのすべてで、値を 400 または 500 とするようにも指定できます。

  • 200 ステータスコード (OK) と静的ウェブサイトを返すことにより、ウェブサイトが停止していることをユーザーが気づかないようにもできます。

CloudFront 標準ログを有効にし、レスポンスの HTTP ステータスコードを変更するように CloudFront を設定すると、ログの sc-status 列の値には指定したステータスコードが記述されます。ただし、x-edge-result-type 列の値は影響を受けません。この列には、オリジンから返された結果タイプが記述されます。例えば、オリジンが 404 (見つかりません) を CloudFront に返す場合、200 のステータスコードをビューワーに返すように 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 がエラーをキャッシュする時間の制御

デフォルトでは、オリジンから HTTP 4xx または 5xx ステータスコードが返されると、CloudFront はこれらのエラーレスポンスを 10 秒間キャッシュします。その後 CloudFront は、オブジェクトに対する次のリクエストをオリジンに送信し、エラーの原因となった問題が解決され、リクエストしたオブジェクトが利用可能になったかどうかを確認します。

注記

リクエストされた範囲は不適格であることを示す HTTP ステータスコード 416 (Requested Range Not Satisfiable) のカスタムエラーページを作成したり、オリジンが CloudFront にステータスコード 416 を返すと CloudFront がビューワーに返す HTTP ステータスコードを変更したりできます。(詳しくは、CloudFront より返されるレスポンスコードの変更 を参照してください)。 ただし、CloudFront はステータスコード 416 によるレスポンスをキャッシュしないため、ステータスコード 416 に対し [エラーキャッシュ最小 TT)] の値を指定することはできますが、CloudFront はそれを使用しません。

CloudFront がキャッシュする 4xx および 5xx ステータスコードそれぞれに対して、エラーキャッシュ期間 (エラーキャッシュ最小 TTL) を指定することができます。期間を指定する場合は、以下の点に注意してください。

  • 短いエラーキャッシュ期間を指定すると、長い期間を指定した場合に比べて CloudFront からオリジンに転送されるリクエストの数が多くなります。この構成で 5xx エラーが発生すると、エラーの返信処理のために、オリジンで障害を起こした問題が悪化する可能性があります。

  • オリジンがオブジェクトに関するエラーを返すと、CloudFront は、エラーキャッシュ期間が終了するまで、オブジェクトのリクエストにエラーレスポンスで応答するか、またはカスタムエラーページで応答します。長いエラーキャッシュ期間を指定するなら、オブジェクトが再び利用可能になった後も、CloudFront は長い間、リクエストにエラーレスポンスまたはカスタムエラーページで引き続き応答するかもしれません。

CloudFront がエラーをキャッシュする時間を個別のオブジェクトに対して制御することを希望する場合は、以下のようにして、対象のオブジェクトのエラーレスポンスに適切なヘッダーを追加するようにオリジンサーバーを構成できます。

  • オリジンが Cache-Control: max-age ディレクティブや Cache-Control: s-maxage ディレクティブ、または Expires ヘッダーを追加している場合は次のようになります。

    CloudFront は、ヘッダーの値と [エラーキャッシュ最小 TTL] の値で大きい方に対応する期間、エラーレスポンスをキャッシュに保持します。

    Cache-Control: max-age および Cache-Control: s-maxage の値は、エラーページをフェッチするためのキャッシュ動作で設定されている、[最大 TTL] の値以下にする必要があることに注意してください。

  • オリジンが他の Cache-Control ディレクティブを追加する、もしくはヘッダーを追加しない場合は、次のようになります。

    CloudFront は、[エラーキャッシュ最小 TTL] の値に対応する時間、エラーレスポンスをキャッシュに保持します。

オブジェクトに対する 4xx または 5xx ステータスコードの有効期限が、設定した待機時間よりも長く、さらにオブジェクトが使用可能状態に復帰した場合は、リクエストされたオブジェクトの URL を使ってそのステータスコードを無効化できます。オリジンが複数のオブジェクトに対してエラーレスポンスを返している場合は、各オブジェクトについて個別に無効化する必要があります。オブジェクトの無効化については、「ファイルの無効化」を参照してください。