Amazon Route 53徹底解説：Google Cloud DNS・Azure DNS / Traffic Manager比較で学ぶ“DNSとトラフィック制御”設計

はじめに

Amazon Route 53 は、AWS の権威 DNS サービスを中心に、ドメイン登録、ヘルスチェック、DNS フェイルオーバー、各種ルーティングポリシーまで扱えるサービスです。AWS 公式ドキュメントでは、Route 53 が DNS サービスに加えてヘルスチェックや VPC Resolver などの機能を持つこと、またルーティングポリシーでユーザー位置・リソース位置・レイテンシ・IP・ヘルスチェックに基づく振り分けができることが説明されています。

GCP で近い中核サービスは Cloud DNS、Azure では Azure DNS が相当します。ただし、Route 53 の「DNS フェイルオーバー」「レイテンシ/パフォーマンスベースの振り分け」に近い機能は、Azure では Azure DNS 単体ではなく Azure Traffic Manager と組み合わせて考えるのが自然です。Cloud DNS はゾーンとクエリ単位のシンプルな課金体系で、Azure DNS もゾーンとクエリ課金が中心、Traffic Manager は DNS クエリとヘルスチェック課金が中心です。

この記事では、Route 53 を「ただ名前解決するだけのサービス」ではなく、公開 DNS、内部 DNS、可用性設計、マルチリージョン切り替え、コスト最適化まで含めた設計対象として整理します。

1. Route 53 とは何か

Route 53 は、AWS のフルマネージドな DNS サービスです。名前解決の基盤として使うだけでなく、ドメイン登録、パブリックホストゾーン、プライベートホストゾーン、ヘルスチェック、各種ルーティングポリシーをまとめて扱えます。公式ガイドでも、Route 53 が DNS サービスに加えて、ヘルスチェックや DNS フェイルオーバー、VPC Resolver を提供することが示されています。

一言でいうと、Route 53 は次の3つをまとめて面倒見られるのが強みです。

インターネット向けの DNS
VPC 内部向けの DNS
可用性や地理・レイテンシを考慮したトラフィック制御

特に AWS 上で複数リージョン、複数 AZ、複数エンドポイントを使い始めると、単なる DNS 管理ではなく「どこに流すか」の設計が重要になります。そこで Route 53 の価値が一気に上がります。

2. GCP・Azure の同等サービスとの対応関係

GCP: Cloud DNS

Cloud DNS は、Google Cloud のマネージド DNS サービスです。課金は主にゾーン数とクエリ数で、無料枠はないと公式料金ページに明記されています。Route 53 の権威 DNS 部分にかなり近い立ち位置ですが、Route 53 のようなヘルスチェック連動フェイルオーバーや多彩なルーティングポリシーは、そのまま 1 サービスで重なるわけではありません。

Azure: Azure DNS + Traffic Manager

Azure DNS は権威 DNS のホスティングを担うサービスです。一方、Traffic Manager は DNS ベースのトラフィック分散サービスで、パフォーマンス、フェールオーバー、ラウンドロビンなどのルーティングとヘルスチェックを提供します。つまり Azure では、Route 53 が 1 サービス内で持つ機能の一部が、Azure DNS と Traffic Manager に分かれている、と捉えると分かりやすいです。

この違いは設計に効きます。
AWS では「DNS と振り分け」を Route 53 に寄せやすいのに対し、Azure では「名前は Azure DNS、振り分けは Traffic Manager」と役割分担を意識しやすいです。GCP は比較的 DNS 自体はシンプルで、より上位の分散は別サービスや構成で補うことが多くなります。

3. Route 53 の基本構成

ホストゾーン

Route 53 の中心概念はホストゾーンです。

パブリックホストゾーン はインターネット公開用
プライベートホストゾーン は VPC 内部名前解決用

この切り分けが、運用設計の最初の分岐になります。インターネットから見える名前と、社内・VPC 内だけで解決したい名前を混ぜないほうが、権限も事故リスクも整理しやすいです。Route 53 のルーティングポリシーは、プライベートホストゾーンでも使えるものがあります。

レコード

DNS レコード自体は一般的な A/AAAA/CNAME などの概念ですが、Route 53 ではレコード作成時に「どのルーティングポリシーを使うか」を選ぶのが大きな特徴です。ここが、単なる DNS サービスと Route 53 の違いを最も感じるところです。

ヘルスチェック

Route 53 のヘルスチェックは、指定したエンドポイント、他のヘルスチェック、または CloudWatch アラームの状態を監視できます。ヘルスチェック結果を DNS フェイルオーバーに組み込めるため、「死んでいる先を返さない」設計がしやすくなります。

4. ルーティングポリシーが Route 53 の本体

Route 53 の価値は、実は DNS レコードを持てることよりも、どう返答するかを制御できることにあります。公式ドキュメントでは、レコード作成時にルーティングポリシーを選び、応答方法を決めると説明されています。主なポリシーには、シンプル、フェイルオーバー、位置情報、レイテンシベースなどがあります。

4.1 シンプルルーティング

単一リソース、または基本的な名前解決向けです。最初の環境ではこれで十分なことも多いですが、可用性や地理分散を考え始めると、すぐ限界が来ます。

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

アクティブ/パッシブ構成向けです。プライマリが死んだらセカンダリへ切り替える、という最も分かりやすい高可用設計を DNS レベルで実現できます。ヘルスチェックと組み合わせることで、エンドポイント障害時の自動切替が可能です。

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

ユーザーにとって最も低レイテンシなリージョンへ返す設計です。マルチリージョン構成で、地域ごとに近い拠点へ誘導したいときに使います。グローバルサービスで特に有効です。

4.4 位置情報ルーティング

ユーザーの地理的位置に基づいて応答先を変える方式です。法規制、地域別コンテンツ、海外向け切替などで使いやすいです。

4.5 加重ルーティング

本番切替や A/B テスト、段階リリースに向いています。たとえば 90% を旧環境、10% を新環境へ流す、といった使い方がしやすいです。

実務では、これらを全部覚えるより、

単純な名前解決
切り替え
地理/レイテンシ
段階リリース
の4分類で考えると、かなり整理しやすいです。

5. ヘルスチェックと DNS フェイルオーバー

Route 53 のヘルスチェックは、DNS を「静的な名前解決」から「状態に応じた交通整理」へ変える機能です。AWS 公式では、ヘルスチェックが Web サーバーなどのリソース、他のヘルスチェック、CloudWatch アラームの状態を監視できること、そして DNS フェイルオーバーに使えることが説明されています。

これが役立つ典型例は次の通りです。

東京リージョンのフロントが死んだら大阪へ切り替える
プライマリの API が落ちたら DR 側へ逃がす
アプリケーションのメトリクス異常を CloudWatch アラームで拾い、その状態を DNS に反映する

DNS レイヤーなので、L7 ロードバランサーほどきめ細かい制御ではありませんが、そのぶんシンプルで、リージョンをまたいだ大きな切り替えには相性が良いです。

6. 料金の考え方

Route 53 の料金は、主に

ホストゾーン
DNS クエリ
ヘルスチェック
ドメイン登録
に分かれます。公式料金ページでは、ヘルスチェックが月額課金で、AWS エンドポイント向け基本ヘルスチェックに無料枠があることも示されています。

GCP Cloud DNS はゾーンごと月額＋クエリ課金、無料枠なしです。Azure DNS もゾーンとクエリ単位です。Traffic Manager は DNS クエリとエンドポイントごとのヘルスチェック課金が中心です。

この違いから、ざっくり次のように考えると見積もりがしやすいです。

Route 53 / Cloud DNS / Azure DNS
- 「名前を持つ数」と「引かれる回数」で増える
Route 53 のヘルスチェック / Azure Traffic Manager
- 「監視対象の数」と「高頻度監視の有無」で増える

つまり、単純な DNS ホスティングだけなら比較的読みやすいですが、可用性設計まで DNS に持ち込むと、ヘルスチェック系のコストが追加されます。そこを「高可用性の保険」として納得できるかが判断ポイントです。

7. 実務での設計パターン

7.1 シンプルな Web サイト

パブリックホストゾーン
www.example.com を CDN や LB に向ける
まずはシンプルルーティング

小規模ならこれで十分です。最初から複雑にしすぎないことが大切です。

7.2 マルチリージョン API

api.example.com にレイテンシベース、またはフェイルオーバー
各リージョンの API へ振り分け
ヘルスチェックで障害時切替

グローバル API や DR 要件がある場合に向いています。DNS 切替なので、完全リアルタイムではない点を理解して使うのがコツです。

7.3 社内向け内部 DNS

プライベートホストゾーン
db.internal.example.local のような内部名
VPC ごとに解決

アプリ設定を IP 直書きにしないだけで、構成変更や DR 時の柔軟性がかなり上がります。Route 53 はこの“内部 DNS 基盤”としても強いです。

7.4 段階リリース

加重ルーティングで旧/新環境を併存
新環境を 5% → 20% → 50% → 100% と増やす

アプリ層の AB テストというより、インフラ切替や大規模移行に相性が良いです。

8. GCP・Azure との比較まとめ

AWS Route 53

Route 53 は、権威 DNS、ヘルスチェック、フェイルオーバー、各種ルーティングポリシーを 1 サービスでまとめやすいのが特徴です。AWS ネイティブなマルチリージョン設計と相性が良いです。

GCP Cloud DNS

Cloud DNS は権威 DNS サービスとしてはシンプルで分かりやすいです。料金もゾーン＋クエリで読みやすいですが、Route 53 のような多彩な DNS フェイルオーバー/ルーティング機能を 1 サービスで完結させる方向ではありません。

Azure DNS + Traffic Manager

Azure は DNS とトラフィック分散が分かれています。

Azure DNS: 権威 DNS
Traffic Manager: DNS ベース分散、ヘルスチェック、フェイルオーバー

この分割は一見複雑ですが、逆に役割を明確にしやすいとも言えます。

9. よくある落とし穴

9.1 DNS とロードバランサーの役割を混同する

Route 53 は DNS レベルの制御です。リクエストごとの細かい振り分けやアプリケーションヘッダーに応じた制御は別レイヤーの仕事です。ここを混同すると設計がややこしくなります。

9.2 最初からルーティングポリシーを盛りすぎる

全部入りにすると、運用者しか分からない DNS になります。
まずはシンプル、次にフェイルオーバー、必要ならレイテンシや位置情報へ進む順番が安全です。

9.3 ヘルスチェックの意味を曖昧にする

ヘルスチェックが「何をもって正常とするか」を決めないまま入れると、誤検知や切り替わりすぎが起きます。
単なる 200 応答でよいのか、アプリ疎通まで見るのか、CloudWatch アラーム連携にするのか、を先に決めると安定します。

10. まとめ

Amazon Route 53 は、DNS を管理するサービスであると同時に、可用性とグローバル配信の“入口設計”を支えるサービスです。公式ドキュメントでも、ルーティングポリシー、ヘルスチェック、VPC Resolver など、単なる DNS を超えた機能が明確に整理されています。

GCP の Cloud DNS はシンプルで素直な権威 DNS、Azure は Azure DNS と Traffic Manager の組み合わせで Route 53 に近い世界を作る、という理解を持つと、マルチクラウドでも設計がぶれにくくなります。

最初の一歩としておすすめなのは、

外部向け DNS を Route 53 に寄せる
重要エンドポイントにヘルスチェックを付ける
フェイルオーバーを 1 つだけ試す
この3つです。

DNS は地味ですが、ここを丁寧に設計すると、障害対応、マルチリージョン、移行、段階リリースのすべてが少し楽になります。