Amazon Route 53 ルーティングポリシー完全ガイド｜フェールオーバー・レイテンシー・加重・ジオロケーションの設計判断と実践

マルチリージョン展開を終えたとき、次の壁として立ちはだかるのが「どのリージョンへ、どんな条件でトラフィックを振り向けるか」というDNSレイヤーの設計だ。オンプレ時代はBINDや商用DNSアプライアンスで制御していたフェールオーバーやロードバランスを、クラウドではRoute 53のルーティングポリシーで解決できる。

この記事では、Amazon Route 53が提供する6種類のルーティングポリシーを実務シナリオに照らしながら解説する。どのポリシーをいつ選ぶか、複数ポリシーを組み合わせた階層設計はどう組むか、ヘルスチェックとはどう連携するかまでを現場目線で整理する。Route 53の基本的なDNS設定についてはAmazon Route 53入門を先に参照していただきたい。

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

Route 53のレコードセットには「ルーティングポリシー」を設定できる。ポリシーは「同じドメイン名に対して複数のエンドポイントが存在するとき、どのエンドポイントへのIPアドレスをクライアントに返すか」を決めるロジックだ。

DNS応答はクライアント（またはリゾルバー）へのIPアドレス通知であり、実際の通信経路をRoute 53が制御するわけではない。この点はオンプレのロードバランサーと根本的に異なる。TTLの設定がフェールオーバー速度に直結するのはそのためだ。

6種類のポリシーと主な用途をまとめると以下のとおりだ。

シンプルルーティング

最も基本的なポリシーで、1レコードセットに対して1つ（または複数のIPをまとめた1応答）のエンドポイントを返す。ヘルスチェックと組み合わせられないため、単一構成の開発・ステージング環境や、可用性が不要なバッチ処理用のエンドポイントに使う。

1レコードに複数のIPを返す設定（マルチバリューアンサー）は技術的には可能だが、負荷分散ではなくDNSラウンドロビンになり、障害時に不健全なIPを返し続ける可能性がある。本番トラフィックの制御には後述のポリシーを使うほうが安全だ。

フェールオーバールーティング

Primary（本番系）とSecondary（待機系）の2レコードを設定し、Primaryのヘルスチェックが失敗したときにSecondaryへ自動切り替えするポリシーだ。Active-Passive構成のDR設計で最もよく使われる。

1. ヘルスチェックの設計

フェールオーバールーティングではヘルスチェックが正確に機能することが前提だ。設定のポイントを整理する。

・エンドポイントの種類: IPアドレス・ドメイン名・他のRoute 53ヘルスチェックの3タイプを選べる
・プロトコル: HTTP・HTTPS・TCPのいずれか。本番エンドポイントはHTTPSでアプリ固有のヘルスエンドポイント（例: /health）を指定する
・評価期間: チェック間隔は30秒（標準）または10秒（高速・追加料金）。失敗判定は連続失敗回数で決まる
・CloudWatchとの連携: ヘルスチェック結果をCloudWatchメトリクスで監視し、アラームと連携させることでチーム通知まで一元化できる

2. フェールオーバーの仕組みと注意点

TTLを低く設定（60秒程度）しないとDNSキャッシュの影響でフェールオーバーに時間がかかる。一般的な設定例は以下のとおりだ。

# フェールオーバーレコードの設定例（AWS CLI）
aws route53 change-resource-record-sets   --hosted-zone-id ZXXX   --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "HealthCheckId": "aaaa-bbbb-cccc",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.1"}]
      }
    }]
  }'

フェールオーバー後にPrimaryが回復すると、自動でPrimaryに戻る（自動切り戻し）。計画的メンテナンスで意図的にSecondaryへ向けたいときは、一時的にPrimaryのヘルスチェックを無効化する方法が使いやすい。

DR戦略との組み合わせについてはAWS DR戦略4パターン比較も参考にしてほしい。

レイテンシーベースルーティング

クライアントからAWSリージョンへのネットワークレイテンシーを測定し、最も応答が速いリージョンのエンドポイントへトラフィックを誘導するポリシーだ。グローバルサービスを複数リージョンに展開するときの標準的な選択肢になる。

注意すべきは、レイテンシー測定はリアルタイムではなく、AWSがリージョン間で定期的に収集しているサンプリングデータに基づいている点だ。「その瞬間に最も速い」ではなく「統計的に最も速い傾向にある」リージョンへ向く、という理解が正確だ。

1. 設計の典型パターン

・東京リージョン（ap-northeast-1）: 日本・韓国ユーザーが主な対象
・バージニア北部（us-east-1）: 北米・欧州ユーザーへのカバー
・フランクフルト（eu-central-1）: 欧州ユーザーのレイテンシー低減

マルチリージョン設計全体の考え方についてはAWSマルチリージョン設計入門を参照してほしい。

2. Global Acceleratorとの比較

レイテンシーベースルーティングはDNSレイヤーの制御だが、AWS Global AcceleratorはAWSバックボーンネットワーク上のルーティングで、実際のパケット転送経路も最適化する。接続安定性やロングLIVEなTCPセッションが重要なアプリケーション（ゲーム・IoT・金融取引）はGlobal Acceleratorが向く。WebのHTTPS APIならRoute 53のレイテンシーポリシー＋CloudFrontの組み合わせが軽量で管理しやすい。

加重ルーティング

複数のエンドポイントに「重み（0～255の整数値）」を割り当て、その比率に応じてトラフィックを分散するポリシーだ。カナリアリリース・A/Bテスト・段階的なブルーグリーン切り替えに活用できる。

1. カナリアリリースへの適用

新バージョンのデプロイ時に以下のような段階的移行が可能だ。

重みを0に設定するとそのエンドポイントへのルーティングが停止する（レコードは残る）。旧バージョンへのロールバックは0→元の値に戻すだけで済み、オペレーションがシンプルだ。デプロイ戦略全体の詳細はBlue/GreenデプロイとカナリアリリースのAWS実践ガイドも参考にしてほしい。

2. よくある誤解

加重ルーティングはリクエストをセッション単位で固定しない。同一クライアントが連続してアクセスしても、毎回の名前解決で確率的に振り分けられる。セッションをまたいで同じバージョンへ誘導したい場合は、ALBのスティッキーセッションやCookieベースのルーティングと組み合わせる必要がある。

ジオロケーションルーティング

クライアントのIPアドレスから推定される地理的な位置（国・大陸・米国の州レベル）に基づいてルーティングするポリシーだ。レイテンシーとは関係なく「どの国のユーザーにどのエンドポイントを見せるか」を明示的に制御したいときに使う。

1. 向くシナリオ

・法規制対応: EU圏（GDPR）のユーザーデータをEUリージョンに閉じる必要があるケース
・地域別コンテンツ配信: 日本語サイトと英語サイトで異なるドメインを使わず、同一ドメインで言語切り替えをDNSレイヤーで行う
・著作権・ライセンス制約: 特定国でのコンテンツ提供が制限される場合に対象国を別エンドポイントへ向ける

2. デフォルトレコードの重要性

ジオロケーションルーティングでは、定義した地域に該当しないクライアントはデフォルトレコードへ向く。デフォルトレコードを設定しないと該当外クライアントへの応答が返らず、DNSが解決できない状態になる。必ず「デフォルト」レコードを用意すること。

ジオプロキシミティルーティング

エンドポイント（AWSリージョンまたは任意の緯度経度）に「バイアス値」を設定し、地理的な境界を意図的にずらしてトラフィック比率を調整するポリシーだ。ジオロケーションは「この国はここ」という固定マッピングだが、ジオプロキシミティは「このリージョンへの誘引力を強めたり弱めたりする」イメージで捉えると理解しやすい。

ただし設定にTraffic Flow（月額$50程度・2026年時点）が必要であるため、コストと運用の複雑さを考慮した上で採用を判断すること。シンプルな地域分割はジオロケーションで十分なケースが多い。

複合ルーティング設計：ポリシーの階層化

Route 53では複数のポリシーを組み合わせた「エイリアスレコードによる階層設計」が可能だ。実務でよく使われるパターンを紹介する。

1. レイテンシー＋フェールオーバーの組み合わせ

グローバルサービスで最もよく使われるパターンだ。構成の考え方は以下のとおり。

・親レコード（レイテンシーポリシー）: ユーザーを最寄りのリージョンへ誘導する
・子レコード（フェールオーバーポリシー）: 各リージョン内でPrimary（例: ECS）とSecondary（例: S3静的ページ）を切り替える

親レコードのターゲットを子レコードに設定（エイリアス）することで、「東京ユーザーは東京リージョンへ向き、東京リージョンのプライマリが落ちたら東京リージョンのセカンダリへ」という動作を実現できる。

2. 加重＋ヘルスチェックの組み合わせ

カナリアリリース中に新バージョンで障害が発生した場合、ヘルスチェックと加重ルーティングを組み合わせておくと、新バージョンのヘルスチェックが失敗した瞬間に加重が0として扱われ、自動的に旧バージョンへフォールバックする。カナリアリリースの安全弁として有効な設計だ。

ヘルスチェック設計のポイント

ヘルスチェックはルーティングポリシーと切り離して単独で設計することが大切だ。

・文字列マッチング: レスポンスボディに特定文字列（例: “ok”）を含むかチェックできる。ステータスコード200でも依存サービスが落ちている場合を検知できる
・計算式ヘルスチェック: 複数のヘルスチェック結果をAND/ORで評価できる。DBと外部APIの両方が正常なときだけhealthyとみなす、といった複合条件を表現できる
・CloudWatchアラームとの連動: CloudWatchアラームの状態をヘルスチェックのステータスに反映できる。アプリレベルのメトリクス（エラーレート・レイテンシー）が閾値を超えたらルーティングを切り替える設計が可能だ
・プライベートエンドポイントの注意: Route 53のヘルスチェッカーはインターネットからアクセスするため、プライベートサブネット上のリソースを直接チェックできない。CloudWatchメトリクスを経由したヘルスチェック連動が必要だ

料金体系と試算

Route 53の料金体系は「ホストゾーン料金＋クエリ料金＋ヘルスチェック料金」の3軸だ（以下は2026年時点の料金、最新はAWSコンソールで確認すること）。

ルーティングポリシーを使ったクエリはシンプルルーティングより単価が高い点に注意が必要だ。想定例として月間1億クエリの場合、ポリシー有りとポリシー無しで月額$20の差が生じる計算になる。規模が大きくなるとクエリ料金の積み上がりも無視できない。

ポリシー選択の判断マトリクス

どのポリシーを使うか迷ったときの判断基準を整理する。

よくあるつまずきと対処法

設計・運用でよくぶつかる問題を整理する。

・TTLが長すぎてフェールオーバーが遅い: DNS TTLは「キャッシュ保持時間」であり、Route 53側でヘルスチェックが切り替わっても既存のキャッシュが残る。TTLを60秒以下に設定するのが原則だ。ただしTTLを下げるとクエリ数が増え料金も上がる点はトレードオフとして認識しておく
・ジオロケーションでデフォルトレコードを忘れる: 定義外の地域からのアクセスに対してデフォルトレコードを用意しないとNXDOMAIN（ドメイン未存在）扱いになる。デフォルトは必ず設定する
・加重ルーティングで合計を100にしようとする: 加重の値は比率なので合計が100である必要はない。10と90でも1と9でも9:1の比率になる。0にするとそのレコードへはルーティングされない（削除なしで一時的に除外できる）
・プライベートリソースのヘルスチェックが通らない: Route 53ヘルスチェッカーはパブリックIPから接続する。VPC内のプライベートリソースはCloudWatchメトリクスを経由したヘルスチェック方式（計算式ヘルスチェック）を使う
・フェールオーバーとActive-Activeを混同する: フェールオーバーポリシーはActive-Passive構成専用で、両系が同時に稼働するActive-Active構成には向かない。Active-Activeにはレイテンシーベースまたは加重ルーティングを選ぶ

本記事のまとめ

Amazon Route 53のルーティングポリシーは、DNSレイヤーでトラフィック制御を行う強力な仕組みだ。主要なポイントを振り返る。

・フェールオーバー: DR・Active-Passive構成の自動切り替えに使う。ヘルスチェックとTTL設計が鍵
・レイテンシーベース: グローバルサービスで最寄りリージョンへ誘導する。Global Acceleratorとのトレードオフをユースケースとコストで判断
・加重: カナリアリリース・段階的切り替えに使う。ヘルスチェックとの組み合わせで自動ロールバックも実現できる
・ジオロケーション: 法規制・地域別コンテンツに使う。デフォルトレコードは必須
・階層化設計: レイテンシー＋フェールオーバーを組み合わせるとグローバル高可用性を実現できる
・料金: ポリシー有りクエリはシンプルより高い。Traffic Flowは月額$50/レコードのコストを伴う

Route 53のルーティングポリシーを正しく設計することで、手動のDNS書き換えや監視ツールへの依存を減らし、インフラの自律的な回復力を高められる。まずはステージング環境でフェールオーバーポリシーを試し、実際のDNS切り替えの挙動を体感してみることをすすめる。