導入
DR戦略を選んでも、実際に「利用者のリクエストをどう新しいリージョンへ向け直すか」という仕組みがなければ絵に描いた餅です。その切り替えの要がRoute 53です。
説明
Route 53は、DNSレベルでリージョン間の切り替えを自動化する中心的なサービスです。DR文脈で使う代表機能は次の2つです。
| 機能 | 役割 |
|---|---|
| ヘルスチェック | エンドポイントの死活監視（HTTP/HTTPS/TCP、CloudWatchアラーム連携も可） |
| フェイルオーバールーティングポリシー | プライマリのヘルスチェックが失敗したら自動でセカンダリへ切り替える |
flowchart TD
U["利用者"] --> R53["Route 53<br/>フェイルオーバールーティング"]
R53 -->|"ヘルスチェックOK"| PRI["プライマリリージョン"]
R53 -.->|"ヘルスチェックNG時のみ"| SEC["セカンダリリージョン（DR）"]
HC["ヘルスチェック"] -.監視.-> PRI
フェイルオーバールーティングは、パイロットライト以上の戦略（DRリージョンに何らかの稼働系がある場合）で使います。バックアップ&リストアのようにDRリージョンに何も起動していない場合は、Route 53切り替えの前にインフラそのものを作る作業が必要になるため、フェイルオーバールーティングだけでは完結しません。
複数リージョンにルーティングする他のポリシーとの使い分けも押さえておきます。
- フェイルオーバー: 通常時はプライマリ固定、障害時のみセカンダリへ（DR向け）
- レイテンシーベース: 利用者に最も近い（速い）リージョンへ振り分け（アクティブ-アクティブのマルチサイト向け）
- 加重: 比率を指定して段階的にトラフィック移行（カットオーバーのリハーサルにも使える）
読んでみよう
「セカンダリリージョンへの自動フェイルオーバーが必要」という要件は、ほぼそのままRoute 53のヘルスチェック＋フェイルオーバールーティングを指します。マルチサイト構成で両リージョンに常時トラフィックを流したい場合は、フェイルオーバーではなくレイテンシーベース（または加重）が正解になる点に注意してください。