AWSでSorryページの実装：Route53によるフェールオーバー設定

こんにちは、TAMの石川です。

Webサイトが障害やメンテナンスで停止している際に表示するSorryページをAWS上で切り替える方法として、CloudFrontのカスタムエラーページを利用するケースが多いかと思います。

今回は、Route53を活用して同じことができるかを検証してみました。

Sorryページの実現方法

AWSでSorryページを実現する方法はいくつかあります。

• CloudFrontのカスタムエラーページを利用（任意のページを表示可能）
• ALBのRule設定（カスタムページの表示可。ただし256バイトのサイズ制限あり）
• Route53のフェールオーバー設定を利用

今回は、あまり活用されていないRoute53を使った設定を試してみたいと思います。

Route53のフェールオーバー設定の仕組み

Route53はDNSのサービスであり、複雑な処理はできませんが、DNSのレコード応答を制御する以下の2つのオプションが用意されています。

Failover（フェールオーバー）

1つのDNSレコードに対し、プライマリとセカンダリを設定し、それぞれにヘルスチェックを用意します。 プライマリのヘルスチェックが失敗すると、セカンダリのレコードへ切り替わる仕組みです。

※プライマリは1つのみ登録可能です。

Weight（重み付け）

Route53の優先度付け機能を活用し、同じレコード内でヘルスチェックの状況に応じて複数のサーバーを名前解決先として設定できます。

例：

• web01（Weight: 50）
• web02（Weight: 50）
• Sorry（Weight: 0）

通常はweb01・web02へトラフィックが振り分けられますが、両方がダウンした場合はSorryページへ流れる仕組みです。

Sorryページへの遷移時の挙動とSEOの考慮点

Sorryページへのフェールオーバーは正常に動作しますが、1つ懸念点があります。

• SorryページがHTTP 200 OKで応答するため、一度Sorryに切り替わるとブラウザキャッシュが残り、ページを更新しても元のコンテンツが表示されないことがある。
• SEOを考慮すると、Sorryページのレスポンスコードは**403（Forbidden）や500（Internal Server Error）**で返すのが適切。

そのため、SEOを意識する場合は適切なエラーレスポンスを設定することが重要です。

Route53のFailoverとWeightを利用した環境構築

ここでは、Route53のFailoverおよびWeightを利用した環境を構築するためのyamlを紹介します。

注意： これらの設定にはVPC、Subnet、AMIのイメージID、Route53のHostedZoneIDなどが含まれており、適用環境を考慮する必要があります。

FilaOver設定の環境を作るyaml

 

Weight設定の環境を作るyaml

 

まとめ

今回の検証では、AWSのRoute53を活用してSorryページのフェールオーバーを実現する方法を紹介しました。

• CloudFrontやALBのカスタムエラーページの代替手段として、Route53のFailoverやWeightを活用できる。
• Sorryページのレスポンスコードは適切に設定しないと、SEOやユーザー体験に影響を与える可能性がある。
• CloudFormationを活用することで、Failover/Weightの設定を簡単にデプロイ可能。

Sorryページの設計は、サイトの可用性とUXを考慮しながら、適切な手法を選択することが重要です。

今後、より柔軟なSorryページの実装方法についても検討していきたいと思います。