インフラ

Amazon Route 53とは?DNS・ドメイン登録・ルーティング設計を実装者目線で解説

Amazon Route 53は、AWSが提供するマネージドDNS(ドメインネームシステム)サービスです。ドメイン名の登録、DNSルーティング、ヘルスチェックの3機能を1つのサービスに束ね、可用性100%のSLAを掲げています。名前の由来はDNSが使う標準ポート番号「53」です。この記事では、ホストゾーンとレコードの構造、8種類のルーティングポリシーの使い分け、ホストゾーン・クエリ・ヘルスチェックの料金体系、そしてAWS基盤でRoute 53を採用すべき場面と他社DNSのままにすべき場面までを、実装者の判断軸で整理します。

目次

まとめ:Amazon Route 53の要点と採用判断の結論

Route 53は、AWS上のリソースへトラフィックを振り分けるDNSの制御盤です。ホストゾーンにレコードを登録し、そのレコードに8種類のルーティングポリシーのいずれかを割り当てて挙動を決めます。AWSリソース向けのAliasレコードはクエリ課金が無料になるため、CloudFrontやELBを前段に置く構成では実質コストを抑えられます。

採用判断はシンプルです。AWS上にシステムを集約し、マルチリージョンやアクティブ/パッシブの切り替えを自動化したいなら、Route 53は第一候補になります。逆に、単一の静的サイトを1リージョンで公開するだけ、あるいは既に他社DNSで安定運用しているなら、乗り換えの費用対効果は小さくなります。料金はホストゾーン0.50 USD/月(最初の25個)、標準クエリ100万件あたり0.40 USDが基準です(2026年7月時点)。

Amazon Route 53の全体像とDNSサービスとしての役割

DNSは、人が読むドメイン名(example.com)を、機器が通信に使うIPアドレス(192.0.2.1)へ変換する仕組みです。Route 53はその変換を担うAWSのマネージドサービスで、権威DNSサーバーの運用・冗長化・スケールをAWS側が引き受けます。自前でBINDを立てて冗長構成を組む手間が消え、DNS応答の可用性は100%のSLAで担保されます。

Route 53が担う3つの機能(ドメイン登録・DNSルーティング・ヘルスチェック)

Route 53の機能は3つに分かれ、必要なものだけを組み合わせて使えます。第一はドメイン登録です。Route 53から直接ドメインを取得・管理できます。第二のDNSルーティングは、登録したドメインへの問い合わせをどのリソースに向けるかを制御します。第三のヘルスチェックが監視するのは、向き先の生死です。障害時に別リソースへ切り替える判断材料になります。

3つは独立して契約できます。ドメインは他社レジストラで取得したまま、Route 53はDNSルーティングだけ担わせる運用も一般的です。実装では「ドメインは既存のまま、ネームサーバーだけRoute 53に向ける」構成から始めると移行リスクが小さくなります。

ホストゾーンとレコードセットが構成するDNS設定の基本的な構造

Route 53の設定単位はホストゾーンです。ホストゾーンは「1つのドメイン(とそのサブドメイン)のレコードをまとめる入れ物」で、example.comごとに1つ作ります。インターネットに公開するパブリックホストゾーンと、VPC内部だけで名前解決するプライベートホストゾーンの2種類があります。

ホストゾーンの中に個々のレコード(レコードセット)を並べます。レコードは「名前・タイプ・値・ルーティングポリシー」の組です。www.example.comをどのIPやAWSリソースへ向けるかを1件ずつ定義します。プライベートホストゾーンを使えば、社内システムのサーバー名解決をVPC内で完結させられます。

対応するDNSレコードタイプとAliasレコードが持つ独自仕様

Route 53はA、AAAA、CNAME、MX、TXT、NS、SOA、SRV、PTR、CAA、NAPTRなど標準的なDNSレコードタイプを網羅します。加えて、Route 53だけの拡張としてAliasレコードを持ちます。Aliasは、CloudFrontディストリビューションやELB、S3の静的サイト、API GatewayといったAWSリソースをドメインの頂点(example.com)に直接マッピングできる仕組みです。

通常のDNSではドメイン頂点にCNAMEを置けませんが、AliasはこのZone Apex制約を回避します。しかもAWSリソースへのAliasクエリは課金対象外です。Aliasの主な向き先についてはAmazon CloudFrontとは?の解説Amazon S3とは?の解説で、それぞれの前段DNSとしての置き方を確認できます。

Amazon Route 53で使える8種類のルーティングポリシーの使い分け

Route 53の中核はルーティングポリシーです。同じドメイン名でも、割り当てるポリシーによって「誰に・どのリソースを返すか」が変わります。用途の近いものから順に整理します。

基本となる3種のルーティング(シンプル・加重・フェイルオーバー)

シンプルルーティングは、1つのドメインに1つのリソースを対応させる基本形です。まず1台のサーバーに向けるだけならこれで足ります。加重ルーティングが行うのは、複数リソースへ指定した比率でのトラフィック分配です。新バージョンへ10%だけ流すカナリアリリースや、A/Bテストの振り分けに使います。フェイルオーバールーティングは、プライマリが健全なうちはそちらへ、ヘルスチェックが失敗したらセカンダリ(Sorry ページや別リージョン)へ切り替えます。

地理で振り分ける3種(レイテンシー・位置情報・地理的近接性)

レイテンシールーティングは、複数AWSリージョンにリソースを置き、ユーザーから見て応答遅延の小さいリージョンへ返します。判断の基準は物理距離ではなく、実測の遅延です。位置情報(Geolocation)ルーティングは、ユーザーの国・地域で明示的に振り分け、日本からのアクセスは日本語サイト、といった出し分けやコンテンツ規制対応に向きます。地理的近接性(Geoproximity)ルーティングは、リソースとユーザーの地理的な近さで振り分けつつ、バイアス値で特定拠点へ寄せる調整ができます。

応用となる2種のルーティング(複数値回答とIPベースの制御)

複数値回答(Multivalue Answer)ルーティングは、ヘルスチェックを通った正常なレコードを最大8件までランダムに返します。ロードバランサーを挟まない構成でも、DNSレベルの簡易な負荷分散として冗長化に寄与する点が特徴です。IPベースルーティングは、アクセス元IPアドレスのCIDRブロック単位で向き先を決め、特定ISPや社内ネットワークからの経路を制御します。用途の早見表を以下に示します。

ポリシー 振り分けの基準 代表的な用途
シンプル 単一リソース固定 1台のサーバーへ向けるだけ
加重 指定した比率 カナリアリリース・A/Bテスト
フェイルオーバー ヘルスチェックの健全性 アクティブ/パッシブ冗長
レイテンシー 実測の応答遅延 マルチリージョンの速度改善
位置情報 ユーザーの国・地域 言語出し分け・規制対応
地理的近接性 地理的な近さ+バイアス 拠点へのトラフィック寄せ
複数値回答 正常レコードを最大8件 DNS簡易ロードバランス
IPベース 送信元IPのCIDR ISP・社内経路の制御

実務ではまず、単一構成なら「シンプル」、冗長化するなら「フェイルオーバー」の2つを押さえれば大半のニーズに応えられます。レイテンシーや地理系は、複数リージョンにリソースを持って初めて意味を持ちます。

ホストゾーン・クエリ・ヘルスチェックの料金体系とコスト設計の考え方

Route 53は初期費用ゼロの従量課金です。課金要素は主にホストゾーン・DNSクエリ・ヘルスチェック・ドメイン登録の4つで、それぞれ独立して積み上がります。以下は2026年7月時点のAWS公式料金を基準にした整理です。

ホストゾーン・クエリ・ヘルスチェックにかかる従量課金の料金内訳

課金要素 単価(2026年7月時点) 補足
ホストゾーン 0.50 USD/月(最初の25個) 26個目以降は0.10 USD/月
標準クエリ 100万件あたり0.40 USD 月10億件超は0.20 USD
Aliasクエリ(AWSリソース向け) 0 USD 非AWS向けは標準料金
ヘルスチェック(AWS内) 0.50 USD/月・個 最大50件まで無料枠あり

ドメインを1つ運用する最小構成なら、ホストゾーン0.50 USD/月に少額のクエリ料金が乗る程度で、月1 USD前後に収まるケースが多くなります。コストが膨らむのは、ヘルスチェックの有償オプション(レイテンシー計測や文字列一致など1個あたり追加1〜2 USD/月)を多数のエンドポイントに付けた場合です。監視対象を絞り込むことでコストの膨張を防げます。

AliasレコードでDNSクエリの課金を抑える構成設計の考え方

クエリ料金を抑える定石は、AWSリソースへの向き先をAliasレコードにすることです。CloudFrontやELB、S3静的サイトへAliasで向けたクエリは課金されないため、CDNやロードバランサーを前段に置く構成では、実質的なクエリコストがゼロに近づきます。EC2インスタンスへIPで直接向ける場合は標準クエリ課金が発生するため、規模が大きいならAmazon EC2とは?の解説で触れているロードバランサー経由の構成にし、Route 53からはAliasで受ける設計が費用面で有利です。

Amazon Route 53を採用すべき場面と他社DNSのままにする場面

Route 53は万能ではありません。AWSとの統合が価値の源泉なので、そこがかみ合わないと料金と運用負荷だけが残ります。条件を切り分けて言い切ります。

採用が効くケース(AWS集約・マルチリージョン・高可用性の要件)

次のいずれかに当てはまるなら、Route 53を採用する判断が立ちます。ひとつ、システムの主要リソース(CloudFront・ELB・S3・API Gateway等)がAWS上にあり、Aliasで無料クエリと頂点マッピングの恩恵を受けられる。ふたつ、複数リージョンやアクティブ/パッシブ構成で、ヘルスチェック連動の自動切り替えをDNSレベルで実現したい。みっつ、DNSの可用性100% SLAを運用要件として必要としている。こうした要件は、他社の汎用DNSでは実現が難しいか、追加の作り込みが要ります。AWS基盤全体の設計・構築から任せたい場合は、AWSを含むインフラ構築の受託開発で、Route 53を組み込んだ可用性設計まで一括で対応できます。

過剰投資になりRoute 53の採用を見送るべきケースの条件

逆に、次の状況ではRoute 53への移行を見送る判断が妥当です。単一の静的サイトを1リージョンで公開するだけで、フェイルオーバーもマルチリージョンも不要な場合、ドメインレジストラ付属の無料DNSで十分に足ります。また、すでに他社DNS(CloudflareやGoogleのDNS等)でCDNやWAFと統合した運用が安定しているなら、DNSだけRoute 53へ剥がすと管理面が分断され、かえって運用が複雑になります。移行コスト(TTLを見越した切り替え期間、レコードの棚卸し)に見合う便益がAWS統合から得られるか、を判断の分岐点にしてください。

よくある質問

Amazon Route 53の導入検討でよく挙がる質問に、実装者の観点で簡潔に答えます。

Route 53の「53」という名前の由来は何ですか?

DNSが使う標準ポート番号の「53」に由来します。DNSサービスであることを名前で示したネーミングで、機能とは直接関係しません。ドメイン名解決の問い合わせがUDP/TCPの53番ポートでやり取りされることにちなんでいます。

他社で取得したドメインでもRoute 53は使えますか?

使えます。ドメインは他社レジストラのまま、ネームサーバー(NSレコード)をRoute 53が発行するものに変更すれば、DNSルーティングだけをRoute 53に任せられます。ドメイン登録・DNSルーティング・ヘルスチェックは独立して契約できる仕組みです。必要な機能だけを段階的に移せます。

AliasレコードとCNAMEレコードは何が違いますか?

Aliasはドメインの頂点(example.com)にAWSリソースを直接割り当てられ、そのクエリが無料になるRoute 53独自の拡張です。CNAMEはサブドメイン(www.example.com)にしか設定できず、頂点には使えません。AWSリソースを向き先にするなら、頂点・非頂点を問わずAliasが有利です。

DNSの可用性はどの程度保証されますか?

Route 53のDNSサービスは、AWSが可用性100%のSLAを掲げています。世界中に分散配置された権威DNSサーバーで応答するため、単一障害点になりにくい構成です。ただしヘルスチェックやドメイン登録は別のSLA体系なので、要件がある場合は各サービスの条件を確認してください。

ヘルスチェックだけを目的にRoute 53を使えますか?

使えます。ヘルスチェックは単体で作成でき、CloudWatchアラームと連動させてエンドポイントの死活監視に用いる運用も可能です。ただしフェイルオーバーとして機能させるには、対象ドメインのレコードにヘルスチェックを紐づける必要があります。

関連記事

資料請求

RELATED POSTS 関連記事