Amazon Route 53 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon Route 53 は、AWS の フルマネージド DNS・ドメイン登録・ヘルスチェックサービス です。2010 年のローンチ以来、100% の可用性 SLA を誇る唯一の AWS サービスとして、グローバルなトラフィック制御の中核を担ってきました。本ドキュメントは、Route 53 の概念・ルーティングポリシー・エコシステム・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： Route 53 とは何か、DNS の基礎から学びたい方
• 開発者向け： Blue/Green デプロイ、カナリアリリースを実装したい方
• SRE / インフラ向け： マルチリージョン DR、グローバルトラフィック制御を構築したい方
• 意思決定者向け： Route 53 vs Cloudflare / Google Cloud DNS の比較検討

2026 年の Route 53 エコシステム

• Route 53 Application Recovery Controller (ARC)： Zonal Shift による可用性ゾーン単位のフェイルオーバー
• IPv6 対応の拡大： AAAA レコード、IPv6 Prefix Delegation 対応
• Terraform / CDK 統合成熟： IaC による Route 53 管理の標準化
• External-DNS for Kubernetes： K8s と Route 53 の自動同期
• Route 53 Resolver Firewall： DNS セキュリティ機能の強化
• AI ベースのトラフィック分析： CloudWatch との連携強化

目次

1. 概要
2. Route 53 が解決する課題
3. 主な特徴
4. アーキテクチャ
5. ホストゾーン
6. レコードタイプ
7. ルーティングポリシー
8. 主要ユースケース
9. ヘルスチェックとフェイルオーバー
10. Route 53 Resolver
11. Route 53 Resolver DNS Firewall
12. Application Recovery Controller (ARC)
13. DNSSEC
14. ドメイン登録
15. 他の類似ツールとの比較
16. クライアントとエコシステム
17. ベストプラクティス
18. トラブルシューティング
19. 2025-2026 最新動向
20. 学習リソース
21. 実装例・活用シーン
22. 導入ロードマップ
23. 実装チェックリスト
24. まとめ
25. 参考文献

概要

初心者向けメモ： Route 53 は「DNS サーバー」ではなく、「DNS クエリを受け取って、ルーティングポリシーに基づいて IP アドレスを返す」マネージド DNS サービスです。DNS サーバーの管理・スケーリング・可用性を AWS が 100% 保証してくれるのが最大のメリットです。Route 53 という名前は「ポート 53 が DNS のデフォルトポート」に由来します。

Route 53 の公式定義（AWS Route 53 Developer Guide）：

“Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications.”

Route 53 を選ぶ理由

なぜ Amazon Route 53 でないといけないのか？

• 100% 可用性 SLA： AWS は Route 53 に唯一 100% 可用性 SLA を提供。他の DNS サービスは 99.99% が一般的
• AWS サービス統合： ALB / CloudFront / S3 / API Gateway などの AWS リソースを Alias レコードで直接指定可能。Alias はクエリ料金無料
• 8 種類のルーティングポリシー： シンプルな負荷分散から、地理情報・レイテンシー・加重・フェイルオーバーなど複雑なトラフィック制御が可能
• ヘルスチェック連動フェイルオーバー： エンドポイント障害を自動検知して DNS レベルで切り替え。RTO 数分の DR を実現
• プライベートホストゾーン： VPC 内専用の DNS で、サービスディスカバリーを実現
• Global Accelerator との組み合わせ： L3-4 最適化（GA）と L7 DNS ルーティング（Route 53）で多層トラフィック制御

Route 53 が解決する課題

主な特徴

アーキテクチャ

初心者向けメモ： Route 53 は 3 層構造で考えると理解しやすいです。（1）ユーザーからの DNS クエリ、（2）ホストゾーンとルーティングポリシー、（3）エンドポイント（AWS リソース or オンプレ）の 3 層です。

【図1】Route 53 の全体アーキテクチャ：

graph TD
    User[ユーザーブラウザ]
    User -->|DNS クエリ: example.com| R53[Route 53 パブリックホストゾーン]
    
    R53 -->|ルーティングポリシー| RP{ルーティング判定}
    
    RP -->|Simple| A1[エンドポイント A]
    RP -->|Weighted 90%| A2[エンドポイント B]
    RP -->|Weighted 10%| A3[エンドポイント C]
    RP -->|Latency| A4[最寄りリージョン]
    RP -->|Failover| HC{ヘルスチェック}
    HC -->|Primary OK| A5[プライマリ]
    HC -->|Primary Down| A6[セカンダリ]
    
    A1 --> ALB1[ALB in us-east-1]
    A2 --> ALB2[ALB in eu-west-1]
    A3 --> ALB3[ALB in ap-northeast-1]
    A4 --> CF[CloudFront]
    A5 --> RDS1[RDS Primary]
    A6 --> RDS2[RDS Standby]
    
    subgraph VPC_Private[プライベートホストゾーン]
        PR[api.internal]
        PR -->|ECS Service Discovery| ECS1[ECS Service 1]
        PR -->|ECS Service Discovery| ECS2[ECS Service 2]
    end

Route 53 の構成要素

flowchart TB
    service["Route 53<br/>フルマネージド DNS"]
    zone["ホストゾーン<br/>パブリックホストゾーン / プライベートホストゾーン"]
    records["レコードセット<br/>A / AAAA / CNAME / MX / TXT / NS / Alias"]
    policy["ルーティングポリシー<br/>Simple / Weighted / Latency / Geolocation"]
    health["ヘルスチェックとフェイルオーバー<br/>HTTP / HTTPS / TCP ポーリング<br/>CloudWatch アラーム連携"]

    service --> zone --> records --> policy --> health

ホストゾーン

初心者向けメモ： ホストゾーンは「ドメイン単位の DNS 管理区域」です。example.com というドメインを AWS で管理する場合、そのホストゾーンを Route 53 に作成して、NS レコード（ネームサーバー）を登録します。

パブリックホストゾーン

インターネット全体から解決可能なドメイン。

example.com
├── A レコード
│   └── www.example.com → 203.0.113.1
├── MX レコード
│   └── example.com → mail.example.com
├── CNAME レコード
│   └── blog.example.com → example.wordpress.com
└── Alias レコード
    └── example.com → ALB（us-east-1）

料金：

• ホストゾーン作成：$0.50/月/ゾーン
• DNS クエリ：100 万クエリあたり $0.40（最初の 10 億クエリ）
• Alias レコード（AWS リソース）：無料

プライベートホストゾーン

VPC 内専用のドメイン。外部からはアクセス不可。

api.internal（プライベートホストゾーン）
├── payments.api.internal → ECS Service IP
├── inventory.api.internal → Lambda ALB IP
└── auth.api.internal → ECS Service IP

用途：

• マイクロサービス間の通信（サービスディスカバリー）
• RDS クラスタエンドポイント
• ElastiCache エンドポイント
• 内部 API

VPC 関連付け：

• 1 つのプライベートホストゾーンを複数 VPC に関連付け可能
• クロスアカウント対応（Resource Access Manager 経由）

ホストゾーン管理

レコードタイプ

初心者向けメモ： DNS レコードタイプは「ドメイン名をどの情報に変換するか」を定義しています。www.example.com が何の IP アドレス・別名・メールサーバーなのか、DNS に教えるための設定です。

基本レコードタイプ

AWS 特有の Alias レコード

初心者向けメモ： Alias レコードは「Route 53 と AWS リソースの特別な連携」です。通常の A/CNAME レコードとは異なり、AWS リソース（ALB、CloudFront など）を DNS ターゲットに直接指定でき、そのリソースの IP が変わると Route 53 が自動で追従します。Alias レコードへのクエリは課金されません。

Alias の利点：

✅ IP アドレス管理不要（AWS がリソース IP を自動管理） ✅ クエリ無料（通常の A / CNAME レコードはクエリ課金） ✅ ゾーン頂点（example.com）でも使用可能（CNAME は不可） ✅ リソース削除時に自動的に無効化検出

Alias と CNAME の比較：

ルーティングポリシー

初心者向けメモ： ルーティングポリシーは「DNS クエリに対して、複数のエンドポイントから どれを返すか を決める ルール」です。同じドメインでも、クライアント位置、エンドポイント健全性、ユーザーのセッション ID など、様々な要因に基づいて異なる IP を返すことで、トラフィック制御を実現します。

1. シンプルルーティング（Simple）

1 つのリソースに対する単純なマッピング。複数値の場合、Route 53 がランダムに 1 つ返します。

• www.example.com → 203.0.113.1（常にこれを返す）

ユースケース：

• 単一エンドポイント
• テスト環境
• 開発環境

注意： ❌ ヘルスチェック非対応。プロダクション環境では推奨されません。

2. 加重ルーティング（Weighted）

複数リソースに対して、重みの比率でトラフィックを分配。Blue/Green デプロイ・カナリアリリース・A/B テストで活用。

www.example.com
├── 重み 90 → v1 エンドポイント（v1-lb.example.com）← 90% のトラフィック
└── 重み 10 → v2 エンドポイント（v2-lb.example.com）← 10% のトラフィック

段階的デプロイの例：

ユースケース：

• Blue/Green デプロイ
• カナリアリリース
• A/B テスト
• 段階的マイグレーション

3. レイテンシーベースルーティング（Latency）

ユーザーと AWS リージョン間のレイテンシーが最小のエンドポイントにルーティング。グローバル展開で使用。

www.example.com
├── us-east-1 リージョンのエンドポイント
├── eu-west-1 リージョンのエンドポイント
└── ap-northeast-1 リージョンのエンドポイント
    ↓
ユーザーのレイテンシー最小のリージョンに自動ルーティング

Route 53 の測定方法：

• ユーザーから Route 53 エッジロケーションへのレイテンシー
• エッジロケーションからリージョン間のレイテンシー（事前計測）

ユースケース：

• グローバル Web アプリケーション
• マルチリージョン SaaS
• ゲーム（低レイテンシー要求）

注意： ✅ ヘルスチェックと組み合わせて、障害リージョンを除外可能。

4. 地理情報ルーティング（Geolocation）

ユーザーの地理的位置（国、州、大陸）に基づいてルーティング。

www.example.com
├── 日本（jp） → ap-northeast-1 エンドポイント
├── EU → eu-west-1 エンドポイント
├── 米国（us） → us-east-1 エンドポイント
└── Default → us-east-1 エンドポイント（その他の地域）

ユースケース：

• データレジデンシー要件（EU は GDPR で欧州内に保存必須）
• 地域別コンテンツ配信（多言語）
• 地域別価格設定（ジオブロッキング）
• 規制要件への対応

Route 53 の地理情報判定：

• ユーザー IP のジオロケーション DB を使用
• 精度：国単位、州単位（米国）、大陸単位で対応

5. 地理的近接性ルーティング（Geoproximity）

ユーザーとリソースの距離 + バイアス値で、最適なエンドポイントを決定。より細かい制御が可能。

www.example.com
├── us-east-1（バイアス：0）
├── eu-west-1（バイアス：+10）← EU を優先
└── ap-northeast-1（バイアス：-10）← APAC を抑制

バイアス値の使い方：

• 正のバイアス（+）： その地域へのトラフィックを増加
• 負のバイアス（-）： その地域へのトラフィックを減少

ユースケース：

• 複雑なグローバルトラフィック最適化
• 特定リージョンの容量制御
• リソース配置に応じた動的ルーティング

6. フェイルオーバールーティング（Failover）

プライマリエンドポイントが健全な場合はそれを使用。障害を検知した場合、セカンダリへ自動切り替え。

www.example.com
├── Primary（ヘルスチェック OK）→ us-east-1 RDS
└── Secondary（フェイルオーバー先）→ eu-west-1 RDS Read Replica

障害検知 → 自動的に Secondary に切り替え

フェイルオーバーの流れ：

sequenceDiagram
    participant Route53 as Route 53 ヘルスチェッカー
    participant Primary as Primary エンドポイント
    participant Secondary as Secondary エンドポイント
    participant Client as クライアント

    Route53 ->> Primary: HTTP ヘルスチェック
    Primary -->> Route53: 200 OK
    Route53 ->> Client: Primary IP を返す
    
    Note over Route53: Primary が障害を起こす...
    
    Route53 ->> Primary: HTTP ヘルスチェック
    Primary --X Route53: 接続タイムアウト
    Route53 ->> Secondary: ヘルスチェック
    Secondary -->> Route53: 200 OK
    Route53 ->> Client: Secondary IP を返す（自動切り替え）

RTO（復旧時間目標）：

• ヘルスチェック間隔：30 秒（標準） or 10 秒（高速）
• DNS TTL：通常 60 秒
• 総 RTO：約 1-2 分

ユースケース：

• アクティブ/スタンバイ DR
• マルチリージョン High Availability
• 定期メンテナンス対応

7. 複数値回答ルーティング（Multivalue）

シンプルルーティングとフェイルオーバーの中間。最大 8 つの正常なエンドポイントをランダムに返します。

www.example.com
├── エンドポイント A（ヘルスチェック OK）
├── エンドポイント B（ヘルスチェック OK）
├── エンドポイント C（ヘルスチェック NG）← 返却対象外
└── エンドポイント D（ヘルスチェック OK）

返却値：A, B, D からランダムに複数個返す（最大 8 個）

ユースケース：

• 複数リージョンの負荷分散（レイテンシー非考慮）
• シンプルな冗長化
• ヘルスチェック対応の負荷分散

⚠️ 注意： Multivalue は「複数値の IP を返す」が、実際のクライアント負荷分散は OS/ブラウザが行います。より細かい制御が必要な場合は ALB/NLB を推奨。

8. IP ベースルーティング（IP-based）

クライアントの IP アドレスに基づいてルーティング。ISP 別、企業内ネットワーク別に制御。

www.example.com
├── CIDR 203.0.113.0/24（特定 ISP）→ 専用エンドポイント
├── CIDR 198.51.100.0/24（別 ISP）→ 別エンドポイント
└── Default → デフォルトエンドポイント

ユースケース：

• ISP 別パフォーマンス最適化
• 企業内 VPN からの専用ルート
• 不正検知・DDoS 対策

主要ユースケース（10+）

初心者向けメモ： Route 53 は「DNS」という基盤機能だからこそ、様々なユースケースが存在します。自分の業務にどのユースケースが当てはまるか、チェックしましょう。

1. マルチリージョン高可用性（HA）

複数リージョンにアプリケーションをデプロイし、Route 53 のフェイルオーバー + ヘルスチェックで自動切り替え。

アーキテクチャ：

Route 53（Failover ポリシー）
├── Primary: us-east-1
│   ├── ALB
│   ├── ECS
│   └── RDS（Multi-AZ）
└── Secondary: eu-west-1
    ├── ALB
    ├── ECS
    └── RDS Read Replica（同期レプリケーション）

達成する SLA：

• RTO：1-2 分（ヘルスチェック + DNS TTL）
• RPO：ほぼ 0（同期レプリケーション）
• 可用性：99.99%（ヘルスチェック精度に依存）

2. Blue/Green デプロイ（段階的）

加重ルーティングで、トラフィックを段階的に新バージョンに切り替え。

デプロイプロセス：

Day 1: Blue 100%, Green 0%
  ↓
Day 2: Blue 80%, Green 20%（メトリクス監視）
  ↓
Day 3: Blue 50%, Green 50%（全ユーザーへの影響確認）
  ↓
Day 4: Blue 0%, Green 100%（完全切り替え）

実装例（Terraform）：

resource "aws_route53_record" "app" {
  zone_id = aws_route53_zone.example.zone_id
  name    = "app.example.com"
  type    = "A"
  
  weighted_routing_policy {
    weight = 90
  }
  set_identifier = "blue"
  alias {
    name                   = aws_lb.blue.dns_name
    zone_id                = aws_lb.blue.zone_id
    evaluate_target_health = true
  }
}

resource "aws_route53_record" "app_green" {
  zone_id = aws_route53_zone.example.zone_id
  name    = "app.example.com"
  type    = "A"
  
  weighted_routing_policy {
    weight = 10
  }
  set_identifier = "green"
  alias {
    name                   = aws_lb.green.dns_name
    zone_id                = aws_lb.green.zone_id
    evaluate_target_health = true
  }
}

3. カナリアリリース

新機能を少数ユーザーで検証してから本番展開。Route 53 の加重ルーティング + CloudWatch メトリクスで監視。

メトリクス監視項目：

• エラーレート（目標：0.1% 未満）
• レイテンシ（P99 < 500ms）
• コンバージョン率
• ユーザー満足度

4. マルチリージョン DR（災害対策）

地理的に離れた複数リージョンで冗長化。一方が全滅しても他方で継続。

シナリオ：

Primary: us-east-1（ビジニス中心地）
Secondary: ca-central-1（地理的に離隔）

条件：
- Cross-region RDS replication（同期）
- 定期的なフェイルオーバードリル
- 対応時間 SLA：1 時間以内

5. グローバルアクセス最適化（レイテンシー）

ユーザーを地理的に最寄りのリージョンに自動ルーティング。グローバル SaaS で必須。

利点： ✅ ユーザー体験向上（低レイテンシ） ✅ キャッシュヒット率向上（CDN / ElastiCache） ✅ グローバル規模の対応

6. 内部 DNS（VPC プライベートホストゾーン）

マイクロサービス間で、IP アドレスをハードコードせず、ドメイン名で通信。サービスディスカバリー実現。

設定例：

プライベートホストゾーン: api.internal（VPC に関連付け）

レコード設定：
- payments.api.internal → ECS Service（自動スケール）
- inventory.api.internal → Lambda ALB
- auth.api.internal → Fargate Service

メリット：
- Service のスケール時に DNS が自動追従
- ロードバランサーより軽量
- CloudMap 連携で自動登録可能

7. CI/CD パイプラインのステージング分離

dev / staging / prod を異なるリージョン/アカウントにデプロイ。Route 53 プライベートホストゾーンで各ステージへのアクセスを制御。

8. IoT デバイスの地理的分散

IoT デバイスをリージョン別に分散デプロイ。デバイスが接続時に最寄りのエンドポイントに自動接続。

9. アクティブ/アクティブ構成

複数リージョンで同時に処理。コスト効率化と HA を両立。加重ルーティング（50%/50%）+ フェイルオーバー（ヘルスチェック）で実装。

10. コンプライアンス・データレジデンシー

GDPR（EU）、PII（日本）など、地域別の規制要件に対応。地理情報ルーティングで各地域のデータセンターに自動ルーティング。

• 地理情報ルーティング設定：
• EU ユーザー → eu-west-1（GDPR 対応）
• 日本ユーザー → ap-northeast-1（個人情報保護方針対応）
• デフォルト → us-east-1

ヘルスチェックとフェイルオーバー

初心者向けメモ： ヘルスチェックなしのフェイルオーバーは「盲目的な切り替え」です。Route 53 が実際にエンドポイントが健全か確認してから切り替えるのが、自動 DR の要です。

ヘルスチェックの種類

1. エンドポイントヘルスチェック

HTTP/HTTPS/TCP で定期的にエンドポイントをポーリング。

HTTP/HTTPS チェック：
- 対象 URL：http://example.com:80/health
- 期待ステータス：200-299
- チェック間隔：30 秒（標準） or 10 秒（高速）
- 失敗判定：3 連続失敗で unhealthy

TCP チェック：
- 対象ポート：443 など
- 接続確立で healthy と判定

2. 計算済みヘルスチェック

複数ヘルスチェックの AND / OR / NOT 組み合わせ。

Calculated Health Check（例：Blue/Green）
├── Blue ALB ヘルスチェック
├── Blue RDS ヘルスチェック
└── Blue キャッシュ ヘルスチェック
    ↓
全て healthy な場合のみ Blue が healthy と判定

3. CloudWatch アラームベース

CloudWatch メトリクスの閾値に基づくヘルスチェック。カスタムメトリクス対応。

• CloudWatch Alarm → Route 53 Health Check → フェイルオーバー
• 例：CPU 使用率が 90% を超えたら unhealthy と判定

フェイルオーバー動作

graph TD
    R53[Route 53 ヘルスチェッカー]
    R53 -->|Primary チェック| HC1{Primary<br/>Healthy?}
    HC1 -->|YES| Return1[クライアントに Primary IP を返す]
    HC1 -->|NO| HC2{Secondary<br/>Healthy?}
    HC2 -->|YES| Return2[クライアントに Secondary IP を返す]
    HC2 -->|NO| Return3[フェイルオーバーできず<br/>DNS エラー]
    
    Return1 --> Client1[クライアント]
    Return2 --> Client2[クライアント]
    Return3 --> Client3[クライアント]

ヘルスチェック設定のベストプラクティス

Route 53 Resolver

初心者向けメモ： Route 53 Resolver は「VPC 内の DNS 解決エンジン」です。すべての EC2 インスタンス・ECS・Lambda は自動的に VPC の Route 53 Resolver（169.254.169.253）を使用しており、ユーザーが明示的に設定する必要はありません。重要なのは、オンプレミスとの DNS 統合（Hybrid DNS）です。

VPC 内 DNS 解決フロー

EC2 インスタンス → Route 53 Resolver（169.254.169.253）
                       ↓
                 ┌──────────────────────────┐
                 │ AWS ドメイン？            │
                 │ (example.internal 等)   │
                 └──────────────────────────┘
                 YES ↓              NO ↓
            プライベート         パブリック DNS
            ホストゾーン         （Route 53 public）
            で解決                 or 再帰リゾルバ

Resolver Endpoints

Inbound Endpoint： オンプレミスから AWS の VPC ドメインを解決

オンプレミス DNS サーバー
    ↓
Route 53 Resolver Inbound Endpoint（ENI）
    ↓
プライベートホストゾーン（例：api.internal）
    ↓
オンプレミスのサーバーが AWS リソースに接続可能

Outbound Endpoint： AWS VPC からオンプレミスのドメインを解決

VPC 内リソース（EC2 / Lambda）
    ↓
Route 53 Resolver Outbound Endpoint
    ↓
Resolver Rule（転送ルール）
    ↓
オンプレミス DNS サーバー
    ↓
オンプレミスドメイン解決

Hybrid DNS の実装例：

# Outbound Endpoint
resource "aws_route53_resolver_endpoint" "outbound" {
  name            = "on-prem-resolver"
  direction       = "OUTBOUND"
  security_groups = [aws_security_group.resolver.id]
  
  ip_address {
    subnet_id = aws_subnet.private_1.id
  }
  ip_address {
    subnet_id = aws_subnet.private_2.id
  }
}

# オンプレミスドメイン転送ルール
resource "aws_route53_resolver_rule" "on_prem" {
  name            = "on-prem-rule"
  domain_name     = "corp.internal"
  rule_type       = "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id
  
  target_ip {
    ip = "192.168.1.10"  # オンプレミス DNS
  }
}

# 関連付け
resource "aws_route53_resolver_rule_association" "on_prem_vpc" {
  resolver_rule_id = aws_route53_resolver_rule.on_prem.id
  vpc_id           = aws_vpc.main.id
}

Route 53 Resolver DNS Firewall

初心者向けメモ： Route 53 Resolver DNS Firewall は「VPC レベルの DNS フィルタリング」です。悪意あるドメイン（マルウェア、フィッシング）への DNS クエリをブロック。

機能

VPC 内 DNS クエリ
    ↓
┌─────────────────────────────────────┐
│ Route 53 Resolver DNS Firewall      │
│ ├─ Domain List（ブロックリスト）   │
│ ├─ Alert リスト                     │
│ └─ Alexa Top 1M サイト許可          │
└─────────────────────────────────────┘
    ↓
┌────────────────────────────────────┐
│ アクション                         │
├─ Allow：クエリ許可                │
├─ Block：クエリブロック            │
├─ Alert：CloudWatch ログに記録     │
└────────────────────────────────────┘

実装例

resource "aws_route53_resolver_firewall_domain_list" "malware" {
  name = "malware-domains"
  domains = [
    "malware-c2.example.com",
    "phishing.example.com",
    "ransomware.example.com"
  ]
}

resource "aws_route53_resolver_firewall_rule_group" "security" {
  name            = "security-rules"
  share_status    = "OWNED"
}

resource "aws_route53_resolver_firewall_rule" "block_malware" {
  name                    = "block-malware"
  action                  = "BLOCK"
  firewall_domain_list_id = aws_route53_resolver_firewall_domain_list.malware.id
  firewall_rule_group_id  = aws_route53_resolver_firewall_rule_group.security.id
  priority                = 100
  block_response          = "NXDOMAIN"  # NXDOMAIN / NODATA
}

resource "aws_route53_resolver_firewall_rule_group_association" "vpc" {
  name                   = "firewall-vpc"
  firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.security.id
  vpc_id                 = aws_vpc.main.id
}

Application Recovery Controller (ARC)

初心者向けメモ： ARC（旧 Route 53 ARC）は「可用性ゾーン単位の細かいコントロール」を提供します。リージョン障害ではなく、AZ 障害に対応する必要がある場合に使用。

Zonal Shift

可用性ゾーン（AZ）の障害時、そのゾーンからトラフィックを即座に移行。

東日本リージョン（ap-northeast-1）
├── AZ: ap-northeast-1a → 健全
├── AZ: ap-northeast-1b → 障害検知
└── AZ: ap-northeast-1c → 健全

アクション：
Zonal Shift で ap-northeast-1b を一時的に除外

Readiness Checks

設定したリソース群が実際に動作するか、定期的にチェック。

resource "aws_route53recoveryreadiness_readiness_check" "app" {
  name = "app-readiness"
  resources = [
    aws_lb.main.arn,
    aws_rds_cluster.main.arn
  ]
}

DNSSEC

初心者向けメモ： DNSSEC は「DNS 応答の改ざん防止」です。中間者攻撃で DNS 応答が改ざんされないように、Route 53 が KMS キーで署名。

動作

正規な DNS クエリ応答：
   Route 53 → KMS キーで RRSIG（署名）を生成
            ↓
        DNSKEY + RRSIG をクライアントに返送
            ↓
        クライアントが署名を検証

実装例

resource "aws_route53_key_signing_key" "example" {
  hosted_zone_id             = aws_route53_zone.example.zone_id
  key_management_service_arn = aws_kms_key.dnssec.arn
  name                       = "example-ksk"
  status                     = "ACTIVE"
}

resource "aws_route53_dnssec" "example" {
  hosted_zone_id = aws_route53_zone.example.zone_id
}

料金： $0.10/月/署名ゾーン

ドメイン登録

初心者向けメモ： Route 53 でドメイン登録できます。別のレジストラ（GoDaddy など）で購入したドメインの NS レコードを Route 53 に向けることも可能。

Route 53 でのドメイン購入

1. Route 53 コンソール → "Domain Names"
2. "Register Domain" を選択
3. 希望ドメイン名を検索
4. レジストラとして Route 53 を選択
5. WHOIS 情報登録（プライバシー保護オプション付き）
6. 自動更新設定

料金例

他レジストラからの移管

1. 現在のレジストラで unlock
2. Route 53 で "Transfer Domain"
3. Authorization Code 入力
4. Route 53 がホストゾーンを自動作成
5. NS レコードが Route 53 のネームサーバーに自動設定

他の類似ツールとの比較

比較表（AWS ユーザー向け）

クライアントとエコシステム

AWS CLI / SDK

# CLI で Route 53 操作
aws route53 list-hosted-zones
aws route53 list-resource-record-sets --hosted-zone-id Z123ABC
aws route53 change-resource-record-sets --hosted-zone-id Z123ABC \
  --change-batch file://changes.json

Terraform

provider "aws" {
  region = "us-east-1"
}

# ホストゾーン作成
resource "aws_route53_zone" "main" {
  name = "example.com"
  tags = {
    Environment = "production"
  }
}

# A レコード（Alias）
resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www.example.com"
  type    = "A"
  
  alias {
    name                   = aws_lb.main.dns_name
    zone_id                = aws_lb.main.zone_id
    evaluate_target_health = true
  }
}

# MX レコード
resource "aws_route53_record" "mx" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "MX"
  ttl     = 3600
  records = ["10 mail.example.com"]
}

# TXT レコード（SPF）
resource "aws_route53_record" "spf" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "TXT"
  ttl     = 3600
  records = ["v=spf1 include:aws.amazon.com ~all"]
}

AWS CDK

import { aws_route53, aws_elasticloadbalancingv2 } from 'aws-cdk-lib';

const zone = new aws_route53.HostedZone(this, 'HostedZone', {
  zoneName: 'example.com',
});

const alb = new aws_elasticloadbalancingv2.ApplicationLoadBalancer(
  this,
  'ALB'
);

new aws_route53.ARecord(this, 'WWWRecord', {
  zone,
  target: aws_route53.RecordTarget.fromAlias(
    new aws_route53_targets.LoadBalancerTarget(alb)
  ),
  recordName: 'www',
});

External-DNS for Kubernetes

Kubernetes の Ingress / Service を Route 53 に自動登録。

# Helm values.yaml
externalDns:
  provider: aws
  policy: sync
  registry: txt
  domainFilters:
    - example.com
  aws:
    region: ap-northeast-1
    zoneType: public
    iamRoleArn: arn:aws:iam::ACCOUNT:role/external-dns

ベストプラクティス

❌ アンチパターン

トラブルシューティング

DNS 解決確認ツール

# dig（Linux / Mac）
dig www.example.com

# nslookup（Windows / Mac / Linux）
nslookup www.example.com

# host（Linux）
host www.example.com

# Route 53 specific queries
dig www.example.com +short
dig www.example.com MX
dig www.example.com TXT

CloudWatch Reachability

Route 53 の Reachability ツールで、複数リージョンからのアクセス確認。

• コンソール → Route 53 → Reachability →
• 各リージョンから実際に接続テスト

Query Logging

resource "aws_cloudwatch_log_group" "route53" {
  name              = "/aws/route53/example.com"
  retention_in_days = 7
}

resource "aws_route53_query_log" "example" {
  zone_id                  = aws_route53_zone.example.zone_id
  cloudwatch_log_group_arn = "${aws_cloudwatch_log_group.route53.arn}:*"
}

2025-2026 最新動向

1. IPv6 普及加速

• AAAA レコードの標準化
• IPv6 Prefix Delegation 対応拡大
• デュアルスタック必須化

2. ARC Zonal Shift 成熟

• 可用性ゾーン障害への自動対応
• CloudWatch との連携強化

3. Resolver DNS Firewall 高度化

• AI による脅威検知
• 自動ブロックリスト更新

4. IaC 統合の標準化

• Terraform Module の充実
• CDK による宣言的管理

5. Kubernetes ネイティブ対応

• External-DNS の標準化
• Service Mesh との連携

学習リソース

公式ドキュメント

✅ What is Amazon Route 53 ✅ Route 53 API Reference ✅ Route 53 Pricing ✅ Route 53 Best Practices ✅ Application Recovery Controller ✅ Route 53 Resolver DNS Firewall

ハンズオン・サンプル

✅ AWS-DNS-Workshop ✅ Route 53 Terraform Examples ✅ AWS Well-Architected マルチリージョンパターン

実装例・活用シーン

シーン 1：SaaS 企業のグローバル展開

例：例えば CRM SaaS が日本、シンガポール、米国に展開

Route 53 設定：
- Geolocation ルーティング
  - 日本ユーザー → ap-northeast-1
  - APAC ユーザー → ap-southeast-1
  - 北米ユーザー → us-east-1
  
- Failover ポリシー（リージョン内 HA）
  - Primary：Multi-AZ RDS
  - Secondary：別リージョン Read Replica
  
- Health Check：毎 30 秒 ALB エンドポイント確認
  - 障害 → 自動切り替え（RTO 1-2 分）
  
メリット：
- グローバルユーザーに低レイテンシ提供
- リージョン障害時も数分で復旧

シーン 2：e-コマース のカナリアリリース

例：新決済システム（v2）をリリース

Week 1: Weighted 99% (v1) / 1% (v2)
  → エラーレート、パフォーマンス監視

Week 2: Weighted 90% / 10%
  → ユーザーからのフィードバック収集

Week 3: Weighted 50% / 50%
  → 全機能の並行テスト

Week 4: Weighted 0% / 100%
  → 完全切り替え

Route 53 設定：
- 加重ルーティング + Alias（ALB）
- CloudWatch メトリクス監視

シーン 3：オンプレ + AWS ハイブリッド

例：企業が段階的にクラウド移行

Route 53 Resolver 設定：

【Outbound Endpoint】
VPC → オンプレ DNS → corp.internal ドメイン解決

【Inbound Endpoint】
オンプレ DNS → VPC → api.internal（ECS Service）

メリット：
- IP ハードコード不要
- 段階的マイグレーション対応
- 既存システムとの互換性維持

導入ロードマップ

Phase 1：基礎構築（1-2 週間）

• [ ] Route 53 ホストゾーン作成
• [ ] 基本レコード設定（A、MX、TXT）
• [ ] Alias レコード（AWS リソース向け）
• [ ] CloudWatch Query Logging 設定
• [ ] ドメイン registrar を Route 53 に更新

Phase 2：HA 化（2-4 週間）

• [ ] 複数リージョンのリソース構築
• [ ] Route 53 ヘルスチェック設定
• [ ] Failover ポリシー実装
• [ ] フェイルオーバードリル実施

Phase 3：グローバル最適化（4-8 週間）

• [ ] Latency / Geolocation ルーティング設定
• [ ] CloudFront / Global Accelerator 統合
• [ ] ユーザーレイテンシ測定・最適化
• [ ] キャッシュヒット率改善

Phase 4：セキュリティ・コンプライアンス（8-12 週間）

• [ ] DNSSEC 有効化
• [ ] Route 53 Resolver Firewall 設定
• [ ] Query Logging 分析・アラート設定
• [ ] IAM ポリシー最小権限化
• [ ] 定期監査・ドリル

Phase 5：IaC 化・自動化（12+週間）

• [ ] Terraform で Route 53 管理
• [ ] GitOps ワークフロー構築
• [ ] Kubernetes + External-DNS 統合
• [ ] CI/CD パイプライン自動化

実装チェックリスト

設計フェーズ

• [ ] ドメイン構成（apex / subdomain）を定義
• [ ] ホストゾーン種類（public / private）を決定
• [ ] ルーティングポリシーを選択
• [ ] SLA 目標を定義（RTO / RPO）
• [ ] 監視・アラート戦略を決定

実装フェーズ

• [ ] ホストゾーンを作成
• [ ] ネームサーバーを registrar に登録
• [ ] レコードを作成（A / AAAA / CNAME / MX / TXT / NS）
• [ ] Alias レコード（AWS リソース）を確認
• [ ] ヘルスチェックを設定
• [ ] DNS 解決を確認（dig / nslookup）

テストフェーズ

• [ ] TTL を短縮してレコード変更を確認
• [ ] フェイルオーバーを手動トリガーして動作確認
• [ ] 複数リージョンからの接続確認
• [ ] ヘルスチェック失敗時の動作確認
• [ ] Query Logging で DNS クエリを確認

本番運用フェーズ

• [ ] CloudWatch アラーム設定
• [ ] Query Logging 分析
• [ ] 定期的なドリル実施（毎月 1 回）
• [ ] 障害回対応プロセス構築
• [ ] 定期監査（毎四半期）

まとめ

Route 53 は 「100% SLA の DNS + ルーティングポリシーによるトラフィック制御基盤」 です。8 種類のルーティングポリシーでカナリアデプロイ・DR フェイルオーバー・グローバルレイテンシー最適化を実現。Alias レコードで AWS リソースへのクエリコストをゼロに。Resolver Endpoints でオンプレとのハイブリッド DNS 解決を統合。

重要なポイント：

✅ Alias レコードは必須： AWS リソース向けは Alias で、クエリ課金を回避 ✅ ヘルスチェック + フェイルオーバーで自動 DR： RTO 1-2 分の復旧を実現 ✅ ルーティングポリシーで複雑なトラフィック制御： Blue/Green / カナリア / 地理情報 ✅ Hybrid DNS で統合運用： オンプレ ↔ AWS シームレス連携 ✅ IaC で宣言的管理： Terraform / CDK で版管理・自動化

Route 53 を使いこなすことで、スケーラブルで高可用性のグローバルインフラを構築できます。

参考文献

• AWS Route 53 Documentation
• AWS Route 53 API Reference
• AWS Route 53 Pricing
• Route 53 Accelerated Recovery - 2026
• Application Recovery Controller - Zonal Shift Best Practices
• AWS Well-Architected Framework - Operational Excellence
• DNS & BIND 5th Edition (参考書籍)
• Terraform AWS Route53 Module
• AWS CDK Route53 Constructs
• AWS-DNS-Workshop GitHub
• Route 53 Resolver DNS Firewall Documentation
• RFC 4033 - DNSSEC Protocol
• Mozilla MDN - DNS

最終更新：2026-04-26