Amazon Route 53とは？できること・各機能・動作の仕組みを解説
Amazon Route 53 は、example.com のようなドメイン名と、その名前についての情報を管理するAWSのサービスです。Webサイトの接続先を調べるための情報を返したり、接続先の状態に応じて返す情報を変えたりできます。
この記事では、まずRoute 53のできることを大まかにつかみ、次に各機能と用語を整理します。そのうえで、実際の問い合わせがどのように処理されるかを見ていきます。
Route 53の役割と、できること
Section titled “Route 53の役割と、できること”Route 53の中心となるのは、**DNS（Domain Name System）**という、名前をもとに接続先などの情報を調べる仕組みです。Route 53では、この仕組みで使う情報を保存し、問い合わせに回答します。
Webサイトの場合、ブラウザーはURLに含まれる名前から接続先を調べます。Route 53はその名前についての情報を持ち、接続先を調べる処理を支えます。管理できる情報には、Webサイトの接続先のほか、メールの配送先などもあります。
Route 53には、大きく見ると次のような機能があります。
| 機能 | できること |
|---|---|
| ドメイン名の登録・管理 | example.com のようなドメイン名を登録し、維持する |
| DNS情報の管理と回答 | 名前に対応するIPアドレスやメールの配送先などを管理し、問い合わせに回答する |
| DNSの回答の選択 | 複数の接続先から、割合や通信の遅延、地理的位置などに応じて回答を選ぶ |
| 接続先の状態の監視 | 接続先が利用できるかを確認し、その結果をDNSの回答選択に反映する |
| 内部向けの名前解決とDNSの転送 | AWS内のネットワークや、接続された社内ネットワークで使う名前を調べられるようにする |
このように、Route 53は「名前と接続先の対応を保存する」「問い合わせに回答する」「条件に応じて回答を選ぶ」といった機能を持っています。ドメイン登録も含めたサービスの全体像は、AWS公式のRoute 53の説明でも確認できます。
Route 53を理解するための機能と用語
Section titled “Route 53を理解するための機能と用語”ここからは、概要に登場した機能を理解するために、名前や情報の管理単位、回答を選ぶ機能を一つずつ整理します。具体的な処理の流れは、これらを確認したあとに説明します。
ドメイン名・IPアドレス・URL
Section titled “ドメイン名・IPアドレス・URL”ドメイン名は、example.com や shop.example.com のような名前です。shop.example.com は example.com の配下にある名前で、サブドメインと呼びます。
IPアドレスは、ネットワーク上で通信相手を識別するためのアドレスです。192.0.2.10 のようなIPv4や、IPv6という形式があります。この記事の 192.0.2.10 は説明用の値です。
普段ブラウザーで使うURLには、ドメイン名のほか、接続方法やページを指定する情報も含まれています。
| URLの例 | 各部分が表すこと |
|---|---|
https://shop.example.com/products | Web上のページなどの場所を表すURL全体 |
https:// | 暗号化されたWeb通信を使うこと |
shop.example.com | 接続先を表すドメイン名 |
/products | サイト内のページなどを指定するパス |
ドメイン名をもとにIPアドレスなどの情報を調べる処理を、名前解決と呼びます。
DNSリゾルバーと権威DNSサーバー
Section titled “DNSリゾルバーと権威DNSサーバー”DNSリゾルバーは、端末から名前解決の依頼を受け、必要な情報を調べて返す役割です。利用者の端末は通常、このリゾルバーに問い合わせます。
権威DNSサーバーは、そのドメインについて正式な回答を持つDNSサーバーです。Route 53で公開用のDNS情報を管理している場合、Route 53の権威DNSサーバーが、保存された情報に基づいて問い合わせへ回答します。
リゾルバーは情報を調べる役割、権威DNSサーバーは担当するドメインの情報を回答する役割、と整理できます。
ホストゾーン：DNS情報をまとめる場所
Section titled “ホストゾーン：DNS情報をまとめる場所”ホストゾーンは、ドメインと配下の名前について、DNS情報をまとめて管理する入れ物です。たとえば example.com のホストゾーンには、shop.example.com や api.example.com の情報を置けます。
ホストゾーンには、公開範囲の異なる2種類があります。
| 種類 | DNS情報を利用する範囲 |
|---|---|
| パブリックホストゾーン | インターネット上の名前解決 |
| プライベートホストゾーン | 関連付けたVPCや、適切なDNS転送を構成した接続元での名前解決 |
VPCはAWS内で使うネットワークです。プライベートホストゾーンには、内部処理から参照する db.internal.example.com のような名前の情報を保存できます。ネットワーク自体の役割を確認したい場合は、下記の記事を参照してください。
DNSレコード：名前ごとに保存する情報
Section titled “DNSレコード：名前ごとに保存する情報”ホストゾーンの中の、一つ一つの情報をDNSレコードと呼びます。レコードには、名前、情報の種類、その値などが含まれます。
| レコードの種類 | 保存する情報 |
|---|---|
| A | 名前に対応するIPv4アドレス |
| AAAA | 名前に対応するIPv6アドレス |
| CNAME | 別のドメイン名との対応 |
| MX | そのドメインのメールの配送先 |
| TXT | ドメインの所有確認などに使う文字列 |
| NS | そのゾーンの回答を担当するネームサーバーの情報 |
たとえば、shop.example.com のAレコードに 192.0.2.10 を保存すると、その名前についてIPv4アドレスを問い合わせた際の回答になります。種類ごとの詳細はサポートされているDNSレコードに記載されています。
ドメイン登録と委任
Section titled “ドメイン登録と委任”ドメイン登録は、使うドメイン名を登録・維持する仕組みです。ドメインの登録先と、DNS情報を管理するサービスは、それぞれ別に選べます。他社で登録したドメインのDNS情報をRoute 53で管理することもできます。
DNSでは「このドメインについては、このネームサーバーが回答を担当する」という情報も管理されています。ネームサーバーはDNSサーバーのことです。親のゾーンから担当先を示し、DNSの回答を任せる関係を委任と呼びます。
Route 53が情報を保存するホストゾーンと、そのゾーンへ問い合わせを導く委任には、それぞれ役割があります。ドメイン登録とDNSの関係も参照してください。
Alias：AWSリソースを参照するレコード
Section titled “Alias：AWSリソースを参照するレコード”Route 53のAlias（エイリアス）レコードは、対応するAWSリソースや、同じホストゾーン内の対応するレコードを参照する機能です。
Aliasは独立したDNSレコードタイプではなく、AやAAAAなどのレコードで利用するRoute 53固有の指定です。たとえば、**Application Load Balancer（ALB）**というWeb通信を複数の接続先へ振り分けるサービスを、参照先にできます。
また、ホストゾーンと同じ名前である example.com を**ゾーン頂点（zone apex）**と呼びます。ゾーン頂点にはCNAMEを作れませんが、対応先へのAliasレコードは作れます。参照できる対象や制約は、AliasとCNAMEの違いに記載されています。
キャッシュとTTL：回答を保存する仕組み
Section titled “キャッシュとTTL：回答を保存する仕組み”リゾルバーは、以前取得した回答を一時保存して再利用します。この保存をキャッシュと呼びます。
**TTL（Time To Live）**は、回答をキャッシュできる時間です。たとえばTTLが300秒なら、リゾルバーは取得した回答を最大300秒間再利用できます。AWSリソースを参照するAliasでは、TTLも参照先の値を使います。
ルーティングポリシー：回答を選ぶルール
Section titled “ルーティングポリシー：回答を選ぶルール”同じ名前に複数の接続先があるとき、どの回答を選ぶかを決めるルールがルーティングポリシーです。
| ポリシー | 回答を選ぶ基準 |
|---|---|
| シンプル | 基本的な名前と接続先の対応 |
| 加重（Weighted） | 接続先に付けた相対的な重み |
| レイテンシー（Latency：通信遅延） | AWSが持つ、リージョンとの通信遅延のデータ |
| フェイルオーバー（Failover） | 接続先の正常性と、主系・待機系の区別 |
| 位置情報（Geolocation） | DNS問い合わせ元の地理的位置 |
このほか、リソースの地理的位置とバイアス（受け持つ地理的範囲の補正値）を使う地理的近接性（Geoproximity）、送信元IPアドレスの範囲に基づくIPベース、正常なレコードを最大8件回答する**複数値回答（Multivalue answer）**があります。ルーティングポリシーの一覧で全体を確認できます。
ヘルスチェック：接続先の状態を確認する機能
Section titled “ヘルスチェック：接続先の状態を確認する機能”ヘルスチェックは、接続先が利用できるかを継続して確認する機能です。たとえば、一定間隔でWebページへの応答を調べ、その結果を正常性の判断に使います。
通常のレコードには、作成したヘルスチェックを関連付けられます。ALBなど対応するAWSリソースを指すAliasには、**Evaluate Target Health（ターゲットの正常性の評価）**という設定もあり、参照先の状態を回答選択へ反映できます。利用条件は参照先によって異なります。
VPC Resolverとエンドポイント：内部の名前解決とDNS転送
Section titled “VPC Resolverとエンドポイント：内部の名前解決とDNS転送”Route 53 VPC Resolverは、VPC内のリソースから、プライベートホストゾーンや公開ドメインなどの名前解決を行う仕組みです。以前はRoute 53 Resolverと呼ばれていた機能です。
Resolverエンドポイントは、VPCと社内ネットワークなどの間で、DNS問い合わせを受け渡す出入口です。
- インバウンド：社内などからVPC側へDNSの問い合わせを受け入れる。
- アウトバウンド：VPC側から社内などのDNSサーバーへ問い合わせを送る。
ここまでで、Route 53が管理する情報と、問い合わせや回答に関わる機能を整理できました。次は、これらが実際にどのようにつながって動くかを見ていきます。
Route 53が動く仕組み
Section titled “Route 53が動く仕組み”名前解決からWebサイトへ接続するまで
Section titled “名前解決からWebサイトへ接続するまで”https://shop.example.com/products を開く場合を考えます。example.com のパブリックホストゾーンに、次のAレコードが保存されているものとします。
名前：shop.example.com種類：A値：192.0.2.10（説明用のIPアドレス）名前解決の回答がまだキャッシュされていない場合、次のように処理が進みます。
- ブラウザー側からDNSリゾルバーへ、
shop.example.comのIPアドレスを問い合わせる。 - リゾルバーはDNSの委任情報をたどり、
example.comを担当するRoute 53の権威DNSサーバーを見つける。 - Route 53はホストゾーンから名前と種類が合うレコードを探し、
192.0.2.10を回答する。 - リゾルバーから回答を受け取ったブラウザーが、そのIPアドレスへHTTPSで接続し、ページを取得する。
sequenceDiagram
participant Browser as 利用者のブラウザー
participant Resolver as DNSリゾルバー
participant DNS as Route 53の権威DNS
participant Web as Webサーバー
Browser->>Resolver: shop.example.comのIPアドレスを問い合わせる
Note over Resolver: 委任情報をたどり担当の権威DNSを見つける
Resolver->>DNS: shop.example.comのAレコードを問い合わせる
Note over DNS: ホストゾーン内のレコードを確認する
DNS-->>Resolver: 192.0.2.10を回答する
Resolver-->>Browser: IPアドレスを返す
Browser->>Web: 得られたIPアドレスへHTTPSで接続する
Web-->>Browser: ページの内容を返す
図では、ルートDNSや親ゾーンへの個々の問い合わせを省略しています。Route 53は、名前に対応する情報を回答する段階を担当します。名前解決のあと、Web通信はブラウザーからWebサーバーへ進み、/products のようなパスはWebサーバーやアプリケーション側で扱われます。AWS公式の名前解決の流れでも、この役割を確認できます。
回答がキャッシュされている場合
Section titled “回答がキャッシュされている場合”リゾルバーが有効な回答を保存していれば、Route 53へ改めて問い合わせずに、その回答を返せます。この仕組みによって、名前解決にかかる時間やDNSへの問い合わせを減らせます。
たとえばTTLが300秒の回答を取得した直後に、Route 53側のレコードが更新されたとします。それでも、リゾルバーは以前の回答を残りの有効時間中、再利用することがあります。
そのため、Route 53の回答が変わることと、利用者が新しい接続先へアクセスすることには時間差があります。この性質は、後で説明する障害時の回答の切替にも関係します。DNSのベストプラクティスでは、TTLと回答の再利用の関係が説明されています。
AliasでAWSリソースを参照している場合
Section titled “AliasでAWSリソースを参照している場合”通常のAレコードの例では、保存されているIPアドレスが回答になりました。ALBを参照するAliasでは、Route 53が参照先のALBに対応するIPアドレスを回答します。
ALB側のIPアドレスが変わると、Route 53の回答もその変更に追従します。これは、レコードが固定のIPアドレスの値を持つ代わりに、対応するAWSリソースを参照しているためです。
AliasにもDNSキャッシュは関係します。参照先に追従して回答が変わることと、すべてのリゾルバーが新しい回答を使い始めることには、同じように時間差があります。
複数の接続先から回答を選ぶ場合
Section titled “複数の接続先から回答を選ぶ場合”同じ名前に複数の接続先がある場合、Route 53はルーティングポリシーを使って回答を選びます。
たとえば、shop.example.com に東京側と大阪側のレコードがあり、加重ルーティングで重みが9対1になっているとします。この場合、Route 53はその重みに基づく割合で、どちらのレコードを回答するか選びます。
ここで選ばれるのはDNSの回答です。同じ回答をリゾルバーが再利用するため、実際のWebリクエストが常に正確な9対1になるわけではありません。
ポリシーをレイテンシーにすると、選択の基準はAWSが持つ遅延データになります。位置情報の場合は、DNS問い合わせ元の地理的位置が基準になります。つまり、回答を選ぶルールが変わることで、同じドメイン名でも接続先の案内の仕方が変わります。
正常性に応じて回答を変える場合
Section titled “正常性に応じて回答を変える場合”ヘルスチェックを関連付けたレコードでは、Route 53は継続的に確認している接続先の状態を、回答選択に使います。DNS問い合わせのたびに接続先を検査する仕組みではありません。
たとえば、主系・待機系それぞれにヘルスチェックを関連付け、フェイルオーバールーティングを使う場合、次のように回答が決まります。
| 主系の状態 | 待機系の状態 | Route 53の回答 |
|---|---|---|
| 正常 | 正常 | 主系 |
| 異常 | 正常 | 待機系 |
| 異常 | 異常 | 主系 |
このように、回答するルールと接続先の状態が組み合わさり、主系から待機系へ案内が変わります。両方が異常なら主系が回答されるなど、すべての異常な接続先が一律に除外され続けるわけではありません。正常性を使った回答選択に詳しい条件があります。
また、待機系を回答する状態になっても、以前の回答をキャッシュしているリゾルバーは、しばらくその回答を返すことがあります。接続中の通信がその瞬間に切り替わるわけでもありません。
VPCや社内ネットワークで名前解決する場合
Section titled “VPCや社内ネットワークで名前解決する場合”VPC内のリソースが db.internal.example.com を調べる場合は、VPC Resolverが、そのVPCに関連付けられたプライベートホストゾーンの情報を使って回答できます。
この名前解決によって接続先が分かっても、実際の通信はネットワークの経路や、通信を許可する設定に従います。名前の回答と、サーバーへ接続する通信には、それぞれの仕組みがあります。プライベートホストゾーンの説明も参照してください。
社内ネットワークとVPCの間では、問い合わせの方向に応じて次のように処理されます。
- 社内からAWS内部の名前を調べる場合は、社内のDNSサーバーからインバウンドエンドポイントへ問い合わせを転送し、VPC側で名前解決する。
- VPCから社内の名前を調べる場合は、対象ドメインの転送ルールに従い、アウトバウンドエンドポイントから社内のDNSサーバーへ問い合わせる。
問い合わせは、VPCと社内ネットワークの間に用意された通信経路を通ります。こうして、AWS側と社内側に分かれて管理されているDNS情報を、両方の環境から調べられます。VPC Resolverの役割では、両方向の流れが説明されています。
Route 53は、これらの機能を通して名前と接続先の関係を管理し、条件や正常性に応じて回答を選べるサービスです。各機能を使った構成の選択を学ぶ場合は、下記の記事へ進んでください。
2026-10-21にAWS公式資料を確認しました。