Instiq
第3章 · エッジと DNS の設計·v2.0.0·更新 2026/6/3·読了目安 約12分

変更要約: ANS-C01 第3章を深掘り（トラフィックフロー/ヘルスチェック種別・エッジ関数2種/キャッシュキー・GA内部構成/ダイヤル＋比較表・シナリオ・FAQ・ひっかけ、図ja化）

3.1Route 53 とルーティングポリシー

この節の要点

DNS で賢く振り分ける——Route 53、レイテンシー/位置情報/加重/フェイルオーバー ルーティング、ヘルスチェック、エイリアスレコード——を理解します。目的に合うポリシーを選びます。

Route 53 は AWS の DNS サービスです。単に名前を IP に変換するだけでなく、ルーティングポリシーでトラフィックを賢く振り分けられます。

3.1.1主なルーティングポリシー

Route 53 のルーティングポリシーを示した図。app.example.com への DNS クエリを、レイテンシー（最も遅延の低いリージョンを返す）・位置情報（ユーザーの国/大陸で返す）・加重（割合で分割し A/B テストやカナリアに使う）・フェイルオーバー（ヘルスチェック＋プライマリ/セカンダリ）の各ポリシーに振り分け、目的（性能/ロケール/分割/可用性）でポリシーを選ぶこと、フェイルオーバーにはヘルスチェックが必要なことを示した図。
Route 53 のルーティングポリシー
  • レイテンシールーティング：ユーザーから最も遅延の低いリージョンへ振り分ける（性能重視）。
  • 位置情報ルーティング：ユーザーの国/大陸に応じて返す（コンプライアンスやローカライズ）。
  • 加重ルーティング：割合で分割。A/B テストや段階的リリース（カナリア）に使う。
  • フェイルオーバールーティング：ヘルスチェックでプライマリ障害時にセカンダリへ切替（可用性）。
試験ポイント

「性能で最寄りリージョン＝レイテンシー」「国/地域で分ける＝位置情報」「割合分割/カナリア＝加重」「障害時に切替＝フェイルオーバー（要ヘルスチェック）」 は ANS-C01 で頻出です。フェイルオーバーはヘルスチェックが前提です。

補足

ALB や CloudFront など AWS リソースを指す場合は「エイリアスレコード」を使います。エイリアスは追加料金がなく、IP 変化にも自動追従します。

ANS-C01 では「複数ポリシーの組み合わせ」と「ヘルスチェックの種類」が問われます。ポリシーは入れ子にできます。たとえば加重レコードの各ターゲットにフェイルオーバーを組み合わせ、最上位でレイテンシーに束ねるといった多段構成が可能で、これを実現するのが「エイリアスで別レコードセットを指す」トラフィックフロー（Traffic Flow）です。ヘルスチェックには、エンドポイントを直接監視するエンドポイント監視、複数のヘルスチェックを論理結合する計算済みヘルスチェック、CloudWatch アラームに連動するCloudWatch メトリクス連動の 3 種類があり、プライベートな対象は VPC 内からは到達できないため計算済みや CloudWatch メトリクスで代替します。地理的近接（Geoproximity）はリージョンからの距離にバイアス値を加減してトラフィックの引き寄せ範囲を調整でき、位置情報（Geolocation）が「国・大陸の一致」で返すのとは別物です。DNS は TTL の間キャッシュされるため、フェイルオーバーの実効切替時間は TTL に左右される点も設計上の要点です。

ポリシー決定基準主な用途
レイテンシー測定済みネットワーク遅延性能最優先のマルチリージョン
位置情報ユーザーの国/大陸の一致規制・言語ローカライズ・地域限定
地理的近接リージョンからの距離＋バイアス引き寄せ範囲を比率調整したい
加重設定した割合A/B・カナリア・段階移行
フェイルオーバーヘルスチェックの健全/不健全アクティブ/スタンバイの可用性
補足

シナリオ：東京と米国にアクティブ/アクティブの API を置き、各ユーザーを最速のリージョンへ送りつつ、片方が落ちたら自動で生存側へ寄せたい。→ 各リージョンのエンドポイントにヘルスチェック付きのレイテンシーレコードを設定する。不健全になったレイテンシーレコードは応答候補から外れるため、レイテンシー＋ヘルスチェックだけでアクティブ/アクティブのフェイルオーバーが成立する（明示的なフェイルオーバーポリシーは不要）。

補足

FAQ：Q. 位置情報と地理的近接はどう違う? A. 位置情報は「ユーザーがどの国/大陸か」で一致するレコードを返す離散的な判定。地理的近接は「リージョンからの距離」を連続量として扱い、バイアスで各リージョンの担当範囲を広げ/狭めできる。Q. フェイルオーバーが切り替わらない? A. TTL が長いとリゾルバのキャッシュが残り切替が遅れる。重要な切替対象は TTL を短くする。

注意

ひっかけ：「シンプルルーティングでもヘルスチェックでフェイルオーバーできる」は誤り。複数値（マルチバリュー）応答ルーティングはヘルスチェックで不健全な値を返さなくできるが、これはフェイルオーバーポリシーとは別物で、クライアント側で複数 IP から選ぶ簡易な可用性向上にとどまる。明示的なプライマリ/セカンダリ切替が要件ならフェイルオーバールーティングを使う。

3.1.2この節のまとめ

  • ポリシー＝レイテンシー/位置情報/加重/フェイルオーバーを目的で選ぶ
  • AWS リソースへはエイリアスレコード、切替にはヘルスチェック

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. グローバルなユーザーを、それぞれにとって最も応答の速いリージョンへ DNS で誘導したい。どのポリシーを使いますか？

Q2. 新バージョンへ全体の 10% のトラフィックだけを流して段階的に検証したい。どのポリシーを使いますか？

Q3. プライマリのエンドポイントが不健全になったら自動でセカンダリへ切り替えたい。何が前提として必要ですか？

理解度を確認第3章「エッジと DNS の設計」の問題を解く