AWS Sorry Page定番パターン整理（ソーリーページ／メンテナンスページ）

はじめに

Webシステムを利用していて「メンテナンス中」や「アクセスが集中しています」などと表示された経験はないでしょうか？あまり頻繁に目にするものでは（というより目にしたく）ありませんが、このようにサービスが一時的に利用できない場合に表示するページを一般的にソーリーページ（SorryPage）と呼ぶことが多いと思います。ソーリーページがないと無骨でそっけないエラー画面が表示されることになるので利用者に現在の状況が伝わらず、サービスへの印象も悪くなってしまいます。

しかし、計画されたメンテナンスと突発的な障害の両方を一緒くたにソーリーページと呼ぶことには個人的には違和感があります。そこで、ここでは次のように区別して呼ぶことにします。

突発的な障害：ソーリーページ（SorryPage）
計画的な停止：メンテナンスページ（MaintenancePage）

記事の目的

AWS環境でソーリーページ／メンテナンスページを表示する定番の方式について調査したところ、まとまった情報がなかなか見つからず苦労したので、再度同じ苦労をしなくて済むよう、調査した内容を今後のためナレッジとしてまとめておくことが目的です。

注意点

本記事でまとめた以外にも様々な実現方式が存在すると思います。また、本内容は現時点（2024年2月時点）の情報に基づいた内容になっている点についても併せてご承知おきください。

実現方式

以下に定番の実現方式を示します。

1．突発的な障害：ソーリーページ（SorryPage）

以下の方式は、突発的な障害が発生した際、マネージドサービスのフェイルオーバー機能を利用して、自動的にセカンダリであるバックアップサイトのソーリーページに遷移させます。

★方式１：Route53フェイルオーバールーティング

Route53のフェイルオーバールーティングでオリジンとの接続タイムアウトやオリジン側で発生したエラーコード（5XX系）を基にセカンダリのソーリーページへ自動的に遷移させます。

2018年頃まではこの方式が主流
カスタムエラーページは、CloudFront からのアクセスが可能な場所に保存します。これらのページの保存先は、Amazon S3 バケットにすることを推奨します。
カスタムエラーページを Amazon S3 に保存している場合、そのページがパブリックにアクセスが可能であるか、CloudFront のオリジンアクセスコントロール (OAC) を設定する必要があります。カスタムエラーページをカスタムオリジンに格納する場合には、そのページはパブリックにアクセス可能である必要があります。
昔から存在するよくある王道パターン（AWSクラウドデザインパターンにも掲載）

＜AWS公式＞

フェイルオーバールーティング - Amazon Route 53

＜その他＞

Amazon Route 53 によるフェイルオーバーと CloudFront と S3 構成のソリーページ設定について考えてみた | DevelopersIO

★方式２：CloudFrontオリジンフェイルオーバー

CloudFrontのオリジンフェイルオーバーでオリジンとの接続タイムアウトやオリジン側で発生したエラーコード（5XX系）をセカンダリのオリジン（ソーリーページ）へ自動的に遷移させます。

2018年頃からCloudFrontのみでオリジンフェイルオーバーできるようになった。
カスタムエラーページは、CloudFront からのアクセスが可能な場所に保存します。これらのページの保存先は、Amazon S3 バケットにすることを推奨します。
カスタムエラーページを Amazon S3 に保存している場合、そのページがパブリックにアクセスが可能であるか、CloudFront のオリジンアクセスコントロール (OAC) を設定する必要があります。カスタムエラーページをカスタムオリジンに格納する場合には、そのページはパブリックにアクセス可能である必要があります。

＜AWS公式＞

CloudFront オリジンフェイルオーバーによる高可用性の最適化 - Amazon CloudFront

＜その他＞

2．計画的な停止：メンテナンスページ（MaintenancePage）

以下の方式は、計画的なメンテナンスの際、手動でマネージドサービスの設定を切り替えて利用者をメンテナンスページに遷移させます。

★方式１：WAFルールでIP接続制限

Amazon CloudFront の機能AWS WAFとの連携して手動で設定を切り替えて、許可IP（作業者用）以外の利用者をメンテナンスページに遷移させます。

2017年頃既に使われていた方式
カスタムエラーページは、CloudFront からのアクセスが可能な場所に保存します。これらのページの保存先は、Amazon S3 バケットにすることを推奨します。
カスタムエラーページを Amazon S3 に保存している場合、そのページがパブリックにアクセスが可能であるか、CloudFront のオリジンアクセスコントロール (OAI) を設定する必要があります。カスタムエラーページをカスタムオリジンに格納する場合には、そのページはパブリックにアクセス可能である必要があります。

＜AWS公式＞

Amazon CloudFront の機能AWS WAFとの連携方法 - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced

＜その他＞

★方式２：ALB固定レスポンスアクション

ALB の「固定レスポンスアクション」を利用し、メンテナンス作業時に手動で設定を切り替えて、許可IP（作業者用）以外の利用者にメンテナンスページを表示する。

2018年頃からこの方式が利用可能
ALBを経由する通信であればインターネット／閉域網のいずれからでもこの方式で簡単にページを実現できる。
ページの文字が最大1024文字までなので、凝ったページを扱いにくい。
ページへの切替は手動で行う（自動化するには他サービスCloudWatch、Step Functions、EventBridge、Lambdaなどを組み合わせて自力で頑張る必要がある）