Route 53のルーティング方式は、名前だけ暗記するとすぐ混乱します。SAA-C03では「どの要件なら、どの方式が自然か」を判断できるようにしておくと、選択肢を消し込みやすくなります。この記事では、加重・レイテンシ・位置情報・地理的近接性・フェイルオーバーを、設計の意図と具体例で整理します。
ルーティング方式を選ぶ前に整理したいこと
まずは、Route 53がやっていることを一段抽象化して捉えます。Route 53はDNSサービスなので、最終的には「名前解決の応答として、どのレコード値を返すか」をポリシーで決めています。つまり、ロードバランサーのように“通信を中継して振り分ける”のではなく、“DNS応答を切り替える”仕組みです。
この前提を踏まえると、ルーティング方式はだいたい次の問いに分解できます。
- 割合で振りたいのか（段階リリース、A/B、Blue Green）
- ユーザー体感の遅延を下げたいのか（世界中に利用者がいる）
- 地域で出し分けたいのか（国別のコンテンツ、配信制限）
- 物理的距離に寄せたいのか（距離に加えて寄せ方を調整したい）
- 障害時の切り替えを明確にしたいのか（アクティブ パッシブ）
この整理ができると、試験でも実務でも「要求から逆算してポリシー名にたどり着く」動きができます。
学習を効率化したい場合は、Route 53を含むネットワーク全体を“構成要件→選定→設定”の順に体系立てて学べる教材を1つ持つのが楽です。UdemyでもSAA-C03向けにハンズオン中心で学べる講座がいくつかあります。選ぶときは、Route 53単体ではなくVPC・ELB・CloudFront・可用性設計まで一気通貫で扱っているものが相性良いです。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
加重ルーティングは割合でコントロールしたいときの定番
加重ルーティングは、同じ名前・同じレコードタイプのレコードを複数用意して、それぞれに重みを付け、DNS応答を確率的に振り分ける方式です。段階リリースやA/Bテストの文脈でよく登場します。
典型パターン
- 新バージョンをいきなり100%にせず、最初は 10%だけ 新環境に流して様子を見る
- 問題なければ 10%→30%→50%→100% のように徐々に比率を上げる
たとえば app.example.com に対して、ALB AとALB Bを用意し、Aを90、Bを10にすれば「だいたい9:1」で名前解決が返るイメージです。
混乱しやすいポイント
- 重みは“割合”であって“厳密な分配保証”ではない
DNSはキャッシュされます。クライアントやリゾルバのキャッシュ挙動によって偏りが出ることがあるため、トラフィックの“きっちり10%”を期待する用途には向きません。ここは試験でも引っかかりやすいです。 - 重み0の扱い
重みを0にすると通常は選ばれませんが、ヘルスチェックと組み合わせたときの挙動が独特です。加重レコード群のうち、重み>0がすべて不健全になると、0のレコードも候補として扱われるケースがあります（最終退避のような動き）。
レイテンシーベースは最寄りではなく最小遅延を狙う
レイテンシーベースルーティングは、複数リージョンにエンドポイントがある前提で、Route 53が「ユーザーにとって最も低レイテンシになりやすいリージョン」を選んで応答する方式です。
典型パターン
- 東京リージョンとバージニアリージョンに同じアプリを展開し、ユーザーの体感を下げたい
- グローバル展開していて、単一リージョンだと遠方ユーザーが遅い
混乱しやすいポイント
- 最寄りの“地理的距離”ではなく、あくまで“レイテンシ”の判断
距離が近くてもネットワーク経路次第で遅いことはあります。Route 53の判断は、ユーザーとAWSデータセンター間の計測データに基づく点が注意点として明記されています。 - ヘルスチェックと組み合わせると、最小レイテンシ先が不健全なら次点に回る
「低遅延」と「可用性」をセットで満たしたいときに自然な設計です。
位置情報ルーティングと地理的近接性ルーティングは目的が違う
ここはSAA-C03学習者が混乱しやすい組み合わせです。両方とも“地理”に関係しますが、狙っていることが違います。
位置情報ルーティングは地域で出し分ける
位置情報ルーティングは、DNSクエリの送信元の地理情報にもとづいて「この国からはこのエンドポイント」といったルールベースの出し分けをします。
典型パターン
- 欧州向けはフランクフルト、APAC向けは東京のように地域ごとに固定で振りたい
- 国によってコンテンツを切り替える、配信権利の都合で地域制限したい
ポイントは「この地域はここ」と意図的に固定することです。ユーザー体感の遅延最小化が主目的なら、まずレイテンシーベースが候補に上がります。
地理的近接性ルーティングは距離に寄せつつ寄せ方を調整できる
地理的近接性ルーティングは、ユーザーとリソースの地理的な近さに基づいてルーティングし、さらにbiasで“寄せ方”を調整できます。
典型パターン
- 近い拠点に誘導したいが、片方の拠点が強いので少し多めに寄せたい
- 逆に、ある拠点を混ませたくないので寄せる量を減らしたい
biasの指定で、あるリソースに割り当てられる地理領域を広げたり縮めたりできます。
混乱しやすいポイント
- 位置情報は“地域のルール”、近接性は“距離＋調整”
地域で固定したいなら位置情報、距離で自然に寄せたいなら近接性、という切り分けが基本です。 - Traffic Flowの文脈が絡む
ドキュメント上もTraffic Flowコンソールの更新に触れており、可視化マップがTraffic Flowで提供されるなど、周辺機能として語られることがあります。
試験対策としては「biasで寄せ方を調整できる距離ベース」という本質を押さえるのが効きます。
フェイルオーバーはプライマリとセカンダリを明確にしたいときに使う
フェイルオーバールーティングは、プライマリが健全ならプライマリ、不健全ならセカンダリへ切り替える、というアクティブ・パッシブの考え方に素直な方式です。
典型パターン
- 本番リージョンが落ちたらDRリージョンへ切り替えたい
- S3静的サイトをプライマリ、別系統をセカンダリにするなど、エンドポイント種別は幅広い
ヘルスチェックが前提になる理由
フェイルオーバーの“切り替え判断”は、Route 53のヘルスチェックや関連設定に依存します。ヘルスチェックの概要や作成・通知などの流れは公式ドキュメントでも整理されています。
ここで重要なのは、フェイルオーバーが「アプリケーションの内部状態を理解して切り替える」わけではなく、ヘルスチェックとして定義した観点で健全性を見ている、という点です。たとえばHTTPの200を返すだけのチェックにしていると、“アプリは壊れているのに200だけ返る”ケースでは切り替わりません。試験でも実務でも、何をもって健全とするかが設計の肝になります。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
Route 53のルーティング方式は、名前の暗記よりも「何を最適化したいのか」を言語化できるかが大事です。
- 加重ルーティングは割合で段階リリースやA/Bに向く
- レイテンシーベースは複数リージョンで体感遅延の最小化を狙う
- 位置情報ルーティングは地域ごとのルールで出し分ける
- 地理的近接性ルーティングは距離に寄せつつbiasで寄せ方を調整できる
- フェイルオーバーはプライマリとセカンダリを明確にし、ヘルスチェックで切り替える
SAA-C03の学習では、問題文の要件を「割合」「遅延」「地域」「距離」「障害切替」のどれに当てはまるかに分解してから、方式を選ぶ癖をつけるとブレにくくなります。仕組みがつながってきたら、Route 53単体で終わらせず、CloudFrontやALB、マルチAZ・マルチリージョン設計まで一気に手を動かせるUdemy講座を1本“体系的に学べる教材の一例”として持っておくと、理解が早くなります。
