--- title: "Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15471/" published: 2026-07-22 updated: 2026-10-04 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説 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公式の料金ページ](https://aws.amazon.com/route53/pricing/)／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を立てる手間は消えました。スタブリゾルバから権威サーバーまでの経路は、[名前解決とは？の解説](https://www.issoh.co.jp/tech/details/13556/)を先に通しておくと、Route 53が担う範囲がはっきりします。 ### Route 53が担う3つの機能（ドメイン登録・DNSルーティング・ヘルスチェック） Route 53の機能は3つに分かれ、必要なものだけを組み合わせて使えます。第一はドメイン登録で、Route 53から直接ドメインを取得・管理できます。第二のDNSルーティングは、登録したドメインへの問い合わせをどのリソースに向けるかを決める部分です。第三のヘルスチェックが監視するのは向き先の生死で、障害時に別リソースへ切り替える判断材料になります。 3つは独立して契約できます。ドメインは他社レジストラで取得したまま、Route 53にDNSルーティングだけ担わせる運用も一般的です。反対に、ネームサーバーの固定と引き換えに卸値で登録できるCloudflare側のレジストラは、[Cloudflare Registrarの移管手順と料金](https://www.issoh.co.jp/tech/details/17851/)で比較できます。実装では「ネームサーバーだけRoute 53に向ける」構成から始めると移行リスクが小さくなります。なお「53」はIANAがDNSに割り当てた[サービス名・ポート番号レジストリ](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)上の番号です。 ### ホストゾーンとレコードセットが構成するDNS設定の基本的な構造 Route 53の設定単位はホストゾーンです。「1つのドメイン（とそのサブドメイン）のレコードをまとめる入れ物」で、example.comごとに1つ作ります。インターネットに公開するパブリックホストゾーンと、VPC内部だけで名前解決するプライベートホストゾーンの2種類があります。 ホストゾーンの中に個々のレコード（レコードセット）を並べます。レコードは「名前・タイプ・値・ルーティングポリシー」の組で、www.example.comをどのIPやAWSリソースへ向けるかを1件ずつ定義します。プライベートホストゾーンなら、社内システムのサーバー名解決をVPC内で完結できました。オンプレミスとの条件付きフォワードまで踏み込む構成は、[プライベートDNSとは？の解説](https://www.issoh.co.jp/tech/details/14678/)にパターンをまとめてあります。 ### 対応するDNSレコードタイプとAliasレコードが持つ独自仕様 Route 53はA、AAAA、CNAME、MX、TXT、NS、SOA、SRV、PTR、CAA、NAPTRなど標準的なDNSレコードタイプを網羅します（[対応レコードタイプの公式一覧](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)）。加えて、Route 53だけの拡張として`Alias`レコードを持ちます。Aliasは、CloudFrontディストリビューションやELB、S3の静的サイト、API Gatewayといった**AWSリソースをドメインの頂点（example.com）に直接マッピング**できる仕組みです。 通常のDNSではドメイン頂点にCNAMEを置けませんが、AliasはこのZone Apex制約を回避します。しかもAWSリソースへのAliasクエリは課金対象外です。実装上の差はTTLの扱いにも出ます。[AWS公式のAlias／非Alias比較](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)によれば、AliasがAWSリソースを指す場合はTTLを指定できず、リソース側の既定TTLが使われます。同一ホストゾーン内の別レコードを指すなら、指し先レコードのTTLが採用される仕様です。Aliasの主な向き先は[Amazon CloudFrontとは？の解説](https://www.issoh.co.jp/tech/details/15431/)と[Amazon S3とは？の解説](https://www.issoh.co.jp/tech/details/15433/)で、前段DNSとしての置き方を確認できます。 ## Amazon Route 53で使える8種類のルーティングポリシーの使い分け Route 53の中核はルーティングポリシーです。同じドメイン名でも、割り当てるポリシーによって「誰に・どのリソースを返すか」が変わります。[ポリシー選択の公式ガイド](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)に沿って、用途の近いものから順に整理します。 ### 基本となる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層での振り分けとロードバランサー層での振り分けは守備範囲が別物なので、両者の役割分担は[ロードバランサーとは？の解説](https://www.issoh.co.jp/tech/details/13137/)と併せて整理してください。 ## AWS CLIでホストゾーンを作成しレコードを登録する実装手順 ここからは実際の作業です。AWS CLIのサービス名前空間はスペースなしの`route53`で、ゾーン操作もレコード操作も同じ名前空間に並びます。コンソールで一件ずつクリックするより、change-batchのJSONを置いて差分管理するほうがレビューと再現が効きます。以下は[create-hosted-zoneのCLIリファレンス](https://docs.aws.amazon.com/cli/latest/reference/route53/create-hosted-zone.html)に沿った最小構成です。 ### 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一覧](https://docs.aws.amazon.com/general/latest/gr/elb.html)／2026年9月時点）。取り違えると`InvalidChangeBatch`で弾かれます。 ``` aws route53 change-resource-record-sets \ --hosted-zone-id Z0123456789ABCDEFGHIJ \ --change-batch file://alias-record.json ``` ### digで応答を確かめてから本番のネームサーバーを切り替える段取り レコードを入れた直後は、まだレジストラ側が旧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フェイルオーバーの公式ガイド](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)のとおり、Route 53は不健全と判定したレコードを応答から外し、健全なセカンダリを返します。 ### create-health-check で監視対象のエンドポイントを用意する まず監視対象を作ります。`Type`はHTTP／HTTPS／TCPなどから選び、HTTPS監視ならアプリの死活を返す軽量なパスを指定してください。設定できる値の範囲は[ヘルスチェック作成時の値の公式説明](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html)にまとまっています。 ``` 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 }' ``` `RequestInterval`30秒・`FailureThreshold`3回なら、異常検知までおよそ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分かかるため、その間のリクエストは失敗します。無停止に近づけたいなら、ロードバランサー層やアプリ層での冗長化を重ねる設計になるでしょう。層ごとの守り方の違いは、[フォールトトレラントとは？の解説](https://www.issoh.co.jp/tech/details/15221/)で高可用性との対比として整理しています。 ## ホストゾーン・クエリ・ヘルスチェックの料金体系とコスト設計の考え方 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の料金ページ](https://aws.amazon.com/route53/pricing/)で最新値を確認してください。ドメイン代のTLD別単価やResolverエンドポイントの月額、自社アカウントの実額を出すコマンドは[Route 53の料金を実額で計算する：ホストゾーン・クエリ・Resolver・ドメイン代の月額](https://www.issoh.co.jp/tech/details/18072/)で詳しく扱っています。 ### AliasレコードでDNSクエリの課金を抑える構成設計の考え方 クエリ料金を抑える定石は、AWSリソースへの向き先をAliasレコードにすることです。CloudFrontやELB、S3静的サイトへAliasで向けたクエリは課金されないため、CDNやELBを前段に置く構成では実質的なクエリコストがゼロに近づきます。EC2インスタンスへIPで直接向ける場合は標準クエリ課金が発生するため、規模が大きいなら[Amazon EC2とは？の解説](https://www.issoh.co.jp/tech/details/15424/)で触れているロードバランサー経由の構成にし、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を含むインフラ構築の受託開発](https://www.issoh.co.jp/service/system/aws/)で、Route 53を組み込んだ可用性設計まで一括で対応できます。 ### 過剰投資になりRoute 53の採用を見送るべきケースの条件 逆に、次の状況ではRoute 53への移行を見送る判断が妥当です。単一の静的サイトを1リージョンで公開するだけなら、レジストラ付属の無料DNSで足ります。すでに他社DNS（CloudflareやGoogle等）でCDNやWAFと統合した運用が安定しているなら、DNSだけ剥がすと管理面が分断され、かえって複雑になるでしょう。基盤がGoogle Cloud側に寄っているなら、[Cloud DNSとは？の解説](https://www.issoh.co.jp/tech/details/15679/)と料金・ルーティング方式を並べたほうが判断は早くなります。移行コスト（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文書](https://aws.amazon.com/route53/sla/)では、ホストゾーンに割り当てられた4本の仮想ネームサーバーがその1分間すべてのDNSクエリに応答しなかったときを「利用不可」と定義しています。ヘルスチェックやドメイン登録は別のSLA体系なので、各条件を確認してください。 ### ヘルスチェックだけを目的にRoute 53を使えますか？ 使えます。ヘルスチェックは単体で作成でき、CloudWatchアラームと連動させた死活監視にも使えるつくりです。ただしフェイルオーバーとして機能させるには、対象レコードにヘルスチェックを紐づける必要があります。 ### コンソールとCLIのどちらでレコードを管理すべきですか？ 本番ドメインならCLIかIaCを勧めます。change-batchのJSONをリポジトリに置けば、変更内容がレビュー対象になり、切り戻しも同じJSONの適用で済みます。コンソール操作は差分が残らないぶん、誰がいつ何を変えたかを追いにくいのが難点です。検証用ゾーンでの試行はコンソール、本番反映はCLI、という使い分けが現実的でしょう。 ## 関連記事 - [名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説](https://www.issoh.co.jp/tech/details/13556/)：DNS全体の経路とdigでの確認手順。 - [プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説](https://www.issoh.co.jp/tech/details/14678/)：VPC内部で名前解決を閉じる構成。 - [Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15431/)：Aliasの主な向き先となるCDN。 - [フォールトトレラントとは？耐障害性の仕組みと高可用性・フェイルオーバーとの違いを実装目線で解説](https://www.issoh.co.jp/tech/details/15221/)：DNS層で届く範囲と届かない範囲。 - [Cloud DNSとは？Google Cloudのマネージド権威DNSの仕組み・料金・ルーティングを実装者向けに解説](https://www.issoh.co.jp/tech/details/15679/)：他社マネージドDNSとの比較。 --- 出典: [Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説]()（株式会社一創）