# カスタムエラーレスポンスを生成する
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 攻撃からオリジンを保護するために行います。他のタイプのオリジンには適用されません。