AWS Route 53徹底解説！ホストゾーンからサブドメイン設定まで

AWS Route 53の全体像とDNS設定の基本

Route 53とは？信頼性とスケーラビリティの基盤

Amazon Route 53は、AWSが提供する信頼性とスケーラビリティに優れたDNS（ドメインネームシステム）サービスです。ウェブサイトやアプリケーションにアクセスする際、ユーザーが入力したドメイン名（例: example.com）を、サーバーが識別できるIPアドレス（例: 192.0.2.1）に変換する「名前解決」の役割を担っています。

Route 53の魅力は、単なる名前解決に留まりません。ユーザーを最適なリソースへ誘導する「ルーティング機能」や、サーバーやサービスの稼働状況を監視する「ヘルスチェック機能」も提供し、システムの可用性を高めます。これにより、たとえ特定のサーバーに障害が発生しても、自動的に正常なサーバーへトラフィックを振り分け、サービスの中断を最小限に抑えることが可能です。AWSのインフラと密接に連携し、ミッションクリティカルなシステム基盤として、多くの企業で活用されています。

その高い信頼性は、稼働率目標値が100%（2026年6月時点、サンアットマーク出典）とされていることからも伺えます。大規模なトラフィックを処理しながらも安定したサービス提供を実現するため、DNS設定の核となるサービスとして機能します。

ドメインネームシステム（DNS）の基本概念とRoute 53の役割

DNSはインターネットの住所録のようなもので、人間が覚えやすいドメイン名をコンピュータが理解できるIPアドレスに変換するシステムです。この変換プロセスがなければ、私たちはウェブサイトにアクセスするために複雑な数字の羅列（IPアドレス）を直接入力しなければなりません。

Route 53は、このDNSの機能をAWS上で提供し、ドメインの登録から名前解決、高度なルーティングまでを一元的に管理できるサービスです。利用者は「ホストゾーン」と呼ばれるコンテナを作成し、その中にドメインとIPアドレスの対応関係を定義する「レコード」を設定します。ホストゾーンには、インターネット上のドメインを管理する「パブリックホストゾーン」と、AWSのVPC（Virtual Private Cloud）内で閉じたドメインを管理する「プライベートホストゾーン」の2種類があり、用途に応じて使い分けることができます。

Route 53は、世界中に分散配置されたDNSサーバーネットワークを利用することで、ユーザーからのクエリに対して高速な応答を実現し、ウェブサイトやアプリケーションへのアクセスパフォーマンスを向上させます。これにより、複雑なDNSインフラを自前で構築・運用する手間を省き、安定した名前解決環境を容易に手に入れることが可能です。

Route 53が提供するルーティングとヘルスチェック機能

Route 53のルーティング機能は、ユーザーからのリクエストをどのような基準でAWSリソースに転送するかを柔軟に設定できます。例えば、「シンプルルーティング」は単一のリソースに、「加重ルーティング」は複数のリソースに指定した割合でトラフィックを分散させます。また、「レイテンシーベースルーティング」はユーザーに最も近いリージョンのリソースへ、「フェイルオーバールーティング」はプライマリリソースに障害が発生した場合にセカンダリリソースへ自動で切り替えるなど、ビジネス要件に応じた多様な選択肢が用意されています。

さらに、Route 53は「ヘルスチェック機能」を内蔵しており、登録されたエンドポイント（サーバーやサービス）が正常に稼働しているかを定期的に監視します。もし異常を検知した場合、そのエンドポイントへのトラフィックを停止し、健全な別のリソースへ自動的にルーティングを切り替えることで、サービスの継続性を確保します。

このヘルスチェックとルーティングポリシーの組み合わせは、システム全体の高可用性と耐障害性を実現する上で非常に重要です。例えば、ELB（Elastic Load Balancing）は特定のリージョン内での負荷分散を担いますが、Route 53は複数のリージョンや異なるAWSサービスを横断して、システム全体を俯瞰したルーティングや死活監視を行う役割を担い、より広範囲な障害対策を提供します。

出典：Amazon Route 53 の概念（AWS Documentation）、Amazon Route 53 とは？（AWS Documentation）、Amazon Route 53とは？機能やメリット、料金体系を解説（サンアットマーク）

Route 53ホストゾーン作成からレコード設定までの手順

ホストゾーンの作成とドメイン登録の流れ

AWS Route 53でドメインのDNS設定を始める最初のステップは、ホストゾーンの作成です。AWSマネジメントコンソールにログインし、Route 53サービスへ移動します。左側のナビゲーションペインから「ホストゾーン」を選択し、「ホストゾーンを作成」をクリックします。

次に、管理したいドメイン名（例: example.com）を入力し、オプションでコメントを追加します。最も重要なのは、ホストゾーンのタイプとして「パブリックホストゾーン」か「プライベートホストゾーン」を選択することです。インターネットに公開するウェブサイトやアプリケーションの場合はパブリックを、AWSのVPC内部でのみ解決されるドメインの場合はプライベートを選択します。

ホストゾーンが作成されると、Route 53は4つのネームサーバー（NS）レコードとSOAレコードを自動で生成します。これらのネームサーバー情報は、ドメインの登録事業者（レジストラ）の設定に反映させる必要があります。これにより、インターネット上のDNSがあなたのドメインの名前解決をRoute 53に委任するようになります。ドメイン登録自体をRoute 53で行うことも可能ですが、すでに別のレジストラでドメインを登録している場合は、そのレジストラの設定画面でネームサーバーをRoute 53のものに変更してください。

主要レコードタイプ（A、AAAA、CNAME、エイリアス）の設定方法

ホストゾーン作成後は、いよいよ実際の名前解決を行うレコードを設定します。主なレコードタイプには以下のようなものがあります。AWSコンソールでホストゾーンを選択し、「レコードを作成」から設定を進めます。

• Aレコード (Address Record): ドメイン名やサブドメイン名をIPv4アドレスに関連付けます。例えば、example.comをサーバーのIPv4アドレス192.0.2.10に紐付ける際に使用します。
• AAAAレコード (IPv6 Address Record): ドメイン名やサブドメイン名をIPv6アドレスに関連付けます。IPv6対応のサービスに利用します。
• CNAMEレコード (Canonical Name Record): あるドメイン名（例: www.example.com）を別のドメイン名（例: example.com）の別名として定義します。直接IPアドレスを指すことはできません。
• エイリアスレコード (Alias Record): Route 53独自の機能で、CNAMEレコードと似ていますが、ゾーン頂点（例: example.com自身）にも設定可能という大きな違いがあります。ELBやCloudFront、S3バケットといったAWSリソースを直接指す際に非常に便利で、対象リソースのIPアドレス変更をRoute 53が自動追跡するため、運用の手間を削減できます。

レコードを作成する際は、レコード名、タイプ、値、そしてTTL（Time To Live）を設定します。TTLはDNSキャッシュの保持期間を秒単位で指定するもので、短いほど変更が早く反映されますが、DNSサーバーへのクエリ頻度が増加する点に注意が必要です。特にAWSリソースを指す場合は、エイリアスレコードを積極的に活用することで、シンプルかつ安定した設定が実現できます。

ルーティングポリシーの選択と適用方法

Route 53は、単にドメイン名をIPアドレスに変換するだけでなく、様々な「ルーティングポリシー」を適用することで、トラフィックをよりインテリジェントに誘導できます。これにより、ウェブサイトの可用性向上やパフォーマンス最適化を図ることが可能です。レコード作成時に「ルーティングポリシー」の項目で選択します。

• シンプルルーティング: 最も基本的なポリシーで、単一のリソースにすべてのトラフィックをルーティングします。特別な要件がない場合に利用します。
• 加重ルーティング: 複数のリソースに対し、指定した割合でトラフィックを分散させます。A/Bテストや、段階的なデプロイ（カナリアリリース）などに有効です。
• レイテンシーベースルーティング: ユーザーからのリクエストに対し、最も低遅延なAWSリージョンのリソースへトラフィックをルーティングします。グローバルなユーザーを持つサービスでパフォーマンスを向上させます。
• フェイルオーバールーティング: プライマリリソースに障害が発生した場合、ヘルスチェックと連携して自動的にセカンダリリソースへトラフィックを切り替えます。災害対策や高可用性の実現に不可欠です。
• ジオロケーションルーティング: ユーザーの地理的な場所に基づいてトラフィックをルーティングします。特定の国や地域向けに異なるコンテンツを提供する場合などに利用します。

これらのポリシーは、各レコードセットに適用することで機能します。例えば、フェイルオーバールーティングを設定する場合は、プライマリ用のレコードとセカンダリ用のレコードをそれぞれ作成し、ヘルスチェックを設定して連携させることが必要です。ビジネスの要件に応じて最適なルーティングポリシーを選択し、設定することで、ユーザー体験の向上とシステムの安定稼働に貢献します。

出典：Amazon Route 53 の概念（AWS Documentation）、【AWS】用語を整理しながら学ぶAWS – Amazon Route 53（Qiita）、AWS Route 53入門｜図解でわかる使い方とDNSの基本（エンベーダー）

目的別！Route 53レコードタイプとサブドメインの活用例

WebサイトやAPI向けの基本レコード設定例

一般的なウェブサイトやAPIをRoute 53で設定する際は、Aレコードやエイリアスレコードが中心になります。例えば、ドメインの頂点（ルートドメイン）であるexample.comをウェブサーバー（EC2インスタンスやELB）に紐付ける場合は、レコード名なし（または@）、タイプを「A」、値をEC2インスタンスのElastic IPアドレスまたはELBのDNS名とするエイリアスレコードを設定します。

サブドメインを活用する場合は、例えばwww.example.comをexample.comと同じリソースに紐付けるのであれば、レコード名をwww、タイプを「CNAME」、値をexample.comとして設定します。もしapi.example.comを別のAPI GatewayやELBに接続したい場合は、レコード名をapi、タイプを「A」または「エイリアス」とし、それぞれのターゲットリソースを設定します。特にAWSリソースを利用する場合は、IPアドレスの変動リスクを考慮し、エイリアスレコードを優先的に使用することが推奨されます。

また、メール送受信設定にはMXレコードを、ドメインの所有権確認やSPF（Sender Policy Framework）設定にはTXTレコードを利用するなど、目的に応じて様々なレコードタイプを適切に設定することで、ドメインの機能を最大限に引き出すことが可能になります。これらはウェブサイトやアプリケーションがインターネット上で機能するために不可欠な設定項目です。

サブドメインを活用した開発・ステージング環境の分離

サブドメインは、単にウェブサイトの異なるセクションを区別するだけでなく、開発、ステージング、本番といった異なる環境を分離する強力なツールとして活用できます。例えば、本番環境がexample.comで稼働している場合、開発環境用にdev.example.com、ステージング環境用にstg.example.comといったサブドメインを設定することが可能です。

これらのサブドメインは、それぞれ独立したAWSリソース（EC2インスタンス、ELB、S3バケットなど）を指すようにRoute 53で設定します。これにより、開発チームはdev.example.comで自由に新しい機能のテストやバグ修正を行い、QAチームはstg.example.comで本番リリース前の最終確認を行うことができます。本番環境に影響を与えることなく、安全かつ効率的な開発・デプロイプロセスを構築できる点が大きなメリットです。

各サブドメインのレコード設定は、前述のAレコード、AAAAレコード、エイリアスレコードなどを適切に利用します。例えば、dev.example.comを指すエイリアスレコードを開発用ELBに向け、stg.example.comを指すエイリアスレコードをステージング用ELBに向けるといった具体的な設定が考えられます。これにより、環境ごとに完全に分離されたリソース群を利用し、意図しない干渉や本番障害のリスクを大幅に軽減できます。

ドメインセキュリティ強化のためのCAAレコード設定

ドメインのセキュリティを強化する上で、「CAAレコード（Certificate Authority Authorization）」の設定は重要な手段の一つです。CAAレコードは、特定のドメインに対してSSL/TLS証明書の発行を許可する認証局（CA）を明示的に指定するためのレコードタイプです。これにより、不正な認証局による証明書の発行を防ぎ、フィッシング詐欺や中間者攻撃のリスクを低減することができます。

CAAレコードを設定していない場合、原則としてどの認証局でもドメインの所有者確認が取れれば証明書を発行できてしまいます。しかし、CAAレコードを設定することで「このドメインの証明書は、例えばLet’s Encryptからしか発行を許可しない」といった具体的なルールを設けることが可能になります。もし指定されていない認証局が証明書の発行リクエストを受け取った場合、その認証局は発行を拒否する必要があります。

Route 53でのCAAレコード設定は、ホストゾーンのレコード作成画面でタイプを「CAA」に選択し、値を設定します。値には、認証局のドメイン名や、証明書発行ポリシーに関するフラグなどを記述します。この設定は、特に企業の重要なサービスやウェブサイトにおいて、ドメインの信頼性を高め、ユーザーの安全を保護するために積極的に検討すべきセキュリティ対策の一つです。設定は一度行えば効果が持続するため、手間なくドメイン全体のセキュリティレベルを向上させることができます。

出典：Amazon Route 53 の概念（AWS Documentation）、【初心者向け】Amazon Route 53の主な機能を調べてみた（Serverworks Blog）

Route 53利用時の料金と設定における注意点

Route 53の料金体系とコスト最適化のポイント

Amazon Route 53の料金は、完全従量課金制であり、主に「管理しているホストゾーンの数」と「受信するDNSクエリの数」に基づいて算出されます。前払い契約などは不要で、利用した分だけ料金が発生する仕組みです。

• ホストゾーン料金: パブリックおよびプライベートホストゾーンの数に応じて月額料金が発生します。最初の25個のホストゾーンまでは比較的安価ですが、それを超えると料金が上がります。
• DNSクエリ料金: Route 53が処理するDNSクエリの数に応じて料金が発生します。標準クエリと、レイテンシー、加重、ジオロケーションなどの高度なルーティングポリシーを使用するクエリでは、料金が異なります。
• ドメイン登録料金: Route 53を通じてドメインを登録または更新する場合、ドメインの種類（.com, .jpなど）に応じて年間料金が発生します。
• ヘルスチェック料金: 設定したヘルスチェックの数に応じて月額料金が発生します。

コストを最適化するためには、まず使用していないホストゾーンは定期的に確認し、削除することが非常に重要です。ホストゾーンごとに月額料金が発生するため、不要なものを放置すると無駄なコストがかかります。また、高いクエリ数を発生させるサービスの場合、TTL値を適切に設定することでキャッシュ利用率を高め、Route 53へのクエリ数を減らす工夫も有効な場合があります。ただし、TTLを長くしすぎるとDNS変更時の反映が遅れるため、バランスを考慮する必要があります。

設定ミスを防ぐための確認事項とベストプラクティス

DNS設定は、ウェブサイトやアプリケーションのアクセスを左右する非常に重要な部分です。設定ミスはサービス停止に直結する可能性があるため、慎重な対応が求められます。設定ミスを防ぐための確認事項とベストプラクティスを以下に示します。

• 変更前のバックアップ: 現在のDNS設定をテキストファイルやスクリーンショットなどで記録しておきましょう。万が一の際に元の状態に戻せるようにします。
• テスト環境での検証: 新しいレコードタイプやルーティングポリシーを導入する際は、まず本番環境とは異なるテスト用のサブドメインや環境で動作確認を行うことが理想的です。
• TTL値の考慮: 変更の影響範囲や反映速度を考慮し、TTL値を一時的に短くする（例: 300秒）ことで、問題発生時の復旧を早めることができます。ただし、変更後は適切なTTL値に戻すことを忘れないでください。
• 複数人でのダブルチェック: 重要なDNS設定変更は、担当者だけでなく、別の担当者も内容を確認するダブルチェック体制を確立しましょう。
• アクセス権限の最小化: Route 53へのアクセス権限は、必要なユーザーにのみ最小限の権限で付与し、誤操作のリスクを低減します。

これらの対策を講じることで、DNS設定変更に伴うリスクを最小限に抑え、安定したサービス運用に繋げることができます。特にDNS伝播には時間がかかるため、計画的な作業が不可欠です。

ELBとRoute 53の役割分担とその連携

AWS環境で高可用性と負荷分散を実現する上で、ELB（Elastic Load Balancing）とRoute 53はそれぞれ異なる、しかし連携して機能する役割を担っています。この役割分担を正しく理解することは、効率的で堅牢なインフラ設計に不可欠です。

ELBの役割は、主に特定のAWSリージョン内でのトラフィック分散と、バックエンドインスタンスのヘルスチェックです。複数のEC2インスタンスやコンテナに対して均等に負荷を分散し、障害が発生したインスタンスを自動的に切り離すことで、リージョン内のサービス可用性を高めます。ELBは、そのDNS名をRoute 53に登録することで、外部からアクセス可能になります。

一方、Route 53の役割は、システム全体を俯瞰したルーティングと死活監視です。世界中のユーザーを最も適切なリージョンやサービスに誘導し、ELBを含めた様々なAWSリソースのヘルスチェックを行い、障害発生時には別の健全なリソースへとトラフィックを切り替えます。つまり、ELBがリージョン内の水平スケーリングと高可用性を担うのに対し、Route 53はマルチリージョン、マルチAZ（アベイラビリティーゾーン）にまたがる広域な可用性と耐障害性を実現します。

この連携により、例えばRoute 53のフェイルオーバールーティングポリシーを使って、プライマリリージョンにあるELBに障害が発生した場合、セカンダリリージョンにあるELBに自動的にトラフィックを切り替えるといった設定が可能です。両者を適切に組み合わせることで、単一障害点（Single Point of Failure）を排除し、極めて高いレベルの可用性を持つシステムを構築することができます。

出典：Amazon Route 53 定价（Amazon Web Services）、Amazon Route 53 の料金（Amazon Web Services）、【初心者向け】Amazon Route 53とは？主な機能や料金体系などを解説！（CloudTech）

【ケース】サブドメイン委譲ミスによるアクセス不可事例とその解決策

架空のケーススタディ：サブドメイン委譲失敗によるサービス停止

ここでは、架空のケースとして、とある企業が新しい情報発信プラットフォームを立ち上げる際、blog.example.comというサブドメインの委譲設定を誤り、サービスが一時的に停止してしまった事例をご紹介します。この企業は、既存のexample.comドメインは別のDNSプロバイダ（親ドメイン）で管理していましたが、ブログプラットフォームのインフラはAWS上に構築し、そのDNS設定をRoute 53で行う計画でした。

担当者は、Route 53でblog.example.comのホストゾーンを作成し、必要なAレコードなどを設定しました。しかし、親ドメイン側のDNSプロバイダで、blog.example.comのネームサーバー（NSレコード）をRoute 53が発行したネームサーバーに更新する作業を忘れてしまいました。結果として、ユーザーがblog.example.comにアクセスしようとしても、名前解決が正しく行われず、「ページが見つかりません」というエラーが表示され続け、新しいブログサービスは公開直後からアクセス不能に陥ってしまいました。

このミスは、Route 53でサブドメインのDNS設定を完了したとしても、そのサブドメインの権限を親ドメインからRoute 53へ正しく「委譲」する作業がなければ、インターネット上のDNSサーバーがRoute 53を参照しないために発生します。ドメイン全体のトラフィックに影響を及ぼす重大な設定ミスとして、迅速な対応が求められる事態となりました。

サービス停止に至る原因究明と対応手順

サブドメイン委譲ミスによるアクセス不可が発生した場合、まずは原因を特定することが重要です。一般的な原因究明と対応手順は以下の通りです。

1. DNSキャッシュのクリアと再確認: 自身のPCのDNSキャッシュをクリアし、再度アクセスを試みます。他のユーザーからもアクセスできないことを確認します。
2. DNSルックアップツールでの確認: digやnslookupといったコマンドラインツール、またはオンラインのDNSチェッカー（例: Google Public DNS）を使用して、blog.example.comの名前解決がどのように行われているかを確認します。特に、親ドメインのNSレコードがRoute 53のネームサーバーを指しているか、Route 53側のNSレコードが正しいかを検証します。
3. Route 53設定の確認: AWSコンソールでblog.example.comのホストゾーンを開き、Aレコードやエイリアスレコードが正しく設定されているかを確認します。
4. 親ドメイン側のNSレコード確認と修正: 最も重要なステップです。example.comを管理しているDNSプロバイダの管理画面にログインし、blog.example.comのNSレコードがRoute 53が発行した4つのネームサーバーを指すように設定されているかを確認します。もし設定が漏れていたり、誤っていたりした場合は、正しい値に更新します。
5. DNS伝播の待機: NSレコードの変更は、インターネット全体に反映されるまで時間がかかります（DNS伝播）。通常は数時間程度ですが、最大で48時間かかることもあります。この間は定期的にアクセスを試み、解決状況を監視します。

今回のケースでは、親ドメイン側のNSレコード設定の漏れが原因だったため、正しいネームサーバー情報で更新することで、無事にブログサービスへのアクセスが回復しました。

再発防止策と今後の運用における注意点

サブドメイン委譲ミスによるアクセス不可事例のような問題を再発させないためには、以下の防止策と運用における注意点を講じることが有効です。

• 手順書の作成とダブルチェック: ドメインやDNSの設定変更に関する詳細な手順書を作成し、変更作業を行う際は必ず手順書に沿って進めます。特に重要な設定（NSレコードの変更など）は、一人だけでなく複数人によるダブルチェックを徹底します。
• テスト環境での事前検証: 新しいサブドメインを設定する際は、本番環境に影響を与えないテスト用のドメインやサブドメイン（例: test.example.com）で、委譲設定やレコード設定の動作を事前に検証するプロセスを導入します。
• 影響範囲とDNS伝播時間の考慮: DNS設定変更は、すぐに反映されるわけではありません。変更作業は、アクセスが少ない時間帯を選ぶか、影響が少ないように計画的に実施します。また、DNS伝播を考慮した上で、サービスの公開や切り替えのスケジュールを立てるようにします。
• AWS公式ドキュメントの参照: Route 53の設定や機能については、常にAWS公式ドキュメントを最新の情報源として確認し、民間ブログや情報サイトの情報は補足として参照するに留めます。サービス仕様は変更される可能性があるため、公式情報が最も信頼できます。
• 監視体制の強化: DNS名前解決の監視や、ウェブサイトの稼働状況を継続的に監視するツールを導入し、異常を早期に検知できる体制を構築します。

これらの対策を講じることで、DNS関連のトラブルを未然に防ぎ、サービスの安定稼働と継続的な信頼性確保に繋がります。

出典：AWSブログリレー：Amazon Route 53とは？ 初学者向けに基本機能・料金・活用例を徹底解説（AWSブログ）