Route53講座

この講座では、AWSのDNSサービスであるRoute 53について学びます。

• ドメインとDNSの基本概念
• 名前解決の仕組み
• Route 53の特徴と構成要素
• ホストゾーンとレコードタイプ
• ルーティングポリシーの種類
• ヘルスチェックとフェイルオーバー

1. ドメインとは

ドメインとは、一言で言えば「インターネット上の住所（宛名）」のことです。普段私たちがWebサイトを見る時に入力する google.com や amazon.co.jp といった文字列がこれにあたります。

そもそも、インターネットの世界でコンピュータ同士が通信する際には、本来「IPアドレス」という数字の羅列（例：192.0.2.1）を使ってお互いの場所を特定しています。しかし、人間にとって、無機質な数字の羅列をいくつも暗記して使いこなすのは現実的ではありません。そこで、電話をする時に電話番号を直接打つのではなく、電話帳に登録した名前から相手を探すのと同じように、覚えにくいIPアドレス（数字）に、人間が覚えやすい名前（文字）をつけたものがドメインです。

1.1 ドメインの構造

ドメインの構造は、右側から左側に向かって、大きな分類から小さな分類へと流れる階層構造になっています。

例えば www.example.com というドメインを例に取ると、一番右にある .com や .jp の部分はトップレベルドメインと呼ばれ、国や組織の種類を表す最も大きな分類です。

その隣にある example の部分はセカンドレベルドメインと呼ばれ、組織名やサービス名など、所有者が自由に決められる名前の本体となります。

そして一番左にある www の部分はサブドメインと呼ばれ、一つのドメインを用途別に細かく部屋分けする際などに使われます。

2. DNSとは

ドメインが「住所の名前」だとすれば、DNSはその名前から実際の場所（IPアドレス）を割り出すための「巨大な電話帳システム」にあたります。

先ほど説明した通り、コンピュータは「IPアドレス」という数字でしか通信相手を認識できませんが、人間は「ドメイン名」を使いたいというギャップがあります。この両者の間に入り、人間が入力したドメイン名をコンピュータが理解できるIPアドレスに瞬時に変換する仕組みこそがDNSです。この変換作業のことを名前解決と呼びます。

DNSによる名前解決の流れを以下に示します。

sequenceDiagram
    participant Browser as ブラウザ
    participant Resolver as DNSリゾルバ
    participant Root as ルートDNSサーバ
    participant TLD as TLDサーバ（.com）
    participant Auth as 権威DNSサーバ（Route 53）

    Browser->>Resolver: example.comのIPアドレスは?
    Resolver->>Root: example.comの管理先は?
    Root->>Resolver: .comはこのTLDサーバ
    Resolver->>TLD: example.comの管理先は?
    TLD->>Resolver: Route 53が管理
    Resolver->>Auth: example.comのIPアドレスは?
    Auth->>Resolver: 192.0.2.1
    Resolver->>Browser: 192.0.2.1

私たちが普段ブラウザにURLを入力してEnterキーを押した瞬間、裏側では目に見えない速さでDNSサーバへの問い合わせが行われています。「example.comのIPアドレスはどこですか？」と聞きに行き、DNSから「その住所は192.0.2.1です」という回答を受け取って初めて、ブラウザは正しいWebサーバへと接続することができるのです。

つまり、どれだけ立派なWebサーバ（EC2）や配信ネットワーク（CloudFront）を構築しても、このDNSが正しく機能してユーザをそこへ導いてくれなければ、誰もそのサイトに辿り着くことはできません。AWSのRoute 53は、このインターネットの根幹を支える「道案内」の役割を担う、非常に信頼性の高いDNSサービスです。

3. Route53とは

Amazon Route 53は、AWSが提供する、高い可用性と拡張性を持ったクラウドDNSサービスです。ちなみに、サービス名の「53」という数字は、DNSへの通信に使われるポート番号（TCP/UDPの53番ポート）に由来しています。

先ほど説明した「インターネット上の電話帳」としての役割を担うのがこのサービスですが、Route 53は単にドメインとIPアドレスを紐付けるだけの静的な電話帳ではありません。ドメインの新規取得や管理といった登録業務も行えるほか、最大の特徴は、システムの稼働状況を監視し、状況に応じて案内先を自動的に変えることができる高度な制御機能を持っている点にあります。

例えば、「ヘルスチェック」と呼ばれる機能を使えば、Route 53は常に接続先のWebサーバが正常に動いているかを監視し続けます。もしメインのサーバに障害が発生して応答がなくなった場合、即座にそれを検知し、自動的に予備のサーバや「メンテナンス中」の画面を表示するS3バケットへ通信を切り替えるといった、柔軟な対応が可能です。

さらに、S3やCloudFront、ELB（ロードバランサー）といったAWSの他のサービスとの親和性が非常に高く、これらへの経路設定を簡単で最適に行える点も大きな強みです。

世界中に分散配置されたインフラを利用することで、DNSサービスとしては極めて異例の「SLA（サービス品質保証）100%」を掲げており、絶対に止まってはいけないインターネットの入り口を支える、非常に信頼性の高いサービスといえます。

4. Route53の構成要素

4.1 ホストゾーン (Hosted Zones)

ホストゾーンは、Route 53において特定のドメインに関するDNSレコードをまとめて管理するための「容器（コンテナ）」のようなものです。

例えば、 example.com というドメインを取得した場合、そのドメインに関する「Webサーバはここ」「メールサーバはあっち」といった具体的な行き先情報（レコード）を記述していくための専用のノートを一冊用意するイメージです。Route 53を利用する際は、まず管理したいドメインごとにこのホストゾーンを作成し、その中に詳細な設定を書き込んでいくのが最初のステップとなります。

ここで言う「ドメインごと」とは、取得したドメイン単位（example.com など）を指します。prod.example.com や dev.example.com といったサブドメインは、親ドメインのホストゾーン（example.com）内にレコードとして登録する形で管理するため、サブドメインごとに新しいホストゾーンを作成する必要はありません。

このホストゾーンには、大きく分けて2つの種類が存在します。

1つ目はパブリックホストゾーンです。これはインターネット上に公開されたWebサイトなど、世界中の誰もがアクセスできるドメインを管理するための一般的なゾーンです。

2つ目はプライベートホストゾーンです。こちらはAWSの閉じたネットワーク（VPC）内でのみ有効なドメインを管理するものです。これを利用すると、社内システムや開発環境のサーバに対して、インターネットには公開されない独自のドメイン名を付けて管理することが可能になります。

4.2 ヘルスチェック

ヘルスチェックは、Webサーバなどのリソースが正常に稼働しているかを定期的に診断する監視機能です。

この機能は、単にサーバが動いているかを見るだけではありません。世界中に点在するAWSの監視拠点から、指定されたIPアドレスやドメインに対して、10秒や30秒といった短い間隔でアクセスを試み続けます。そして、「3回連続で応答がなかったら故障（Unhealthy）とみなす」といった判定基準に基づき、厳密にステータスを管理しています。

最大の特徴は、この監視結果がDNSの動きと直接連動している点です。もし特定のサーバが「故障」と判定されると、Route 53は直ちにそのサーバのIPアドレスをDNSの応答リストから除外します。

これにより、ユーザが故障したサーバへ案内されてしまう事故を未然に防ぐことができます。

また、異常を検知した際にAmazon CloudWatchと連携して、管理者にメールで通知を送ることも可能であり、システムの安定運用を守るための番人として非常に重要な役割を担っています。

5. レコードの種類とエイリアス (Records & Alias)

ホストゾーンという「容器」を用意した後に、その中身として書き込む具体的な行き先情報のことを「レコード」と呼びます。このレコードにはいくつかの種類がありますが、インターネット標準で定められた一般的なものと、Route 53が独自に拡張した便利なものが存在します。

今回は網羅性を意識して、設定可能なほぼすべてのレコードを紹介しましたが、これらを現時点で完璧に暗記する必要はありません。

この中で、特に「Aレコード」「CNAMEレコード」「エイリアスレコード」、そして「NSレコード」の4つは実務でも頻繁に利用するため、これらはそれぞれの違いや役割をしっかり理解するようにしてみてください。

それ以外のレコードについては、実際に必要になったタイミングで「そういえば、あそこに書いてあったな」と思い出し、辞書のように参照できれば十分です。まずは主要なレコードから確実に押さえていきましょう。

5.1 Aレコード

一般的なDNSレコードとして最も基本となるのがAレコードです。これはドメイン名に対して、192.0.2.1 のような具体的なIPアドレスを直接紐付ける、最もシンプルな設定です。

5.2 CNAMEレコード

次に頻繁に使われるのがCNAMEレコードです。これはドメイン名を別のドメイン名に転送する「別名」の設定ですが、DNSの仕様上、ドメインの頂点（例えば www がつかない example.com そのもの）には設定できないという大きな制約があります。

5.3 エイリアスレコード

この「頂点にCNAMEが置けない」という長年の課題を解決するために作られたのが、Route 53特有の機能であるエイリアスレコードです。

これは、見た目はAレコードのように振る舞いながら、内部的にはCloudFrontやELB（ロードバランサー）、S3といったAWSリソースを直接指し示すことができる特殊なレコードです。

これを使えば、ドメインの頂点であっても問題なく他のAWSサービスへ転送設定ができるほか、IPアドレスが変わっても自動で追従してくれるため管理が楽になり、さらにAWSリソースへのクエリ料金が無料になるというコストメリットまであります。

5.4 NSレコード

NSレコード（ネームサーバ）です。

これは「このドメインの管理は、どのDNSサーバが担当しているか」をインターネット全体に知らせるための、最も重要な看板です。

Route 53でホストゾーンを作ると自動的に4つほど生成されますが、これをドメインの購入元（お名前.comなど）に登録することで初めて、世界中からのアクセスがRoute 53に届くようになります。つまり、ドメインとRoute 53を繋ぐための存在です。

5.5 SOAレコード

SOAレコード（Start of Authority）です。

これは、そのドメイン（ゾーン）の「管理情報」が書かれたレコードです。「誰が管理者か」「データが更新されたのはいつか（シリアル番号）」「キャッシュをどれくらい保持するか」といった技術的な定義が詰まっています。

これもホストゾーン作成時に自動生成される必須のレコードですが、通常、利用者が手動で編集することはほとんどありません。「このゾーンの設定ファイルはここから始まります」という宣言のようなものです。

5.6 TXTレコード

TXTレコード（テキスト）です。

元々はドメインに対して自由にメモを残すためのものでしたが、現在ではその自由度を活かして、「セキュリティ証明」のために頻繁に使われます。

例えば、「私がこのドメインの本当の持ち主です」と証明するための認証コードを書き込んだり、メールのなりすましを防ぐ設定（SPFなど）を記述したりと、ドメインの信頼性を担保するための検証用として非常に重要な役割を担っています。

5.7 その他の重要な標準レコード（MX・CAA・AAAA）

用途は限定されますが、現代のドメイン運用において頻繁に登場するレコードたちです。

MXレコード

「MX（Mail Exchange）レコード」です。

これはドメイン宛ての「メールの配送先」を指定するためのレコードです。Webサイト（Aレコード）とメールサーバを分けたい場合などに使われます。

特徴的なのは「優先度」という数字を設定できる点で、複数のメールサーバを登録しておき、「まずはメインのサーバに配送し、もし落ちていたら予備のサーバに送る」といった冗長構成を組むことが可能です。Google Workspaceなどを独自ドメインで利用する際にも必ず設定します。

CAAレコード

次に「CAA（Certification Authority Authorization）レコード」です。

これはセキュリティのためのレコードで、自分のドメインに対して「SSL/TLS証明書を発行しても良い認証局（CA）」を明示的に指定するものです。

例えば、「Amazon（ACM）だけが証明書を発行できる」と書いておけば、万が一、他の認証局で勝手に証明書が発行されそうになっても、その認証局がCAAレコードを確認して発行を拒否してくれます。意図しない証明書の不正発行を防ぐための「認可リスト」のような役割を果たします。

AAAAレコード

最後に「AAAA（クアッドエー）レコード」です。

これは最初に出てきた「Aレコード」の兄弟のような存在で、次世代のインターネット規格である「IPv6アドレス」をドメインに紐付けるためのものです。

Aレコードが従来の「IPv4（例：192.0.2.1）」を扱うのに対し、AAAAレコードはより長く複雑な「IPv6（例：2001:db8::1）」を扱います。最近ではスマホやIoT機器の普及でIPv4アドレスが枯渇しつつあるため、このAAAAレコードの重要性が年々高まっています。

6. ルーティングポリシー (Routing Policies)

ルーティングポリシーとは、Route 53がユーザからの問い合わせ（DNSクエリ）を受けた際に、「どのレコード（値）を返すか」を決定するための判断ルールのことです。

一般的なDNS（電話帳）は、誰がいつ問い合わせても、常に決まった一つのIPアドレスを答えるのが基本です。

しかし、Route 53ではこのポリシーを設定することで、「ユーザがいる場所」や「サーバの健康状態」、「アクセスの比率」などの様々な条件に応じて、返すIPアドレスを動的に変化させることができます。

つまり、単に決まった住所を教えるだけでなく、「今はこっちの道が混んでいるから、あっちのサーバに行ったほうが早いよ」とか「日本のユーザには日本のサーバを案内しよう」といった具合に、状況に合わせて最適な行き先を案内してくれる、賢いナビゲーション機能の設定とお考えください。

6.1 シンプルルーティング (Simple)

シンプルルーティングは、最も基本的で標準的なルーティング方式です。

特別な条件分岐を行わず、設定された値をそのまま素直に返す、いわば「普通のDNS」としての動きをします。

基本的には、1つのレコード名に対して1つのリソース（IPアドレスなど）を紐付ける際に利用します。

ただし、1つのレコードに複数のIPアドレスをまとめて登録することも可能です。その場合、Route 53は登録されたすべてのIPアドレスを順不同でクライアントに返却し、クライアント側（ブラウザなど）がその中から一つを選んでアクセスします。

あくまで「登録されたものを全て返す」というシンプルな動作であるため、後述するような「サーバの故障を検知して切り替える」とか「地域ごとに振り分ける」といった高度な判断は行いません。

6.2 フェイルオーバールーティング (Failover)

フェイルオーバールーティングは、システム障害などの緊急事態に備えて、メインの環境とバックアップの環境を自動で切り替えるためのポリシーです。いわゆる「アクティブ・パッシブ（Active-Passive）」構成を実現する際に使用されます。

ヘルスチェックの結果に基づくフェイルオーバーの流れを以下に示します。

flowchart TD
    R53["Route 53"] --> HC{"ヘルスチェック"}
    HC -- "正常" --> Primary["プライマリ<br>（本番サーバ）"]
    HC -- "異常検知" --> Secondary["セカンダリ<br>（S3ソーリーページ）"]

    R53 -. "定期監視" .-> Primary

このルーティングは、常に「ヘルスチェック」という監視機能とセットで利用します。Route 53は設定されたヘルスチェックを使って、メイン（プライマリ）のサーバが正常に稼働しているかを24時間365日監視し続けます。通常、ユーザは常にこのメインサーバへと案内されます。

しかし、もしメインのサーバからの応答が途絶えたり、エラーが返ってきたりした場合、Route 53はそれを「障害発生」と判断し、自動的に通信の宛先を予備（セカンダリ）の環境へと切り替えます。この機能により、サーバがダウンしてもサービス全体が停止してしまうのを防ぎ、代わりにS3に置いておいた「ただいまメンテナンス中です」という画面（ソーリーページ）を表示させるといった、ユーザに配慮した対応が可能になります。

6.3 レイテンシールーティング (Latency)

レイテンシールーティングは、複数のリージョンにシステムを展開している場合に、ユーザから見て「最も通信の遅延（レイテンシー）が少ない」リージョンへ自動的に案内するポリシーです。

Route 53は、世界中のネットワーク状況を常に計測しており、ユーザがアクセスしてきた場所から、東京リージョンへの通信が速いのか、それともバージニア北部リージョンへの通信が速いのかを瞬時に判断します。

例えば、同じ www.example.com というドメインであっても、日本にいるユーザは「東京リージョン」へ、アメリカにいるユーザは「バージニア北部リージョン」へといった具合に、それぞれのユーザにとって最も快適に通信できるサーバへ自動的に振り分けられます。

これにより、世界中のどこからアクセスしても、待ち時間の少ないサクサクとした操作感を提供することが可能になります。

6.4 位置情報ルーティング (Geolocation)

位置情報ルーティングは、ユーザがアクセスしてきた「国」や「地域（大陸や州）」に基づいて、特定のサーバへ誘導するポリシーです。

先ほどの「レイテンシールーティング」と混同しやすいのですが、あちらが「通信速度の速さ」を基準に自動で選ばれるのに対し、こちらは「ユーザがどこにいるか」という地理的な境界線に基づいて、管理者が意図的に行き先を指定する点が異なります。たとえ隣国のサーバの方が通信速度が速かったとしても、必ず設定された国のサーバへ誘導します。

主な利用シーンとしては、「日本からのアクセスには日本語のページを表示し、アメリカからのアクセスには英語のページを表示する」といったコンテンツのローカライズ（現地化）や、EUのデータ保護規則（GDPR）のように「ヨーロッパのユーザのデータは、必ずヨーロッパ圏内のサーバで処理しなければならない」といった法的な要件を満たす場合などに使われます。

なお、設定した国以外の場所からアクセスが来た場合に備えて、必ず「デフォルト（標準）」の行き先を設定しておくことが推奨されます。

6.5 加重ルーティング (Weighted)

加重ルーティングは、一つのドメイン名に対して複数の行き先（リソース）を登録し、それぞれの行き先にどれくらいの割合でアクセスを振り分けるかを管理者がコントロールできるポリシーです。

具体的には、各レコードに対して「0」から「255」までの数値を「重み（ウェイト）」として設定します。Route 53は、設定された重みの合計値に対する比率を計算し、その確率に基づいてアクセスを振り分けます。例えば、サーバAに「10」、サーバBに「90」という重みを設定すれば、アクセスの10%はサーバAへ、残りの90%はサーバBへ流れるようになります。

この機能は、主に新しいバージョンのアプリケーションを安全にリリースしたい場合に重宝されます。新機能をいきなり全員に公開するのではなく、まずは全ユーザの1%だけ新しいサーバに誘導して様子を見るといった「カナリアリリース」や、2つの異なるデザインを特定の比率で出し分けて効果を測定する「A/Bテスト」などを、DNSレベルで手軽に実現することができます。

7. 主なユースケース

Route 53は、ドメイン管理と高度なトラフィック制御を実現するサービスです。以下に代表的なユースケースを紹介します。

7.1 Webサービスのドメイン管理

独自ドメインを取得・管理し、CloudFrontやALBなどのAWSリソースに紐付けます。エイリアスレコードを使用することで、ドメインの頂点（example.com）でも簡単にAWSサービスへのルーティングを設定できます。

7.2 災害対策・フェイルオーバー構成

ヘルスチェックと組み合わせることで、プライマリサイトに障害が発生した場合に自動的にセカンダリサイト（別リージョンやS3のソーリーページ）へ切り替えます。ユーザへの影響を最小限に抑えながら、システムの可用性を向上させます。

7.3 グローバルサービスの最適化

レイテンシールーティングや位置情報ルーティングを使用して、ユーザの所在地に応じて最適なリージョンのサーバへ誘導します。世界中のユーザに対して、それぞれにとって最も応答の速いサーバからサービスを提供できます。

8. 設計のポイント

Route 53を設計する際の主要な検討項目を以下にまとめます。

9. まとめ

この講座では、AWSのDNSサービスであるRoute 53について学びました。

• ドメインはインターネット上の住所であり、DNSはドメイン名をIPアドレスに変換する「名前解決」を行う
• Route 53はホストゾーン（パブリック/プライベート）でドメインのDNSレコードを管理する
• ヘルスチェックでサーバの稼働状況を監視し、障害時に自動で切り替えができる
• Aレコード、CNAMEレコード、エイリアスレコード、NSレコードなど用途に応じたレコードタイプがある
• ルーティングポリシー（シンプル、フェイルオーバー、レイテンシー、位置情報、加重）で柔軟なトラフィック制御が可能