Amazon Route 53は、AWSが提供するマネージドDNS（ドメインネームシステム）サービスです。ドメイン名の登録、DNSルーティング、ヘルスチェックの3機能を1つのサービスに束ね、ホストゾーンの月間稼働率100%をサービスコミットメントに掲げています。名前の由来はDNSが使う標準ポート番号「53」で、AWS CLIやAPIでのサービス名前空間はスペースなしのroute53です。この記事では、ホストゾーンとレコードの構造、8種類のルーティングポリシーの使い分け、CLIでゾーンを作ってAliasレコードを登録する手順、フェイルオーバーの検証方法、料金と採用判断までを、実装者が手を動かす順に整理します。
まとめ：Amazon Route 53の要点と採用判断の結論
Route 53は、AWS上のリソースへトラフィックを振り分けるDNSの制御盤です。ホストゾーンにレコードを登録し、そのレコードに8種類のルーティングポリシーのいずれかを割り当てて挙動を決めます。AWSリソース向けのAliasレコードはクエリ課金が無料になるため、CloudFrontやELBを前段に置く構成では実質コストを抑えられます。
採用判断はシンプルです。AWS上にシステムを集約し、マルチリージョンやアクティブ／パッシブの切り替えを自動化したいなら、Route 53は第一候補になります。逆に、単一の静的サイトを1リージョンで公開するだけなら、乗り換えの費用対効果は小さくなります。料金はホストゾーン0.50 USD／月（最初の25個）、標準クエリ100万件あたり0.40 USDが基準です（AWS公式の料金ページ／2026年9月時点）。
手を動かす側の要点は3つです。ゾーン作成とレコード登録はaws route53のサブコマンドとchange-batchのJSONで完結すること、AWSリソースへの向き先はAliasにすること、本番切り替えの前にdigで新ネームサーバーを直接指名して応答を確かめること。以降の章で実際のコマンドとJSONを示します。
Amazon Route 53の全体像とDNSサービスとしての役割
DNSは、人が読むドメイン名（example.com）を、機器が通信に使うIPアドレス（192.0.2.1）へ変換する仕組みです。Route 53はその変換を担うAWSのマネージドサービスで、権威DNSサーバーの運用・冗長化・スケールをAWS側が引き受けます。自前でBINDを立てる手間は消えました。スタブリゾルバから権威サーバーまでの経路は、名前解決とは？の解説を先に通しておくと、Route 53が担う範囲がはっきりします。
Route 53が担う3つの機能（ドメイン登録・DNSルーティング・ヘルスチェック）
Route 53の機能は3つに分かれ、必要なものだけを組み合わせて使えます。第一はドメイン登録で、Route 53から直接ドメインを取得・管理できます。第二のDNSルーティングは、登録したドメインへの問い合わせをどのリソースに向けるかを決める部分です。第三のヘルスチェックが監視するのは向き先の生死で、障害時に別リソースへ切り替える判断材料になります。
3つは独立して契約できます。ドメインは他社レジストラで取得したまま、Route 53にDNSルーティングだけ担わせる運用も一般的です。反対に、ネームサーバーの固定と引き換えに卸値で登録できるCloudflare側のレジストラは、Cloudflare Registrarの移管手順と料金で比較できます。実装では「ネームサーバーだけRoute 53に向ける」構成から始めると移行リスクが小さくなります。なお「53」はIANAがDNSに割り当てたサービス名・ポート番号レジストリ上の番号です。
ホストゾーンとレコードセットが構成するDNS設定の基本的な構造
Route 53の設定単位はホストゾーンです。「1つのドメイン（とそのサブドメイン）のレコードをまとめる入れ物」で、example.comごとに1つ作ります。インターネットに公開するパブリックホストゾーンと、VPC内部だけで名前解決するプライベートホストゾーンの2種類があります。
ホストゾーンの中に個々のレコード（レコードセット）を並べます。レコードは「名前・タイプ・値・ルーティングポリシー」の組で、www.example.comをどのIPやAWSリソースへ向けるかを1件ずつ定義します。プライベートホストゾーンなら、社内システムのサーバー名解決をVPC内で完結できました。オンプレミスとの条件付きフォワードまで踏み込む構成は、プライベートDNSとは？の解説にパターンをまとめてあります。
対応する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クエリは課金対象外です。実装上の差はTTLの扱いにも出ます。AWS公式のAlias／非Alias比較によれば、AliasがAWSリソースを指す場合はTTLを指定できず、リソース側の既定TTLが使われます。同一ホストゾーン内の別レコードを指すなら、指し先レコードのTTLが採用される仕様です。Aliasの主な向き先はAmazon CloudFrontとは？の解説とAmazon S3とは？の解説で、前段DNSとしての置き方を確認できます。
Amazon Route 53で使える8種類のルーティングポリシーの使い分け
Route 53の中核はルーティングポリシーです。同じドメイン名でも、割り当てるポリシーによって「誰に・どのリソースを返すか」が変わります。ポリシー選択の公式ガイドに沿って、用途の近いものから順に整理します。
基本となる3種のルーティング（シンプル・加重・フェイルオーバー）
シンプルルーティングは、1つのドメインに1つのリソースを対応させる基本形です。1台のサーバーに向けるだけならこれで足ります。加重ルーティングが行うのは、複数リソースへ指定した比率でのトラフィック分配で、カナリアリリースや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つで大半のニーズに応えられます。レイテンシーや地理系は、複数リージョンにリソースを持って初めて意味を持ちます。DNS層での振り分けとロードバランサー層での振り分けは守備範囲が別物なので、両者の役割分担はロードバランサーとは？の解説と併せて整理してください。
AWS CLIでホストゾーンを作成しレコードを登録する実装手順
ここからは実際の作業です。AWS CLIのサービス名前空間はスペースなしのroute53で、ゾーン操作もレコード操作も同じ名前空間に並びます。コンソールで一件ずつクリックするより、change-batchのJSONを置いて差分管理するほうがレビューと再現が効きます。以下はcreate-hosted-zoneのCLIリファレンスに沿った最小構成です。
aws route53 create-hosted-zone でゾーンを作る手順
パブリックホストゾーンを1つ作り、AWSが払い出した4つのネームサーバーを控えるまでが最初の作業です。caller-referenceは重複実行を防ぐ冪等キーなので、日付や実行IDなど毎回変わる文字列を入れます。
aws route53 create-hosted-zone \
--name example.com \
--caller-reference cli-2026-09-07-01 \
--hosted-zone-config Comment="public zone for example.com"
# 払い出されたネームサーバー4本を控える
aws route53 get-hosted-zone \
--id Z0123456789ABCDEFGHIJ \
--query "DelegationSet.NameServers" \
--output text控えた4本は、レジストラ側のネームサーバー設定に入れる値です。ホストゾーンは作成時点で課金が始まり日割りもされないため、検証用ゾーンは放置せず削除します。
change-resource-record-sets でAliasレコードを登録する
レコードの追加・更新・削除は、すべてchange-resource-record-setsに渡すJSON（change-batch）で表現します。UPSERTなら、無ければ作成・あれば置換となり冪等に適用できます。次はドメイン頂点をApplication Load Balancerへ向けるAliasの例です。
{
"Comment": "apex to ALB",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z14GRHDCWA56QT",
"DNSName": "dualstack.web-alb-1234567890.ap-northeast-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}
]
}AliasTarget.HostedZoneIdは自分のゾーンIDではなく、向き先リソース側の固定IDです。ap-northeast-1のALB／CLBはZ14GRHDCWA56QT、同リージョンのNLBはZ31USIVHYNEOWTと、リージョンと種別ごとに値が決まっています（ELBのエンドポイントとゾーンID一覧／2026年9月時点）。取り違えるとInvalidChangeBatchで弾かれます。
aws route53 change-resource-record-sets \
--hosted-zone-id Z0123456789ABCDEFGHIJ \
--change-batch file://alias-record.jsondigで応答を確かめてから本番のネームサーバーを切り替える段取り
レコードを入れた直後は、まだレジストラ側が旧DNSを指しています。切り替え前にRoute 53のネームサーバーを直接指名して応答を確認しておくと、切り替え後の事故をほぼ潰せます。
# Route 53 のネームサーバーを直接指名して答えを見る
dig +short example.com A @ns-1234.awsdns-56.org
# 委任が切り替わったかは NS と +trace で確認する
dig +short NS example.com
dig +trace example.com指名クエリで想定どおりのIPが返れば、レコード設定は完了です。あとはレジストラのネームサーバーを4本まとめて差し替え、dig +traceで親ゾーンからの委任がRoute 53へ向いたことを見届けます。旧DNS側のレコードを切り替え後しばらく残しておくと、キャッシュが残った経路からのアクセスを取りこぼしません。
ヘルスチェックとフェイルオーバーを組んで切り替え動作を検証する
可用性の要件があるなら、ヘルスチェックとフェイルオーバールーティングを組み合わせます。DNSフェイルオーバーの公式ガイドのとおり、Route 53は不健全と判定したレコードを応答から外し、健全なセカンダリを返します。
create-health-check で監視対象のエンドポイントを用意する
まず監視対象を作ります。TypeはHTTP／HTTPS／TCPなどから選び、HTTPS監視ならアプリの死活を返す軽量なパスを指定してください。設定できる値の範囲はヘルスチェック作成時の値の公式説明にまとまっています。
aws route53 create-health-check \
--caller-reference hc-primary-2026-09-07 \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "origin-tokyo.example.com",
"ResourcePath": "/healthz",
"Port": 443,
"RequestInterval": 30,
"FailureThreshold": 3
}'RequestInterval30秒・FailureThreshold3回なら、異常検知までおよそ90秒かかる計算です。間隔10秒の高速リクエスト機能で速められますが、こちらは追加料金の対象になります。監視対象を増やすほど費用が積み上がるため、切り替え判断に使うエンドポイントだけに絞ります。
PRIMARYとSECONDARYの2レコードを同じ名前に束ねる書き方
フェイルオーバーは、同じ名前・同じタイプのレコードを2件登録し、SetIdentifierで区別してFailover属性を与えます。プライマリ側にだけヘルスチェックを紐づけるのが基本形です。
{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"TTL": 60,
"SetIdentifier": "tokyo-primary",
"Failover": "PRIMARY",
"HealthCheckId": "abcd1234-5678-90ab-cdef-EXAMPLE11111",
"ResourceRecords": [ { "Value": "192.0.2.10" } ]
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"TTL": 60,
"SetIdentifier": "osaka-secondary",
"Failover": "SECONDARY",
"ResourceRecords": [ { "Value": "198.51.100.10" } ]
}
}
]
}向き先がAliasなら、EvaluateTargetHealthをtrueにすることで、指し先のELBやCloudFront側の健全性をRoute 53が引き継いで判断します。ヘルスチェックIDを別途作らずに済むため、ELB配下のターゲットグループで死活を見ている構成に素直に噛み合います。
TTLと反映待ち時間を踏まえた切り替え検証の進め方と落とし穴
検証で見落としやすいのがTTLです。上の例でTTLを60秒にしたのは、切り替えの反映を1分程度に抑えるため。3600秒のままだと、Route 53が新しい答えを返し始めても、キャッシュを持つリゾルバは最大1時間ほど旧IPを配り続けます。切り替えの数日前にTTLを短くし、収束後に戻すのが定石です。
もう1つの落とし穴は、DNSフェイルオーバーが「切り替えの手段」であって「無停止の保証」ではない点です。検知に数十秒、キャッシュ収束にTTL分かかるため、その間のリクエストは失敗します。無停止に近づけたいなら、ロードバランサー層やアプリ層での冗長化を重ねる設計になるでしょう。層ごとの守り方の違いは、フォールトトレラントとは？の解説で高可用性との対比として整理しています。
ホストゾーン・クエリ・ヘルスチェックの料金体系とコスト設計の考え方
Route 53は初期費用ゼロの従量課金です。課金要素はホストゾーン・DNSクエリ・ヘルスチェック・ドメイン登録の4つで、それぞれ独立して積み上がります。以下は2026年9月時点のAWS公式料金を基準にした整理です。
ホストゾーン・クエリ・ヘルスチェックにかかる従量課金の料金内訳
| 課金要素 | 単価（2026年9月時点） | 補足 |
|---|---|---|
| ホストゾーン | 0.50 USD／月（最初の25個） | 26個目以降は0.10 USD／月 |
| 標準クエリ | 100万件あたり0.40 USD | 月10億件超は0.20 USD |
| レイテンシー系クエリ | 100万件あたり0.60 USD | 地理系は0.70 USD |
| IPベースのクエリ | 100万件あたり0.80 USD | CIDR1000超は別途課金 |
| Aliasクエリ（AWSリソース向け） | 0 USD | 非AWS向けは標準料金 |
| プライベートゾーンのクエリ | 0 USD | 内部名前解決は課金対象外 |
| ヘルスチェック（AWS内） | 0.50 USD／月・個 | 最大50件まで無料枠あり |
ドメインを1つ運用する最小構成なら、ホストゾーン0.50 USD／月に少額のクエリ料金が乗る程度で、月1 USD前後に収まります。コストが膨らむのは、ヘルスチェックの有償オプション（レイテンシー計測や文字列一致など、AWSエンドポイントで1機能あたり1.00 USD／月、非AWSは2.00 USD／月）を多数に付けた場合です。
単価はポリシーでも変わります。地理系を全レコードへ広げると標準の1.75倍が乗り、1ゾーンあたり1万件を超えたレコードには1件0.0015 USD／月の追加課金もかかります。細かい単価はRoute 53の料金ページで最新値を確認してください。ドメイン代のTLD別単価やResolverエンドポイントの月額、自社アカウントの実額を出すコマンドはRoute 53の料金を実額で計算する：ホストゾーン・クエリ・Resolver・ドメイン代の月額で詳しく扱っています。
AliasレコードでDNSクエリの課金を抑える構成設計の考え方
クエリ料金を抑える定石は、AWSリソースへの向き先をAliasレコードにすることです。CloudFrontやELB、S3静的サイトへAliasで向けたクエリは課金されないため、CDNやELBを前段に置く構成では実質的なクエリコストがゼロに近づきます。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レベルで実現したい。みっつ、稼働率100%というSLA水準を運用要件として必要としている。こうした要件は、他社の汎用DNSだと追加の作り込みが要ります。AWS基盤の設計・構築から任せたいなら、AWSを含むインフラ構築の受託開発で、Route 53を組み込んだ可用性設計まで一括で対応できます。
過剰投資になりRoute 53の採用を見送るべきケースの条件
逆に、次の状況ではRoute 53への移行を見送る判断が妥当です。単一の静的サイトを1リージョンで公開するだけなら、レジストラ付属の無料DNSで足ります。すでに他社DNS（CloudflareやGoogle等）でCDNやWAFと統合した運用が安定しているなら、DNSだけ剥がすと管理面が分断され、かえって複雑になるでしょう。基盤がGoogle Cloud側に寄っているなら、Cloud DNSとは？の解説と料金・ルーティング方式を並べたほうが判断は早くなります。移行コスト（TTLを見越した切り替え期間、レコードの棚卸し）に見合う便益がAWS統合から得られるかを分岐点にしてください。
よくある質問
導入検討でよく挙がる質問に、実装者の観点から答えます。
route53とRoute 53は同じもので、「53」は何を指しますか？
同じサービスを指します。製品名の表記はスペース入りの「Amazon Route 53」ですが、AWS CLIやAPI、IAMポリシーのアクション名ではroute53とスペースなしで書きます。「53」はDNSの問い合わせがUDP／TCPで使う標準ポート番号に由来し、機能そのものとは直接関係しません。
他社で取得したドメインでもRoute 53は使えますか？
使えます。ドメインは他社レジストラのまま、ネームサーバー（NSレコード）をRoute 53が発行するものへ変更すれば、DNSルーティングだけを任せられます。3機能は独立して契約できる仕組みで、必要な機能だけを段階的に移す運用が可能です。
AliasレコードとCNAMEレコードは何が違いますか？
Aliasはドメインの頂点（example.com）にAWSリソースを直接割り当てられ、そのクエリが無料になるRoute 53独自の拡張です。CNAMEはサブドメイン（www.example.com）にしか設定できません。TTLの扱いも異なり、AliasがAWSリソースを指す場合はTTLを指定できません。AWSリソースが向き先なら、頂点・非頂点を問わずAliasが有利です。
DNSの可用性はどの程度保証されますか？
AWSはホストゾーンの月間稼働率100%をサービスコミットメントに掲げ、下回った場合はクエリ料金に対するサービスクレジットを返します。SLA文書では、ホストゾーンに割り当てられた4本の仮想ネームサーバーがその1分間すべてのDNSクエリに応答しなかったときを「利用不可」と定義しています。ヘルスチェックやドメイン登録は別のSLA体系なので、各条件を確認してください。
ヘルスチェックだけを目的にRoute 53を使えますか？
使えます。ヘルスチェックは単体で作成でき、CloudWatchアラームと連動させた死活監視にも使えるつくりです。ただしフェイルオーバーとして機能させるには、対象レコードにヘルスチェックを紐づける必要があります。
コンソールとCLIのどちらでレコードを管理すべきですか？
本番ドメインならCLIかIaCを勧めます。change-batchのJSONをリポジトリに置けば、変更内容がレビュー対象になり、切り戻しも同じJSONの適用で済みます。コンソール操作は差分が残らないぶん、誰がいつ何を変えたかを追いにくいのが難点です。検証用ゾーンでの試行はコンソール、本番反映はCLI、という使い分けが現実的でしょう。
関連記事
- 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説：DNS全体の経路とdigでの確認手順。
- プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説：VPC内部で名前解決を閉じる構成。
- Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説：Aliasの主な向き先となるCDN。
- フォールトトレラントとは？耐障害性の仕組みと高可用性・フェイルオーバーとの違いを実装目線で解説：DNS層で届く範囲と届かない範囲。
- Cloud DNSとは？Google Cloudのマネージド権威DNSの仕組み・料金・ルーティングを実装者向けに解説：他社マネージドDNSとの比較。
