マルチリージョンとフェイルオーバー ― Route 53の役割

導入

DR戦略を選んでも、実際に「利用者のリクエストをどう新しいリージョンへ向け直すか」という仕組みがなければ絵に描いた餅です。その切り替えの要がRoute 53です。

説明

Route 53は、DNSレベルでリージョン間の切り替えを自動化する中心的なサービスです。DR文脈で使う代表機能は次の2つです。

flowchart TD
    U["利用者"] --> R53["Route 53<br/>フェイルオーバールーティング"]
    R53 -->|"ヘルスチェックOK"| PRI["プライマリリージョン"]
    R53 -.->|"ヘルスチェックNG時のみ"| SEC["セカンダリリージョン（DR）"]
    HC["ヘルスチェック"] -.監視.-> PRI

フェイルオーバールーティングは、パイロットライト以上の戦略（DRリージョンに何らかの稼働系がある場合）で使います。バックアップ&リストアのようにDRリージョンに何も起動していない場合は、Route 53切り替えの前にインフラそのものを作る作業が必要になるため、フェイルオーバールーティングだけでは完結しません。

複数リージョンにルーティングする他のポリシーとの使い分けも押さえておきます。

• フェイルオーバー: 通常時はプライマリ固定、障害時のみセカンダリへ（DR向け）
• レイテンシーベース: 利用者に最も近い（速い）リージョンへ振り分け（アクティブ-アクティブのマルチサイト向け）
• 加重: 比率を指定して段階的にトラフィック移行（カットオーバーのリハーサルにも使える）

具体例

Route 53のルーティングポリシーは、DR戦略によって選ぶものが変わります。2社の対比で見ます。

• ウォームスタンバイ構成の予約サイト → フェイルオーバールーティング … 通常は全トラフィックを東京（プライマリ）へ。Route 53のヘルスチェックが東京の異常を検知したら、自動で大阪（セカンダリ）へ切り替え。「セカンダリへの自動フェイルオーバー」の定番。
• マルチサイト（アクティブ-アクティブ）の銀行 → レイテンシーベース … 東京と大阪の両方が常時本番トラフィックを受ける。各ユーザーを近いリージョンへ振り分けたいので、フェイルオーバーではなくレイテンシーベース（または加重）。片方が落ちれば残った方が全部を引き受ける。

注意点：バックアップ&リストアのようにDRリージョンに何も起動していない構成では、フェイルオーバールーティングだけでは不十分。切り替える前にインフラを作る作業（CloudFormation等）が必要だからです。「自動フェイルオーバーが要る＝ヘルスチェック＋フェイルオーバー、両リージョン常時稼働＝レイテンシーベース」と、DR戦略とセットで選びます。

読んでみよう

「セカンダリリージョンへの自動フェイルオーバーが必要」という要件は、ほぼそのままRoute 53のヘルスチェック＋フェイルオーバールーティングを指します。マルチサイト構成で両リージョンに常時トラフィックを流したい場合は、フェイルオーバーではなくレイテンシーベース（または加重）が正解になる点に注意してください。