AWS Route 53でDNSを設計｜ドメイン管理・ルーティング・DNSSEC実装ガイド

⚡ 3秒でわかる！この記事のポイント

Route 53はAWSのマネージドDNSサービスで、100% SLAを提供する唯一のAWSサービス
加重・レイテンシ・フェイルオーバー等のルーティングポリシーでトラフィック制御を最適化
SES案件ではDNS設計スキルの需要が高く、インフラ案件で月単価65〜85万円が目安

「DNSの設定ミスで本番サイトがダウンした」「マルチリージョン構成でのルーティングが複雑すぎる」「ドメイン移管の手順がわからない」——AWS案件に携わるSESエンジニアが頻繁に直面するDNSの課題です。

AWS Route 53は、AWSが提供する高可用性・スケーラブルなDNSウェブサービスです。名前の由来はDNSが使用するTCPポート53にちなんでいます。Route 53はAWSで唯一100% SLAを保証するサービスであり、その信頼性はDNSインフラの根幹として世界中の企業に利用されています。

本記事では、Route 53の基礎からSES案件で求められる実践的なDNS設計パターンまで体系的に解説します。

Route 53の基本概念

3つの主要機能

Route 53は以下の3つの主要機能を提供します：

1. ドメイン登録（Domain Registration）

新規ドメインの登録や他のレジストラからの移管を行います。.com、.jp、.ioなど300以上のTLDに対応しています。

2. DNSルーティング（DNS Routing）

ドメイン名をIPアドレスやAWSリソースに解決します。複数のルーティングポリシーにより、トラフィック制御を柔軟に設定できます。

3. ヘルスチェック（Health Checking）

エンドポイントの死活監視を行い、障害時に自動でトラフィックを切り替えます。

ホストゾーンとレコードタイプ

**ホストゾーン（Hosted Zone）**は、特定のドメインに属するDNSレコードの集合です：

# パブリックホストゾーンの作成
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "$(date +%s)"

主要なレコードタイプ：

レコードタイプ	用途	例
A	IPv4アドレス	`93.184.216.34`
AAAA	IPv6アドレス	`2606:2800:220:1::`
CNAME	ドメインの別名	`www.example.com → example.com`
MX	メールサーバー	`10 mail.example.com`
TXT	テキスト情報	SPF, DKIM, ドメイン検証
NS	ネームサーバー	ゾーン委任
SOA	権威情報	ゾーンのメタデータ
ALIAS	AWSリソースの別名	CloudFront, ELB, S3

ALIASレコード：Route 53の強力な独自機能

Route 53のALIASレコードは、標準DNSにはないAWS独自の機能です。CNAMEとは異なり、**Zone Apexレコード（example.com）**にも設定可能で、DNS解決のレイテンシも発生しません。

# ALB へのALIASレコード作成
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z32O12XQLNTSW2",
          "DNSName": "my-alb-123456.ap-northeast-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

ALIASレコードが使えるAWSサービス：

Elastic Load Balancing（ALB/NLB/CLB）
Amazon CloudFront
Amazon S3（静的ウェブサイトホスティング）
Amazon API Gateway
AWS Global Accelerator
同じホストゾーン内の別レコード

AWS Route 53 DNS設計パターンのインフォグラフィック

ルーティングポリシー

シンプルルーティング

最も基本的なルーティング。1つのリソースにトラフィックを送ります：

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [
          {"Value": "203.0.113.1"}
        ]
      }
    }]
  }'

加重ルーティング（Weighted Routing）

複数のリソースにトラフィックを比率で分配します。カナリアリリースに最適です：

# 本番環境: 90%
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "production",
        "Weight": 90,
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.1"}]
      }
    }]
  }'

# カナリア環境: 10%
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "canary",
        "Weight": 10,
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.2"}]
      }
    }]
  }'

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

ユーザーに最も低レイテンシで応答できるリージョンにルーティングします：

# 東京リージョン
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "ap-northeast-1",
        "Region": "ap-northeast-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.10"}]
      }
    }]
  }'

# バージニアリージョン
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1",
        "Region": "us-east-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.20"}]
      }
    }]
  }'

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

ヘルスチェックと組み合わせて、障害時に自動でDR（Disaster Recovery）サイトにフェイルオーバーします：

# プライマリ（東京）
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "TTL": 60,
        "HealthCheckId": "hc-primary-12345",
        "ResourceRecords": [{"Value": "203.0.113.1"}]
      }
    }]
  }'

# セカンダリ（大阪）
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "secondary",
        "Failover": "SECONDARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.2"}]
      }
    }]
  }'

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

Traffic Flowと組み合わせて、ユーザーの地理的位置に基づいてルーティングします。バイアス値を調整することで、特定リージョンのトラフィック配分を制御できます。

ヘルスチェック

ヘルスチェックの作成

aws route53 create-health-check \
  --caller-reference "$(date +%s)" \
  --health-check-config '{
    "IPAddress": "203.0.113.1",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "api.example.com",
    "RequestInterval": 30,
    "FailureThreshold": 3,
    "EnableSNI": true
  }'

計算式ヘルスチェック

複数のヘルスチェック結果を論理演算で組み合わせます：

# 子ヘルスチェックのうち2つ以上がhealthyならhealthyと判定
aws route53 create-health-check \
  --caller-reference "calc-$(date +%s)" \
  --health-check-config '{
    "Type": "CALCULATED",
    "ChildHealthChecks": [
      "hc-web-12345",
      "hc-api-67890",
      "hc-db-11111"
    ],
    "HealthThreshold": 2
  }'

CloudWatchアラーム連動ヘルスチェック

aws route53 create-health-check \
  --caller-reference "cw-$(date +%s)" \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {
      "Region": "ap-northeast-1",
      "Name": "HighCPUUtilization"
    },
    "InsufficientDataHealthStatus": "LastKnownStatus"
  }'

DNSSEC の実装

DNSSECとは

DNSSECは、DNS応答の真正性を暗号的に検証する仕組みです。DNSキャッシュポイズニング攻撃を防止します。

Route 53でのDNSSEC有効化手順

# 1. KMS キーの作成（us-east-1 必須）
aws kms create-key \
  --region us-east-1 \
  --description "DNSSEC signing key for example.com" \
  --key-spec ECC_NIST_P256 \
  --key-usage SIGN_VERIFY \
  --customer-master-key-spec ECC_NIST_P256

# 2. キー署名キー（KSK）の作成
aws route53 create-key-signing-key \
  --hosted-zone-id Z1234567890 \
  --key-management-service-arn "arn:aws:kms:us-east-1:123456789012:key/xxx" \
  --name "example-com-ksk" \
  --status ACTIVE

# 3. DNSSEC署名の有効化
aws route53 enable-hosted-zone-dnssec \
  --hosted-zone-id Z1234567890

# 4. DSレコードを親ゾーンに登録
# Route 53で登録したドメインの場合は自動的に設定される

DNSSEC導入時の注意点

KMSキーはus-east-1リージョンに作成する必要がある
TTLの設定に注意（RRSIG署名のTTLとの整合性）
ロールバック手順を事前に準備しておく
子ゾーン委任時のDS レコードの連鎖を確認

IaCによるRoute 53管理

CloudFormationテンプレート

AWSTemplateFormatVersion: '2010-09-09'
Description: Route 53 DNS Configuration

Resources:
  HostedZone:
    Type: AWS::Route53::HostedZone
    Properties:
      Name: example.com
      HostedZoneConfig:
        Comment: "Production hosted zone"

  WebRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZone
      Name: www.example.com
      Type: A
      AliasTarget:
        DNSName: !GetAtt CloudFrontDistribution.DomainName
        HostedZoneId: Z2FDTNDATAQYW2  # CloudFront固定値
        EvaluateTargetHealth: false

  APIRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZone
      Name: api.example.com
      Type: A
      AliasTarget:
        DNSName: !GetAtt ApplicationLoadBalancer.DNSName
        HostedZoneId: !GetAtt ApplicationLoadBalancer.CanonicalHostedZoneID
        EvaluateTargetHealth: true

  HealthCheck:
    Type: AWS::Route53::HealthCheck
    Properties:
      HealthCheckConfig:
        FullyQualifiedDomainName: api.example.com
        Port: 443
        Type: HTTPS
        ResourcePath: /health
        RequestInterval: 30
        FailureThreshold: 3
      HealthCheckTags:
        - Key: Name
          Value: API Health Check

  MXRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZone
      Name: example.com
      Type: MX
      TTL: 3600
      ResourceRecords:
        - "10 inbound-smtp.ap-northeast-1.amazonaws.com"

  SPFRecord:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZone
      Name: example.com
      Type: TXT
      TTL: 3600
      ResourceRecords:
        - '"v=spf1 include:amazonses.com ~all"'

Terraformでの管理

resource "aws_route53_zone" "main" {
  name = "example.com"
  tags = {
    Environment = "production"
  }
}

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www.example.com"
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.main.domain_name
    zone_id                = aws_cloudfront_distribution.main.hosted_zone_id
    evaluate_target_health = false
  }
}

resource "aws_route53_health_check" "api" {
  fqdn              = "api.example.com"
  port               = 443
  type               = "HTTPS"
  resource_path      = "/health"
  failure_threshold  = 3
  request_interval   = 30

  tags = {
    Name = "API Health Check"
  }
}

resource "aws_route53_record" "api_primary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.api.id
  ttl             = 60
  records         = ["203.0.113.1"]
}

実践的なDNS設計パターン

パターン1：マルチアカウント構成

AWS Organizationsでマルチアカウント運用する場合のDNS設計：

example.com (管理アカウント)
├── api.example.com      → 本番アカウントへ委任
├── staging.example.com  → ステージングアカウントへ委任
├── dev.example.com      → 開発アカウントへ委任
└── internal.example.com → プライベートホストゾーン

パターン2：Blue/Greenデプロイメント

加重ルーティングを使ったBlue/Greenデプロイの段階的切り替え：

Blue: 100% → Green: 0%（初期状態）
Blue: 90% → Green: 10%（カナリアテスト）
Blue: 50% → Green: 50%（負荷分散テスト）
Blue: 0% → Green: 100%（完全切り替え）

パターン3：プライベートDNS

VPC内部のサービスディスカバリにプライベートホストゾーンを活用：

# プライベートホストゾーンの作成
aws route53 create-hosted-zone \
  --name internal.example.com \
  --caller-reference "$(date +%s)" \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-12345

SES面談でのDNSスキルアピール

インフラ系案件で評価されるポイント

DNS設計の実務経験

ドメイン移管・ゾーン移行の経験
マルチリージョン・マルチアカウント構成のDNS設計
DNSSEC導入の実績
メール認証（SPF/DKIM/DMARC）の設定経験

障害対応・トラブルシューティング

DNS関連の障害調査手法（dig, nslookup, whois）
TTL設計のベストプラクティス
キャッシュ伝播の理解

IaCでの管理

CloudFormation / Terraform によるDNSリソース管理
CI/CDパイプラインでのDNS変更の自動化

まとめ

AWS Route 53は、DNSという基盤技術をマネージドサービスとして提供し、高可用性・柔軟なルーティング・セキュリティの三拍子を兼ね備えたサービスです。

SES案件においてDNS設計スキルは、一見地味ですがインフラ全体の信頼性を左右する重要なスキルです。Route 53の各種ルーティングポリシーやヘルスチェック、DNSSECの知識は、インフラエンジニアとしての市場価値を確実に高めてくれるでしょう。