あるメディア企業は、静的コンテンツを us-east-1 の S3 バケットに保存し、CloudFront で世界中に配信しています。プライマリオリジンの S3 が 5xx エラーを返した場合に、別リージョンの S3 バ

Question

あるメディア企業は、静的コンテンツを us-east-1 の S3 バケットに保存し、CloudFront で世界中に配信しています。プライマリオリジンの S3 が 5xx エラーを返した場合に、別リージョンの S3 バケットへ自動的に切り替えて配信を継続したいと考えています。エッジでのキャッシュ動作を維持しつつ、最小の構成変更でオリジンフェイルオーバーを実現する方法はどれですか。

Accepted Answer

正解: CloudFront のオリジングループを作成し、プライマリとセカンダリのオリジンを登録して、フェイルオーバー基準に 500・502・503・504 を指定する。CloudFront のオリジングループ（Origin Group）は、プライマリオリジンとセカンダリオリジンを束ね、指定したフェイルオーバーステータスコード（500/502/503/504 や 404/403 など）が返ったときに自動でセカンダリへ再試行する機能です。

ビヘイビアにオリジングループを割り当てるだけで、CloudFront のキャッシュ動作を維持したままオリジンレベルの高可用性を実現でき、追加サービスもコード実装も不要で構成変更が最小です。

選択肢Bの Route 53 フェイルオーバーは DNS 層での切り替えであり、CloudFront のオリジンフェイルオーバーほど即時ではなく、TTL の影響を受けるうえ CloudFront のキャッシュ統合からも外れます。
選択肢Cの Lambda@Edge は実装・保守コストが高く、オリジンレスポンスのエラー検知と再ルーティングを自前で書く必要があり、オリジングループより複雑です。
選択肢Dのカスタムエラーレスポンスは、指定オブジェクトをエラーページとして返すだけで本来のコンテンツへフェイルオーバーするものではありません。

Answer

2 つの S3 ウェブサイトエンドポイントを対象に Route 53 のフェイルオーバールーティングとヘルスチェックを設定して切り替える — Route 53 フェイルオーバーは DNS 層の切り替えで、ヘルスチェックの検知と TTL による伝播遅延が生じます。CloudFront のオリジン再試行ほど即時ではなく、エッジのキャッシュ統合からも外れるため最適ではありません。

Answer

Lambda@Edge のオリジンリクエストトリガーで、エラー発生時にオリジンを動的に切り替える処理を実装する — Lambda@Edge でエラー検知と再ルーティングを自前実装する方式は、オリジンレスポンスの監視ロジックや保守が必要で複雑になります。オリジングループという標準機能で完結できるため、構成変更最小の要件に反します。

Answer

CloudFront のカスタムエラーレスポンスを設定し、セカンダリ S3 バケットのオブジェクトをエラーページとして返す — カスタムエラーレスポンスは特定オブジェクトをエラーページとして返す機能であり、本来のコンテンツをセカンダリオリジンから配信し直すオリジンフェイルオーバーではないため、可用性の要件を満たしません。

解説

解説