AWSでマルチリージョン構成を設計する際、Route 53の「加重ルーティング」と「ヘルスチェック」をどう組み合わせるかは、可用性を大きく左右します。
※本記事で扱うヘルスチェックは、ALBのものではなく、Route 53のヘルスチェックを指しています。

特に、東京リージョンと大阪リージョンのDual-ACT構成では、両拠点が常時稼働しており、どちらかが障害になってもサービスを止めない設計が求められます。

本記事では、加重ルーティングとヘルスチェックの連動の仕組み、そして計画的に片方を切り離す場合の注意点まで、実運用に役立つ観点で整理します。

加重ルーティングの基本とよくある誤解

まず押さえておきたいのが、「加重ルーティング」は複数エンドポイントへのトラフィックを比率で分配する仕組みだという点です。

ここでよくある誤解が、「重み（Weight）は合計100にしなければならない」というもの。
実際には、比率だけが重要であり、合計値は任意です。

たとえば：

つまり、Route 53は「合計値100」という前提で動いているわけではなく、「相対比」でトラフィックを分けています。

Dual-ACT構成の場合、通常は「50：50」や「60：40」としてトラフィックを意図的に分散。
一方のリージョンを計画的に停止（メンテナンス作業など）したいときは、単純にWeightを「0」に設定すれば、そのリージョンを一時的に切り離すことができます。

ヘルスチェックがルーティングに与える影響

Route 53のヘルスチェックは、HTTP(S)レスポンスやTCP接続を定期的に監視し、一定回数失敗した場合に「異常（Unhealthy）」と判定します。

このヘルスチェック結果は、ルーティングの可否を直接左右します。
具体的には、「Weightが設定されていても、ヘルスチェックが異常ならDNS応答の対象外になる」という仕組みです。

たとえば以下のような構成を考えます。

リージョン	Weight	ヘルスチェック	状態	トラフィック比率
東京	50	正常	稼働中	50%
大阪	50	正常	稼働中	50%

この状態で、もし東京リージョンのアプリケーションが落ちてヘルスチェックが異常になった場合、
Route 53は自動的に東京のレコードをルーティング対象から除外します。

結果、大阪が100%のトラフィックを受け持つようになります。
これがDual-ACT構成の大きな強みで、DNSレベルで自動的に片系運用へフェイルオーバーできる点です。

Dual-ACT構成でRoute 53を運用していると、「片方を計画的に切り離す」という場面がよくあります。
このときの挙動を正しく理解しておかないと、障害時にDNSが応答しなくなるといった想定外の事態を招くことがあります。

たとえば大阪リージョンをメンテナンス中として、Weightを「0」に設定していたとします。
この場合、大阪のレコードはRoute 53のルーティング対象外になります。

もしこの状態で東京リージョンが落ちた場合、
Route 53は「どのエンドポイントにもトラフィックを流せない」状態になります。

結果としてDNSクエリに有効なレコードを返せず、ユーザーは以下のような事象に直面します。

つまり、Weight=0にした側は自動復帰しない という点に注意が必要です。
障害時の自動切り替えを担保したい場合は、Weightを0にする代わりに「ヘルスチェックを一時停止」する方法も検討できます。

このケースでは、Weightが0なのでルーティング対象にはなりませんが、ヘルスチェックは引き続き実行されています。
そのため、異常が検知されること自体は問題ありません。

ただし、復旧してWeightを戻しても、ヘルスチェックが正常（Healthy）に戻るまではトラフィックが流れない点に注意。
手動復帰の際は、Route 53コンソールまたはCLIでヘルスチェック状態を必ず確認しましょう。

Dual-ACT構成でRoute 53を設計・運用するうえで、以下の3点を明確に理解しておくことが重要です。

特に、「Weight=0にしたリソースは自動でフェイルオーバーしない」という仕様は誤解されやすいポイントです。
障害時の自動切替を狙うなら、“切り離す”手段をWeight操作だけに頼らない設計が求められます。

Route 53の加重ルーティングは一見シンプルですが、運用設計次第で可用性が大きく変わります。
「自動×手動」の両輪を意識した設計こそが、堅牢なDual-ACT構成を支える鍵です。