Route 53のルーティングポリシーまとめ（位置情報ルーティングと地理的近接性ルーティングの違いは？）
この記事の要約
- 位置情報ルーティング
- ユーザーの位置情報（大陸・国・米国の州）を基準に振り分ける
- 「日本からのアクセスは東京」「それ以外はバージニア」のように、地域ごとに明示的に振り分け先を指定する
- 地理的近接性ルーティング
- ユーザーとリソースの地理的な距離を基準に、最も近いリソースへ振り分ける
- biasを設定することで、各リソースが受け持つ地域の範囲を調整できる
- 「位置情報」だけの点で判断したいのか、「近接性（距離）」という線で判断したいのかで覚えておく
AWSのDNSサービスである「Route 53」でレコードを作成するとき、ルーティングポリシーから応答方法を選びます。
ここでいつも混乱するのが、「位置情報ルーティング」と「地理的近接性ルーティング」です。たまに見返すときにどっちがどっちか分からなくなってしまいます……
今回はRoute 53のルーティングポリシー8種類をまとめつつ、位置情報と地理的近接性の違いについて自分なりに整理します。
DNSとRoute 53の基本
「DNS（Domain Name System）」は、ドメイン名に対応するIPアドレスなどの情報を返す仕組みです。
例えば当ブログ「Webrandum」のドメインは「webrandum.net」ですが、ブラウザが実際に接続するときはDNSから取得したIPアドレスを使います。
DNSはよく「電話帳」に例えられます。
実際に電話をかけるときは電話番号（数字の並び）を使いますが、それだけではパッと見で誰の番号か分かりません。
そこで、名前と電話番号を紐付けて電話帳に登録しておきます。
DNS（電話帳）に「このドメイン（人の名前）のIPアドレス（電話番号）を教えて」と聞いて、返ってきたIPアドレスを使うイメージです。
そのDNSの仕組みをAWS上で提供しているのがRoute 53です。
ドメインの登録やDNSレコードの管理に加えて、振り分け先が正常に動いているかを監視する「ヘルスチェック」もまとめて行えます。
ちなみにRoute 53の読み方は「ルート フィフティースリー」ですが、日本だと「ルート ごーさん」と読む人も見かけます。
また、名前の部分はアメリカの有名な国道「Route 66」にちなんだものだと言われていて、「53」という数字は、DNSが使用するポート番号の「53」が由来だそうです。
ルーティングポリシーの基本
ルーティングポリシーは、Route 53がDNSクエリにどのレコードで応答するかを決める設定です。
設定できるのは「このレコードにアクセスされたらここに返す」というシンプルなルールだけではありません。
「指定の比率で分けて返す」というA/Bテスト向けの設定や、「リソースが異常だったら別の場所に振り分ける」といったことも可能です。
ポリシーごとの詳しい仕様は、公式ドキュメントのルーティングポリシーの選択にまとまっています。
ルーティングポリシーの種類
2026年9月時点で、選べるルーティングポリシーは下記の8つです。
- シンプルルーティングポリシー
- 加重ルーティングポリシー
- レイテンシールーティングポリシー
- フェイルオーバールーティングポリシー
- 複数値回答ルーティングポリシー
- 位置情報ルーティングポリシー
- 地理的近接性ルーティングポリシー
- IPベースのルーティングポリシー
振り分けの基準と主な用途をまとめると下記の通りです。
| ポリシー | 振り分けの基準 | 主な用途 |
|---|---|---|
| シンプル | 振り分けない | 単一のリソースに向ける |
| 加重 | 指定した重みの比率 | カナリアリリース、A/Bテスト |
| レイテンシー | ユーザーからの通信の速さ | マルチリージョン構成の応答速度を改善する |
| フェイルオーバー | リソースの正常性 | アクティブ/パッシブ構成を作る |
| 複数値回答 | 正常な複数のレコード | DNSレベルで可用性を高める |
| 位置情報 | ユーザーの場所 | 言語切り替え、地域別の配信制限 |
| 地理的近接性 | ユーザーとリソースの距離 | 近いリソースへ振り分ける |
| IPベース | ユーザーのIPアドレス（CIDR） | ISP単位の最適化 |
シンプルルーティングポリシー
名前の通り、特別な振り分けを行わないルーティングです。
通常は1つのDNSレコードを1つのリソースに紐付けます。
1つのレコードに複数のIPアドレスを書くこともできますが、その場合は書いたすべての値がまとめて返されます。
加重ルーティングポリシー
レコードごとに0〜255の重みを設定し、その比率でDNSの応答を振り分けます。
新しいバージョンに少しだけトラフィックを流して様子を見る「カナリアリリース」やA/Bテストで使えるポリシーです。
重みを0にするとそのレコードは応答から外れますが、ヘルスチェックを設定している場合は重みが0より大きいレコードがすべて異常になると、重み0のレコードが選ばれます。
また、グループ内のすべてのレコードを0にすると、逆にすべてのリソースへ均等に振り分けられます。
レイテンシールーティングポリシー
複数のAWSリージョンにリソースがあるとき、ユーザーから見て最もレイテンシーが低いリージョンへ振り分けます。
しかし、AWSリージョン外のリソースを指定すると、同じ都市にあるサーバーでも実際のレイテンシーと大きくズレる可能性があります。
また、レイテンシーのデータはネットワークの状態に応じて更新されるため、振り分け先は固定ではありません。
フェイルオーバールーティングポリシー
「プライマリ」と「セカンダリ」のレコードを用意し、プライマリのヘルスチェックが異常になったときだけセカンダリを返すポリシーです。
AWSのドキュメントでは、プライマリにWebサーバー、セカンダリにS3の静的ウェブサイトを置く人もいると紹介されています。S3側には「一時的に使用できません」とだけ表示させておく構成です。
複数値回答ルーティングポリシー
1回のDNSクエリに対して、最大8件の正常なレコードをまとめて返すポリシーです。
レコードごとにヘルスチェックを紐付けられるため、異常なサーバーのIPアドレスを応答から除外できます。
正常なレコードが8件以下なら、そのすべてを返します。
9件以上ある場合は最大8件が選ばれるため、返される組み合わせは一定ではありません。
シンプルルーティングで複数の値を書く方法と似ていますが、レコードごとに正常性を確認できる点が大きな違いです。
しかし、AWSのドキュメントでも「ロードバランサーに代わるものではありません」と説明されています。
DNSのキャッシュが挟まるため、細かい負荷分散や即時の切り替えには向いていません。
位置情報ルーティングポリシー
DNSクエリの発信元（ユーザーの場所）を基準に振り分けるポリシーです。
なお、指定できるのは大陸・国・米国の州の3段階です。
範囲が重なるレコードを作った場合は、狭い地域のレコードが優先されます。
例えば「北米向け（大陸）」と「カナダ向け（国）」のレコードを作ると、カナダからのクエリではカナダ向け（国）のレコードが優先される仕組みです。
用途としては、アクセス元の国に応じて言語を切り替える、配信できる権利がある地域だけにコンテンツを出すといったものがあります。
どのレコードにも当てはまらない場所からのクエリに備えて、「デフォルト」のレコードを作っておくことが推奨されています（デフォルトが無いと、レコードを作っていない場所からのクエリには何も応答が返りません）。
地理的近接性ルーティングポリシー
ユーザーと各リソースの場所を比較し、地理的に一番近いリソースへ振り分けるポリシーです。
AWSのリソースであればAWSリージョンまたはLocal Zoneグループを指定し、AWS外のリソースであれば緯度経度を指定します。自社データセンターなど、AWS外のサーバーも振り分け先に含められるのが特徴です。
このポリシーでは、リソースごとに-99〜99の「bias（バイアス）」という範囲調整用の数値を設定できます。
正の値にするとそのリソースが受け持つ地域が広がり、負の値にすると狭くなります。
Route 53がbiasを反映するときの計算式（biasが正の値の場合）は下記の通りです。
バイアス適用後の距離 = 実際の距離 * [1 - (bias / 100)]ちなみに負の値を設定すると下記の計算式になります。
バイアス適用後の距離 = 実際の距離 / [1 + (bias / 100)]例えばユーザーから見て、WebサーバーAが150km、WebサーバーBが100kmの位置にある場合、そのままなら距離が近いBに振り分けられます。
しかし、Aにbias +50を設定すると75kmとして扱われるため、Aの方が近いという判定になります。
IPベースのルーティングポリシー
ユーザーのIPアドレスが、どのCIDRブロック（IPアドレスの範囲）に含まれるかを基準に振り分けます。
IPアドレスとリソースの対応表を自分でRoute 53へ登録して使うポリシーです。
特定のISPからのユーザーを特定のリソースへ寄せて通信コストを下げる、位置情報ルーティングの判定を上書きするといった使い方が想定されています。
位置情報と地理的近接性の違い
さて、位置情報ルーティングポリシーと地理的近接性ルーティングポリシーは、どちらもパッと見ではユーザーの場所を基準にしているように見えてしまいます。
大きな違いは、位置情報がユーザーの場所だけを見るのに対して、地理的近接性はユーザーとリソースの距離を見ている点です。
| 項目 | 位置情報 | 地理的近接性 |
|---|---|---|
| 基準にする場所 | ユーザーの場所 | ユーザーとリソースの場所 |
| レコードに指定するもの | 大陸・国・米国の州 | リソースの場所（リージョン・Local Zoneグループ・緯度経度） |
| 振り分け先 | 指定した地域に紐付けたリソース | 距離が一番近いリソース |
| 範囲の調整 | 地域の単位で固定 | biasで拡大・縮小できる |
| デフォルトレコード | 未定義の地域を受けるために推奨 | 不要 |
| 正常性を評価する場合 | より広い地域の正常なレコードを探す | 他の正常なリソースを探す |
例えば、日本のユーザーには東京リージョンの日本語サイトを、それ以外の国にはバージニア北部リージョンの英語サイトを見せたいケースを考えます。
位置情報ルーティングポリシーなら、「日本 → 東京リージョン」「デフォルト → バージニア北部リージョン」の設定をして実現できます。
それに対して、地理的近接性ルーティングポリシーだとそうはいきません。
仮にオーストラリアからアクセスがあった場合、北米より日本の方が近いため、東京リージョンの日本語サイトが表示されてしまいます。
このように、国などの位置情報だけで決めたいのか、リソースとの距離で決めたいのかでどちらを使うのかが変わってきます。
まとめ
位置情報ルーティングと地理的近接性ルーティングは、どちらも位置情報を使いそうな名前なので久しぶりに見たりすると混乱してしまいます。
ただ、「位置情報」だけの点で判断したいのか、「近接性（距離）」という線で判断したいのかで覚えておくと間違いもなさそうです。
それ以外のほとんどのルーティングポリシーは名前で何ができるのか何となく分かるので、そこまで難しくはないかなと思いますし、調べれば済みます。
しかし、何ができるか知らない状態だと、Route 53側だけで完結する内容をわざわざアプリケーション側で作り込んでしまいます。
すべての細かい仕様を覚える必要はありませんが、どんなことができるかだけでも頭に入れておくと、役に立つ場面が来るかもしれません。
