Route 53でDNSとドメイン管理を行う

前回の記事では、CloudWatchによるAWSリソースの監視について解説しました。本記事では、AWSが提供する高可用性・高スケーラビリティなDNSサービスであるAmazon Route 53について解説します。ドメインの管理からDNSレコードの設定、ルーティングポリシーの使い分け、ヘルスチェックによる可用性向上まで、DNS管理に必要な知識を身につけましょう。

Amazon Route 53とは

Amazon Route 53は、AWSが提供するスケーラブルで高可用性なドメインネームシステム（DNS）Webサービスです。「Route 53」という名前は、DNSサーバーが使用するTCP/UDPポート番号53番に由来しています。

Route 53は単なるDNSサービスにとどまらず、ドメインの登録、トラフィックのルーティング、リソースのヘルスチェックを統合的に提供します。

Route 53の主な機能

Route 53には以下の主要機能があります。

Route 53を使う理由

Route 53を選択する理由を以下に示します。

graph TB
    subgraph "Route 53のメリット"
        R53[Route 53]
        R53 --> Benefit1[100%可用性SLA<br/>高い信頼性]
        R53 --> Benefit2[AWSサービスとの<br/>シームレスな連携]
        R53 --> Benefit3[多彩なルーティング<br/>ポリシー]
        R53 --> Benefit4[ヘルスチェックによる<br/>自動フェイルオーバー]
    end

Route 53はAWSの他のサービスと緊密に統合されています。ELB、CloudFront、S3静的Webサイトホスティング、Elastic Beanstalkなどのリソースに対して、エイリアスレコードを使用することで簡単にDNSルーティングを設定できます。

DNSの基本概念

Route 53の詳細に入る前に、DNSの基本概念を理解しておきましょう。

DNSとは

DNS（Domain Name System）は、人間が理解しやすいドメイン名（例: example.com）を、コンピュータが理解できるIPアドレス（例: 192.0.2.1）に変換するシステムです。

sequenceDiagram
    participant User as ユーザー
    participant Browser as ブラウザ
    participant Resolver as DNSリゾルバ
    participant DNS as DNSサーバー
    participant Server as Webサーバー

    User->>Browser: www.example.comにアクセス
    Browser->>Resolver: www.example.comのIPアドレスは?
    Resolver->>DNS: www.example.comを問い合わせ
    DNS-->>Resolver: 192.0.2.1
    Resolver-->>Browser: 192.0.2.1
    Browser->>Server: 192.0.2.1に接続
    Server-->>Browser: Webページを返却
    Browser-->>User: ページを表示

DNSレコードの種類

DNSレコードは、ドメインに関する情報を定義します。Route 53でサポートされている主要なレコードタイプを以下に示します。

CNAMEとAレコードの違い

CNAMEレコードとAレコードの使い分けは重要です。

graph LR
    subgraph "Aレコード"
        A1[www.example.com] -->|Aレコード| A2[192.0.2.1]
    end

graph LR
    subgraph "CNAMEレコード"
        C1[www.example.com] -->|CNAME| C2[example.com] -->|Aレコード| C3[192.0.2.1]
    end

Zone Apex（ネイキッドドメイン）とは、サブドメインなしのドメイン名（例: example.com）のことです。CNAMEはZone Apexには設定できないため、Route 53ではエイリアスレコードを使用します。

ホストゾーン

ホストゾーン（Hosted Zone）は、特定のドメインとそのサブドメインへのトラフィックをルーティングする方法を定義するコンテナです。

パブリックホストゾーンとプライベートホストゾーン

Route 53には2種類のホストゾーンがあります。

graph TB
    subgraph "パブリックホストゾーン"
        Internet((インターネット)) --> PubDNS[Route 53<br/>パブリックホストゾーン]
        PubDNS --> ALB[ALB]
        PubDNS --> CF[CloudFront]
    end

graph TB
    subgraph "プライベートホストゾーン"
        subgraph "VPC"
            App[アプリケーション] --> PriDNS[Route 53<br/>プライベートホストゾーン]
            PriDNS --> DB[RDS<br/>db.internal]
            PriDNS --> Cache[ElastiCache<br/>cache.internal]
        end
    end

パブリックホストゾーンの作成

パブリックホストゾーンを作成する際は、ドメイン名を指定します。作成後、4つのネームサーバー（NS）レコードが自動的に割り当てられます。

ドメインをRoute 53で管理するには、ドメインレジストラ（お名前.comやAWS自体など）でネームサーバーをRoute 53のNSレコードに変更する必要があります。

sequenceDiagram
    participant User as 管理者
    participant R53 as Route 53
    participant Registrar as ドメインレジストラ

    User->>R53: ホストゾーン作成（example.com）
    R53-->>User: NSレコード4つを返却
    Note right of R53: ns-123.awsdns-xx.org<br/>ns-456.awsdns-xx.co.uk<br/>ns-789.awsdns-xx.com<br/>ns-012.awsdns-xx.net
    User->>Registrar: ネームサーバーを<br/>Route 53のNSに変更
    Registrar-->>User: 設定完了
    Note right of Registrar: 変更が反映されるまで<br/>最大48時間かかる場合あり

プライベートホストゾーンの作成

プライベートホストゾーンは、1つ以上のVPCに関連付けて作成します。関連付けたVPC内のリソースからのみDNSクエリが解決されます。

プライベートホストゾーンの活用例として、内部サービスへのアクセスを簡素化できます。

1
2
3
4
5

# IPアドレスでの接続（管理が煩雑）
mysql -h 10.0.1.123 -u admin -p

# プライベートホストゾーンでの接続（わかりやすい）
mysql -h db.example.internal -u admin -p

レコードセットの設定

レコードセットは、Route 53でトラフィックをルーティングするための設定です。

基本的なレコード設定項目

レコードを作成する際に設定する主な項目を以下に示します。

エイリアスレコード

エイリアスレコードは、Route 53独自の拡張機能です。CNAMEの制限を克服し、AWSリソースへのルーティングを効率化します。

エイリアスレコードを設定できるAWSリソースは以下のとおりです。

• Elastic Load Balancing（ALB、NLB、CLB）
• Amazon CloudFront ディストリビューション
• Amazon S3 静的Webサイトホスティングバケット
• AWS Elastic Beanstalk 環境
• Amazon API Gateway
• AWS Global Accelerator
• 同じホストゾーン内の別のRoute 53レコード

TTL（Time To Live）の設定

TTLは、DNSリゾルバがレコードをキャッシュする時間を秒単位で指定します。

一般的には、通常運用時は300〜3600秒を設定し、変更予定がある場合は事前にTTLを短くしておくことを推奨します。

ルーティングポリシー

ルーティングポリシーは、Route 53がDNSクエリに応答する方法を決定します。要件に応じて適切なポリシーを選択することで、可用性、パフォーマンス、コストを最適化できます。

ルーティングポリシーの種類

Route 53では以下のルーティングポリシーを提供しています。

シンプルルーティング

最も基本的なルーティングポリシーです。単一のリソースにトラフィックをルーティングします。

graph LR
    User[ユーザー] --> R53[Route 53<br/>シンプルルーティング]
    R53 --> EC2[EC2インスタンス<br/>192.0.2.1]

シンプルルーティングでは、1つのレコードに複数の値（IPアドレス）を設定することも可能です。この場合、すべての値がランダムな順序で返却され、クライアントが1つを選択します。ただし、ヘルスチェックとの連携はできません。

加重ルーティング

トラフィックを指定した比率で複数のリソースに分散します。カナリアリリースやBlue/Greenデプロイメントに最適です。

graph LR
    User[ユーザー] --> R53[Route 53<br/>加重ルーティング]
    R53 -->|80%| Old[旧バージョン<br/>v1.0]
    R53 -->|20%| New[新バージョン<br/>v2.0]

加重ルーティングの設定例として、以下のようなシナリオを考えます。

Weightの比率は相対的なもので、合計が100である必要はありません。Weight=0を設定すると、そのリソースへのトラフィックを停止できます。

フェイルオーバールーティング

プライマリリソースの障害を検知した場合、自動的にセカンダリリソースにトラフィックを切り替えます。

graph TB
    User[ユーザー] --> R53[Route 53<br/>フェイルオーバー]
    R53 --> HC[ヘルスチェック]
    HC -->|正常時| Primary[プライマリ<br/>東京リージョン]
    HC -->|異常時| Secondary[セカンダリ<br/>大阪リージョン]

フェイルオーバールーティングでは、プライマリとセカンダリの2つのレコードを作成し、プライマリにはヘルスチェックを関連付けます。

レイテンシールーティング

複数のリージョンにリソースを配置している場合、ユーザーからのレイテンシーが最も低いリソースにトラフィックをルーティングします。

graph TB
    subgraph "日本のユーザー"
        JP[ユーザー<br/>日本] --> R53_1[Route 53]
        R53_1 -->|低レイテンシー| Tokyo[東京リージョン]
    end

graph TB
    subgraph "アメリカのユーザー"
        US[ユーザー<br/>アメリカ] --> R53_2[Route 53]
        R53_2 -->|低レイテンシー| Virginia[バージニア<br/>リージョン]
    end

レイテンシールーティングは、AWSがグローバルに収集しているネットワークレイテンシーデータに基づいて判断されます。実際のユーザーの位置ではなく、DNSリゾルバの位置に基づいて判断される点に注意が必要です。

位置情報ルーティング

ユーザーの地理的位置に基づいてトラフィックをルーティングします。コンテンツのローカライゼーションや、法規制への対応に使用されます。

graph TB
    R53[Route 53<br/>位置情報ルーティング]
    JP[日本のユーザー] --> R53
    EU[ヨーロッパのユーザー] --> R53
    Other[その他の地域] --> R53
    R53 --> JP_Site[日本向けサイト]
    R53 --> EU_Site[EU向けサイト<br/>GDPR準拠]
    R53 --> Default[デフォルトサイト]

位置情報ルーティングでは、「デフォルト」レコードを作成することを推奨します。デフォルトがない場合、位置を特定できないユーザーにはレコードが返却されません。

複数値回答ルーティング

複数のリソースを返却し、簡易的な負荷分散とヘルスチェックを組み合わせた構成を実現します。

ヘルスチェック

Route 53のヘルスチェックは、リソースの正常性を監視し、異常を検知した場合にトラフィックを別のリソースにルーティングするための機能です。

ヘルスチェックの種類

Route 53では3種類のヘルスチェックを提供しています。

エンドポイントヘルスチェックの設定

エンドポイントヘルスチェックの主要な設定項目を以下に示します。

ヘルスチェックのアーキテクチャ

Route 53のヘルスチェックは、世界中の複数のヘルスチェッカーから実行されます。

graph TB
    subgraph "Route 53 ヘルスチェック"
        HC1[ヘルスチェッカー<br/>US-East]
        HC2[ヘルスチェッカー<br/>EU-West]
        HC3[ヘルスチェッカー<br/>AP-Northeast]
    end
    
    Target[監視対象<br/>エンドポイント]
    
    HC1 -->|チェック| Target
    HC2 -->|チェック| Target
    HC3 -->|チェック| Target
    
    HC1 --> Aggregate[結果の集約]
    HC2 --> Aggregate
    HC3 --> Aggregate
    
    Aggregate --> Result{18%以上が<br/>正常と判定?}
    Result -->|はい| Healthy[Healthy]
    Result -->|いいえ| Unhealthy[Unhealthy]

デフォルトでは、ヘルスチェッカーの18%以上がエンドポイントを正常と判定した場合に「Healthy」となります。

プライベートリソースのヘルスチェック

Route 53のヘルスチェッカーはインターネット上にあるため、VPC内のプライベートリソースに直接アクセスできません。プライベートリソースを監視するには、以下の方法を使用します。

graph TB
    subgraph "VPC"
        Private[プライベート<br/>リソース]
        CWAgent[CloudWatch<br/>Agent]
        Private --> CWAgent
    end
    
    CWAgent --> CW[CloudWatch<br/>メトリクス]
    CW --> Alarm[CloudWatch<br/>アラーム]
    Alarm --> R53HC[Route 53<br/>ヘルスチェック]

CloudWatch Agentでメトリクスを収集し、CloudWatchアラームを作成して、そのアラームをRoute 53ヘルスチェックで監視する構成が一般的です。

実践的な構成例

Route 53を活用した実践的なアーキテクチャパターンを紹介します。

マルチリージョンフェイルオーバー構成

災害対策（DR）のために、複数リージョンでアクティブ-スタンバイ構成を構築する例です。

graph TB
    User[ユーザー] --> R53[Route 53<br/>フェイルオーバー<br/>ルーティング]
    
    subgraph "プライマリ（東京）"
        R53 -->|Primary| ALB_TK[ALB]
        ALB_TK --> EC2_TK[EC2]
        EC2_TK --> RDS_TK[RDS Primary]
    end
    
    subgraph "セカンダリ（大阪）"
        R53 -->|Secondary| ALB_OS[ALB]
        ALB_OS --> EC2_OS[EC2]
        EC2_OS --> RDS_OS[RDS Replica]
    end
    
    R53 --> HC[ヘルスチェック]
    HC --> ALB_TK
    
    RDS_TK -.->|レプリケーション| RDS_OS

この構成のポイントは以下のとおりです。

1. プライマリリージョン（東京）にメインのインフラを配置
2. セカンダリリージョン（大阪）にスタンバイ環境を構築
3. Route 53のフェイルオーバールーティングでプライマリを優先
4. ヘルスチェックでプライマリのALBを監視
5. プライマリ障害時に自動的にセカンダリへ切り替え

Blue/Greenデプロイメント構成

加重ルーティングを使用したBlue/Greenデプロイメントの例です。

graph LR
    User[ユーザー] --> R53[Route 53<br/>加重ルーティング]
    
    R53 -->|Weight: 100| Blue[Blue環境<br/>現行バージョン]
    R53 -->|Weight: 0| Green[Green環境<br/>新バージョン]

デプロイメント手順は以下のとおりです。

グローバル展開構成

レイテンシールーティングを使用したグローバル展開の例です。

graph TB
    subgraph "グローバルユーザー"
        JP_User[日本ユーザー]
        US_User[米国ユーザー]
        EU_User[欧州ユーザー]
    end
    
    R53[Route 53<br/>レイテンシールーティング]
    
    JP_User --> R53
    US_User --> R53
    EU_User --> R53
    
    R53 --> Tokyo[東京リージョン<br/>ap-northeast-1]
    R53 --> Virginia[バージニア<br/>us-east-1]
    R53 --> Frankfurt[フランクフルト<br/>eu-central-1]

レイテンシールーティングにヘルスチェックを組み合わせることで、最寄りのリージョンに障害が発生した場合でも、自動的に次にレイテンシーの低いリージョンにルーティングされます。

Route 53の料金

Route 53の料金は、以下の要素で構成されています。

エイリアスレコードを使用してAWSリソース（ELB、CloudFront、S3など）にルーティングする場合、DNSクエリ料金は発生しません。

トラブルシューティング

Route 53でよく発生する問題とその対処法を紹介します。

DNS伝播の遅延

ネームサーバーの変更やレコードの更新後、変更が反映されるまで時間がかかることがあります。

ヘルスチェックの失敗

ヘルスチェックが失敗する一般的な原因と対処法を以下に示します。

Route 53のヘルスチェッカーIPアドレス範囲は、AWSのIP範囲JSONファイルで確認できます。

1
2
3

# Route 53ヘルスチェッカーのIP範囲を取得
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
  jq '.prefixes[] | select(.service=="ROUTE53_HEALTHCHECKS")'

CNAMEとエイリアスの選択ミス

Zone Apex（example.com）にCNAMEを設定しようとしてエラーになるケースがあります。

まとめ

本記事では、Amazon Route 53の基本概念から実践的な構成まで解説しました。

Route 53を使いこなすためのポイントを整理します。

• ホストゾーン: パブリックとプライベートを適切に使い分け、ドメイン管理を一元化
• エイリアスレコード: AWSリソースへのルーティングにはエイリアスレコードを使用し、コスト削減と利便性向上を実現
• ルーティングポリシー: 要件に応じて適切なポリシーを選択し、可用性・パフォーマンス・コストを最適化
• ヘルスチェック: リソースの正常性を監視し、障害時の自動フェイルオーバーを実現

Route 53は、AWSでシステムを運用する上で欠かせないサービスです。単なるDNSサービスとしてだけでなく、可用性向上やトラフィック管理のための強力なツールとして活用してください。

次回の記事では、AWS Well-Architectedフレームワークの6つの柱について解説し、本番環境で信頼性の高いアーキテクチャを構築するための考え方を学びます。

参考リンク

• Amazon Route 53 開発者ガイド
• Route 53 のルーティングポリシー
• Route 53 ヘルスチェックの作成と管理
• Route 53 料金
• DNS 用語集