Route 53 のフェイルオーバーとヘルスチェック（アクティブ／パッシブとアクティブ／アクティブ）
フェイルオーバールーティングとヘルスチェックの組み合わせ、プライマリ／セカンダリ構成と、アクティブ／アクティブを他ポリシーで実現する違いを整理します。
フェイルオーバールーティングの核
フェイルオーバー（Failover） ポリシーは、プライマリとセカンダリのレコード関係を定義し、ヘルスチェックの結果に応じて どちらの答えを返すかを切り替えます。クロスリージョンのスタンバイ構成や、メンテナンス時の意図的な切替の文脈で試験に出ます。
典型的な流れは次のイメージです。
- プライマリのターゲット（例: リージョン A の ALB）にヘルスチェックを関連付ける。
- チェックが健全なら、DNS 応答はプライマリ側のレコードを返す。
- 不健全になったら、セカンダリ（例: リージョン B）のレコードを返す。
セカンダリを「スタンバイ」として常時低トラフィックにするかはコスト設計の話であり、DNS は「どちらを返すか」を決めるレイヤーです。
アクティブ／パッシブとアクティブ／アクティブ（資料でよくある対比）
| パターン | ルーティングの考え方 | コメント |
|---|---|---|
| アクティブ／パッシブ | フェイルオーバーで片系を主、片系を待機 | RTO は待機系の立ち上がりやデータ同期に依存しがち |
| アクティブ／アクティブ | フェイルオーバー以外（加重・レイテンシー等）で複数系を同時に利用し、障害時は健全な系へ寄せる | 「常に両方アクティブ」だが、DNS ポリシーはフェイルオーバー以外が主役 |
試験では「両方稼働させつつ、片方障害で他方に寄せたい」→ 加重＋ヘルスや レイテンシー＋各系の健全性 など、フェイルオーバー以外のポリシーが正解になることがあります。文脈語句を丸暗記せず、**「プライマリ／セカンダリの二択か、複数同時か」**で先に分岐すると安定します。
ヘルスチェックの役割（ざっくり）
- エンドポイント監視 … HTTP/HTTPS、TCP、複数リージョンからのプローブなど。
- 条件の組合せ … しきい値・間隔・失敗回数で Healthy/Unhealthy を決定。
- アラーム連携 … CloudWatch アラームの状態をヘルスに反映する、といった拡張パターンが試験の選択肢に出ることがあります。
ELB のターゲットヘルスと Route 53 のヘルスチェックは別物ですが、「ユーザー向け DNS がどちらを返すか」の問題では Route 53 側のチェックが主役になることが多いです。
マルチバリューとの境界
マルチバリューは 複数の IP を返すためのポリシーで、各 IP にオプションでヘルスチェックを付けられます。これにより「不健全な IP は応答から外す」ことはできますが、L7 での均等負荷分散やスティッキーまでは担いません。ELB の代替という誤答に注意、が定番の論点です。
TTL・キャッシュと「切替が見える速さ」
フェイルオーバーが即座に全世界に伝わるわけではありません。再帰リゾルバやクライアントの TTL キャッシュの影響で、古い答えが残る時間帯があります。運用では TTL を短くする、アプリ側のリトライ、複数レイヤでの健全性などとセットで語られます。
あわせて読む（サイト内）
公式ドキュメント（短い導線）
重要ポイント
- ▸フェイルオーバーポリシーはプライマリが健全ならプライマリ、不健全ならセカンダリへ切り替えるのが基本形
- ▸ヘルスチェックはエンドポイント監視のほか、CloudWatch アラーム連携など拡張がある
- ▸アクティブ／アクティブはフェイルオーバー以外のポリシー（加重・レイテンシー等）で複数を生かす考え方
- ▸マルチバリューは複数 IP を返す用途で ELB とは役割が異なる
- ▸DNS 切替はキャッシュの影響を受けるため、TTL やクライアント挙動とセットで設計する
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
VPC とネットワーク設計 に関連するトピックを続けて確認できます。