Amazon Route 53：ルーティングポリシー、ヘルスチェック、Traffic Flow
Tony Duong
3月 29, 2026 · 3 分
#aws#route-53#dns#health-check#failover#latency-routing#geolocation#traffic-flow#cloudops#certification
Route 53 のルーティングポリシーは、クライアントに返す DNS 回答を制御する。プロキシではない：DNS はクエリに答えるだけで、クライアントが応答内の IP またはホスト名へ HTTP/TCP で接続する。Application Load Balancer がバックエンドに振り分けるのとは別物。
前提： レコード、TTL、alias と CNAME → Amazon Route 53: DNS Fundamentals, Records, TTL, and Alias vs CNAME。
Simple ルーティング
- デフォルト：多くの場合一つのターゲット（例：一つの A レコード値）。
- 同一 simple レコードに複数の IPv4/IPv6 を入れられる；リゾルバは複数アドレスを返しクライアントが一つ選ぶ（コースではランダムと説明されることが多い）。
- Alias + simple：一つの AWS ターゲット（例：一つの ALB）のみ。
- simple ルーティングでは Route 53 ヘルスチェックは使わない（コースモデル）。
Weighted ルーティング
- 同じ 名前・タイプの複数レコード；それぞれに重み（相対整数）。
- 各レコードのトラフィック割合 ≈ weight / sum(weights) — 合計100である必要はない。
- 用途： リージョン間の分割、新バージョンのカナリ（小さい重み）、段階的切替、重み 0 でターゲットを枯らす（コース：すべての重みが 0 のとき均等に振る舞う場合あり — 最新ドキュメントで確認）。
- 設計でヘルスチェックを使う場合、各 weighted レコードに任意でヘルスチェック。
Latency ベースのルーティング
- Route 53 は、クエリを出す DNS リゾルバから見て AWS リージョン（そのレコードに紐づく）の測定レイテンシが最小の一つのレコードを返す — 地図上の「最短距離」ではなく、そのレコードのリージョンに対する AWS のレイテンシ視点。
- 素の IP（例：EC2 パブリック IP）では、レコードにリージョンを指定しなければならない（Route 53 は IP からリージョンを推論しない）。
- 任意のヘルスチェック；設定すれば unhealthy なレコードは省略可能。
- 検証： ブラウザの位置 vs CloudShell の dig（別リージョンのリゾルバ）vs VPN 出口国 — 「最寄り」リージョンが変わる — VPN 切替時は TTL キャッシュに注意。
Failover ルーティング
- 同一名前の プライマリ と セカンダリ（アクティブ／パッシブ風）レコード。
- プライマリは必ず ヘルスチェックと紐付け（コースの手順では必須）。
- プライマリが unhealthy なら回答がセカンダリにフェイルオーバー（セカンダリにも任意でヘルスチェック）。
- 用途： プライマリのヘルス失敗時の DR またはスタンバイ。
Geolocation ルーティング
- エンドユーザーの地理的位置（大陸、国、対応する 米国州 など）でルート — latency ベース（リゾルバ視点の「最寄り AWS リージョン」）とは別物。
- より細かいルールが優先（例：州 > 国 > 大陸）。
- どのルールにも当てはまらない向けに デフォルトの geolocation レコードを用意すべき（例：「その他」→ 英語サイト）。
- 用途： ローカライズ、コンプライアンス／コンテンツ制限、地域に合ったスタックへの誘導。
- 任意のヘルスチェック。
Geoproximity ルーティング
- ユーザーとリソースの地理に bias を加え、あるユーザーにとってどのエンドポイントが「勝つ」かをずらす。
- リソースは AWS リージョン（一覧から）または 緯度／経度 の 非 AWS ロケーション（例：オンプレ）。
- 正の bias でそのリソースへの選好を広げ、負の bias で狭める — DNS 名を変えずにトラフィックを誘導（枯らす／優先など）。
- コンソールの話では Route 53 Traffic Flow（ビジュアルエディタ）で bias とマップを設定。
Multi-value 回答ルーティング
- 目的： 同一 DNS 名で複数リソースの回答を返す — クライアント側の分散：リゾルバが複数の A/AAAA を返しクライアントが一つ選ぶ（ELB がトラフィックをプロキシするのとは違い — multi-value は ELB の代替ではない）。
- ヘルスチェック付きではコースの話ではクエリあたり最大八つの健全な回答 — unhealthy は回答から落ちる。
- 各 multi-value レコードは別行（同一 name/type）で一つの IP と任意のヘルスチェック — simple で一レコードに複数 IP かつヘルスチェックなしとは別（simple マルチ IP には死んだバックエンドが混ざりうる）。
- ラボのコツ： コンソールの Invert health check status で一時的に healthy／unhealthy を反転し、セキュリティグループを変えずに障害をシミュレート。
IP ベースのルーティング
- クエリに対して Route 53 が見るクライアントの送信元 IP を定義した CIDR に照合し、対応するエンドポイントを返す。
- 用途： 既知の ISP／企業の IP レンジへの誘導、クライアントネットが予測できるときのコストや性能調整。
Route 53 ヘルスチェック
役割
ヘルスチェックにより Route 53 は weighted、latency、failover、geolocation、geoproximity、multi-value など（対応時）で不健全なターゲットを返さなくできる。
エンドポイントヘルスチェック（パブリック）
- ターゲットはパブリックインターネットから到達可能である必要（ALB、EC2 パブリック IP、パブリックに解決するホスト名など）。
- 多数のグローバルヘルスチェッカーノード（コースでは ~15 程度）がプローブ。
- プロトコル： HTTP、HTTPS、TCP（コンソールのオプション含む）。
- 十分なチェッカーが成功を報告すれば healthy — コースは「エンドポイント healthy」の閾値に 18% 超のチェッカーが healthy とする説明（正確な規則はドキュメントで確認）。
- 間隔： 標準（例：30 秒） vs 高速（10 秒、高コスト）。
- 成功： HTTP(S) では通常 2xx または 3xx；本文先頭 5120 バイトの文字列マッチは任意。
- セキュリティグループ／NACL／ファイアウォール： テストするポートとパスへ、AWS が公開する Route 53 ヘルスチェッカー IP レンジからのインバウンドを許可する必要がある。
計算ヘルスチェック
- 親ヘルスチェックが子を AND／OR／NOT で集約（例：「M 個中 N 個以上が通れば healthy」）。
- コースでは子は最大 256 まで — クォータは要確認。
プライベートまたは到達不能なエンドポイント
- パブリックチェッカーは RFC1918 の VPC のみのエンドポイントには直接届かない。
- パターン： プライベートリソースからメトリクスを出す（CloudWatch エージェント、カスタムメトリクス）→ CloudWatch アラーム → アラーム状態を追跡するヘルスチェック — アラーム = unhealthy で DNS をその経路から外す。
可観測性
- ヘルスチェックは CloudWatch メトリクスを公開（コンソールでは失敗時のアラーム／SNS も可）。
Traffic Flow（ポリシー）
- weighted、failover、latency、geolocation、multi-value、geoproximity、ネストしたルール、エンドポイントなど複雑な木をビジュアル編集。
- ポリシーはバージョン管理され、hosted zone に policy record として適用可能。
- 料金： コースでは Traffic Flow の policy record に月額がかさむ（デモでは policy record あたり約 50 ドル／月 — 最新 Route 53 料金 を確認）；検証用は削除。
- Traffic Flow から作ったレコードは、静的な一行だけでなくポリシーへ戻って編集することが多い。
要点
- 「ルーティングポリシー」 = DNS 回答の選び方 — Route 53 をプロキシのようにトラフィックが通るわけではない。
- Simple： 一ターゲット（またはマルチ IP のクライアント側ランダム）；alias simple = 一つの AWS ターゲット；基本ストーリーではヘルスチェックなし。
- Weighted： 相対重み → 比例配分；重み 0 で枯らす；ヘルスチェックは任意。
- Latency： レコードごとに宣言した AWS リージョンへの最小レイテンシ；素の IP にはリージョン指定；VPN／リゾルバ位置で検証。
- Failover： プライマリ + セカンダリ；ラボではプライマリにヘルスチェック必須。
- Geolocation： ユーザーの所在地（国／大陸など）；デフォルトを追加；latency とは別。
- Geoproximity： bias で リージョンや lat/long エンドポイント間の選好をシフト；高度な設定は Traffic Flow。
- Multi-value： 回答あたり最大 ~8 個の健全 IP；クライアントが選択；ELB ではない；simple マルチ IP よりヘルスを意識できる。
- IP ベース： クライアント CIDR でルート。
- ヘルスチェック： パブリックエンドポイント + チェッカー IP の SG 許可；計算で論理組合せ；プライベート負荷には CloudWatch アラーム ヘルスチェック。
前へ：Amazon Route 53: DNS Fundamentals, Records, TTL, and Alias vs CNAME。次へ：Amazon Route 53: Registrar Delegation, Resolver, Logging, and Governance。
Claudeによる翻訳
