変更要約: SOA-C02 第5章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
5.2Route 53 と DNS ルーティング
Route 53 のホストゾーンとレコード、ヘルスチェック、ルーティングポリシー（フェイルオーバー/レイテンシ/地理/加重/シンプル）の使い分けを理解します。
ドメイン名をどのエンドポイントへ向けるかを制御するのが Amazon Route 53 です。ルーティングポリシーを要件に合わせて選ぶのが運用のポイントです。
5.2.1ルーティングポリシー
- フェイルオーバー：ヘルスチェックでプライマリ障害時にセカンダリへ（アクティブ-パッシブ）。
- レイテンシ/地理：最も低遅延のリージョン、または地理的位置でルーティングする。
- 加重：割合でトラフィックを分割（カナリア/AB テスト）。シンプルは単一レコード。
- ヘルスチェック：エンドポイントの健全性を監視し、フェイルオーバー等と連携する。
Route 53 は「DNS＋ヘルスチェック」で、ルーティングポリシーを要件に合わせて選びます。シンプル は単一レコード（複数値なら順不同で返す）、フェイルオーバー はヘルスチェックでプライマリ障害時にセカンダリへ（アクティブ-パッシブ）、レイテンシ は最も低遅延のリージョンへ、地理（Geolocation） は利用者の国/地域で、地理的近接（Geoproximity） は位置＋バイアスで、加重（Weighted） は割合でトラフィックを分割（カナリア/AB テスト）します。AWS リソース（ALB/CloudFront/S3 ウェブサイト）へは Alias レコード（ゾーンエイペックスにも使え、追加課金なし）を使い、外部には CNAME を使います。可用性の鍵は ヘルスチェック（エンドポイント/他のヘルスチェック/CloudWatch アラームベース）で、フェイルオーバーや「異常なら配信から除外」に連携します。TTL を小さくすると切り替えは速くなりますが問い合わせが増えます。DNS は結果的に伝播するため、TTL を見越した設計が重要です。
| 要件 | ポリシー |
|---|---|
| 障害時に別サイトへ | フェイルオーバー |
| 最も近い（低遅延）リージョンへ | レイテンシ |
| 国/地域で出し分け | 地理（Geolocation） |
| 割合で段階公開 | 加重（Weighted） |
シナリオ：東京を主、大阪を待機にして広域障害に備える。 フェイルオーバールーティング＋ヘルスチェックで、東京（プライマリ）が異常になったら大阪（セカンダリ）へ自動切替。エンドポイントは ALB なので Alias レコードで指定。切り替えを速めるため TTL を短めに設定し、新バージョンの段階公開には 加重ルーティングを併用します。
Q. 障害時に別サイトへ？ フェイルオーバー＋ヘルスチェック。Q. 最も近いリージョンへ？ レイテンシ。Q. 国で出し分け？ 地理。Q. 10%だけ新版へ？ 加重。Q. ALB/CloudFront を指すには？ Alias レコード（ゾーンエイペックス可・無料）。
混同に注意：
①レイテンシ（速さ）と地理（位置）は別物——「最寄り＝地理」は誤りになりがち（速さはレイテンシ）。
②ゾーンエイペックス（example.com）に CNAME は使えない——Alias を使う。
③フェイルオーバーにはヘルスチェック必須。
④TTL を長くすると切り替えが遅れる（DNS は即時反映ではない）。
「障害時に別サイトへ＝フェイルオーバー」「最も近いリージョンへ＝レイテンシ」「割合で段階公開＝加重」「国/地域で出し分け＝地理」 の使い分けは SOA で頻出です。ALB/CloudFront へは Alias レコードを使います。
5.2.2この節のまとめ
- 要件でフェイルオーバー/レイテンシ/地理/加重を選ぶ
- ヘルスチェックでフェイルオーバーを実現
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. プライマリのエンドポイントが落ちたら自動でセカンダリへ切り替えたい。どの Route 53 ルーティングを使いますか？
Q2. 新バージョンへ全体の10%だけトラフィックを流して段階公開したい。どのルーティングを使いますか？
Q3. ユーザーを最も低遅延のリージョンへ誘導したい。どのルーティングを使いますか？