Route 53は「なんとなくシンプルルーティング」で組んでも動いてしまうため、いざDRやマルチリージョンで詰まる。ルーティングポリシーの選定軸、ヘルスチェックの挙動、TTL設計、ハイブリッドDNSまで、設計時に効いてくる判断を整理する。
01Route 53が「ただのDNS」ではない理由
Route 53は権威DNSサービスであると同時に、ヘルスチェックとルーティングポリシーを組み合わせてトラフィック制御を行う仕組みです。単にAレコードを引くだけなら他のDNSでも足りますが、実務でRoute 53を選ぶ価値は「リージョン障害時にDNSレベルで切り替える」「レイテンシで最寄りリージョンへ寄せる」といった、レコード応答をアプリケーションの状態と連動させられる点にあります。
逆に言えば、この連動を設計せずにシンプルルーティングだけで組むと、DRシナリオでDNSが古いエンドポイントを返し続けるといった事故につながります。本記事では、7つのルーティングポリシーの選定軸から、ヘルスチェックの内部挙動、TTL設計、プライベートホストゾーンとハイブリッドDNSまでを、設計時に迷うポイントに絞って解説します。
なお、マルチリージョンDR全体のRPO/RTO設計は本記事の範囲を超えるため、マルチリージョンDRのRPO/RTO設計と併せて読むと、DNS層とデータ層の切り替え粒度の違いが整理できます。
02ルーティングポリシーを判断軸で選ぶ
Route 53には現在、シンプル・加重・レイテンシ・位置情報(Geolocation)・フェイルオーバー・複数値回答(Multivalue)・IPベース・地理的近接(Geoproximity)の各ポリシーがあります。名前だけ見ると用途が被って見えますが、「何を根拠に返すレコードを選ぶか」という軸で切ると迷いません。
- シンプル — 1つの機能に対して1レコード。ヘルスチェックによる出し分けは不可。まず疑うべきデフォルト。
- 加重(Weighted) — 重み比率でトラフィックを分配。Blue/Greenやカナリアリリース、A/Bで使う。重み0で一時的に切り離せる。
- レイテンシ(Latency) — クライアントから見て最も低レイテンシのAWSリージョンへ。マルチリージョンの読み取り系で定番。
- 位置情報(Geolocation) — ユーザーの地理的位置(大陸/国/都道府県)で出し分け。コンプライアンスやローカライズ用途。
- フェイルオーバー(Failover) — アクティブ/パッシブ。プライマリが不健全なときだけセカンダリを返す。DRの主役。
- 複数値回答(Multivalue) — 健全なレコードを最大8件までランダムに返す。ヘルスチェック付きの簡易的な負荷分散。ELBの代替ではない点に注意。
- IPベース/地理的近接 — 送信元IPブロックや、リソース側の位置とバイアス設定で寄せる。CDNやキャリア別最適化などの高度な用途。
ポリシーの正式な一覧と定義はAWS公式のルーティングポリシー選択ガイドが一次情報です。ポリシー数や仕様は更新されるため、最新は公式で確認してください。
03ヘルスチェックの内部挙動を正しく理解する
DNSフェイルオーバーの信頼性は、ヘルスチェックの挙動をどこまで正確に把握しているかで決まります。Route 53のヘルスチェックには3種類あります。
- エンドポイント監視 — HTTP/HTTPS/TCPで指定エンドポイントを直接叩く。EC2やオンプレサーバーなどエイリアスを張れない対象に使う。
- 計算(Calculated)ヘルスチェック — 子ヘルスチェックの健全数を集計。1つの親で最大255の子を監視でき、「N個中M個が健全なら健全」といった論理を組める。
- CloudWatchアラーム連動 — アラームのデータストリームを監視。VPC内部リソースやカスタムメトリクスをトリガにできる。ただしクロスアカウントのアラームは非対応で、
SetAlarmStateで強制的に状態を変えることはできません。
特に押さえるべきは判定ロジックです。公式ドキュメントによると、世界中に分散したヘルスチェッカーのうち18%を超えるチェッカーが健全と報告すれば健全、18%以下なら不健全と判定されます。これは特定リージョンからのネットワーク分断だけで不健全と誤判定しないための閾値です(この値は将来変わる可能性があるとされています)。
チェック間隔は10秒または30秒、応答判定はHTTP/HTTPSで「4秒以内にTCP接続かつ2秒以内に2xx/3xx応答」、TCPで「10秒以内に接続確立」です。文字列マッチング型は応答ボディの先頭5,120バイト以内に指定文字列が全て現れる必要があります。数値は更新されうるため、設計時は公式で最新値を確認してください。
04DNSフェイルオーバーでDRを組む
DRの中核はフェイルオーバールーティングです。公式のとおり、プライマリレコードが健全なときはプライマリを、不健全になったらセカンダリを返します。プライマリ/セカンダリは、S3静的サイトから複数レコードの複雑なツリーまで指せます。
フェイルオーバーには2つのパターンがあります。
- アクティブ/パッシブ — フェイルオーバーポリシーで構成。通常はプライマリのみ返し、障害時にセカンダリへ。パイロットライトやウォームスタンバイのDRに合う。
- アクティブ/アクティブ — フェイルオーバー以外のポリシー(加重・レイテンシ・複数値など)にヘルスチェックを付けて構成。全リソースを稼働させ、不健全なものだけ応答から外す。
フェイルオーバーはプライベートホストゾーン内のレコードでも利用できます。設定手順の全体像はDNSフェイルオーバーの構成ガイドが一次情報です。
05TTLは「切替速度」と「クエリ料金」のトレードオフ
DNSフェイルオーバーで見落とされがちなのがTTLです。ヘルスチェックが不健全を検知しても、リゾルバやクライアントがキャッシュしている間は古いレコードが返り続けます。つまり実際の切替時間は「ヘルスチェック検知時間 ＋ TTLによるキャッシュ滞留時間」で決まります。
- 短いTTL(例:60秒) — 切替は速いが、キャッシュ効きが弱くなりクエリ数が増える。フェイルオーバー対象のレコードは短めが定石。
- 長いTTL(例:数時間〜1日) — クエリ料金を抑えられるが、障害時の切替に時間がかかる。安定した固定エンドポイント向け。
- Aliasレコード — ALB/CloudFront/S3などAWSリソースを指すAliasは、TTLをAWS側が管理し、かつAliasクエリ自体は無料。エンドポイントがAWS内なら基本Aliasを選ぶ。
06プライベートホストゾーンとVPC内名前解決
社内向けやVPC内部の名前解決にはプライベートホストゾーン(PHZ)を使います。PHZは1つ以上のVPCに関連付けることで、そのVPC内からのみ解決される内部ドメインを提供します。パブリックゾーンと同じexample.internalのような名前空間を、外部に公開せず運用できます。
設計上の注意点を挙げます。
- VPCの
enableDnsHostnamesとenableDnsSupportを有効にしないとPHZは機能しない。 - 同名のパブリックゾーンとPHZが両方ある(スプリットビューDNS)場合、VPC内からはPHZが優先される。意図しない名前解決の逆転に注意。
- 複数VPC・複数アカウントで共有する場合、関連付けの管理が煩雑になる。アカウント跨ぎの統制はマルチアカウント統制の観点で設計する。
フェイルオーバーやヘルスチェックはPHZ内のレコードにも適用できるため、内部APIやオンプレ連携基盤のDRにもDNSフェイルオーバーが使えます。
07ハイブリッドDNS — オンプレとVPCの相互解決
オンプレミスとAWSを併用する環境では、双方向の名前解決が必要になります。ここでRoute 53 Resolverのインバウンド/アウトバウンドエンドポイントが効いてきます。
- インバウンドエンドポイント — オンプレDNSサーバーからVPC内(PHZやEC2)の名前を解決させる入口。オンプレ側の条件付きフォワーダから、このエンドポイントのIPへ転送する。
- アウトバウンドエンドポイント — VPC内リソースからオンプレのドメインを解決させる出口。転送ルール(Resolver Rule)で「この社内ドメインはオンプレDNSへ」と条件付き転送する。
AWSのハイブリッドクラウドDNSホワイトペーパーでは、可用性のためエンドポイントは異なるAZの最低2サブネットで構成することを推奨しています。また高QPS環境では1 ENIあたり1万クエリ/秒の上限があり、ENIを増やしてスケールする設計が必要です(上限値は更新されうるため公式で確認)。
08設計判断まとめ(決定表)
ここまでの選定軸を、よくある要件から逆引きできる形にまとめます。
- 単一エンドポイントで冗長不要 → シンプル(AWS内リソースならAlias)。
- リージョン障害時にDR切替 → フェイルオーバー＋エンドポイント/CloudWatchヘルスチェック、TTLはRTOから逆算して短め。
- マルチリージョンで最寄りへ寄せたい → レイテンシ＋ヘルスチェック(アクティブ/アクティブ)。
- 段階リリース・カナリア → 加重。重みで比率を調整、0で切り離し。
- 国・地域でコンテンツやコンプラ要件が異なる → 位置情報またはIPベース。
- VPC内部・社内向け名前空間 → プライベートホストゾーン。
- オンプレとVPCの相互解決 → Route 53 Resolver(インバウンド/アウトバウンド)。
いずれのケースも、ヘルスチェックとTTLをセットで設計しないと「切り替わらない」「切り替わるのが遅い」という典型的な落とし穴に落ちます。DNSは変更が世界中のキャッシュに滞留する層なので、テスト環境で実際にプライマリを落とし、切替までの実測時間をSLAと突き合わせる検証を必ず行ってください。
—まとめ
Route 53の設計は「ルーティングポリシーの選定」「ヘルスチェックの挙動理解」「TTLによる切替速度の逆算」「PHZとハイブリッドDNSの内部名前解決」の4層で考えると整理できます。特にDNSフェイルオーバーによるDRでは、ヘルスチェックの18%閾値・チェック間隔とTTLのキャッシュ滞留を合算した実切替時間を、SLA(RTO)から逆算して設計することが要になります。数値・料金・上限はバージョンや時期で変わるため、実装時は必ず公式ドキュメントで最新値を確認してください。EMWでは大手SIer・エンタープライズのDR/ハイブリッド構成でRoute 53を軸にした設計を数多く支援しています。具体的な構成のご相談はお問い合わせください。導入の進め方は導入事例も参考になります。