サブドメインのNS委譲 — 別AWSアカウントにDNS管理を移す最小コスト設計

AWSアカウント分離でstaging環境を別アカウントに移す際、サブドメイン（例: stg.example.com）のDNS管理をどう扱うかで設計の複雑さが大きく変わる。

問題: 親ゾーンが本番アカウントにある

example.com のRoute53ホステッドゾーンが本番アカウントに存在する場合、staging用のDNSレコードを追加するたびに本番アカウントを操作することになる。

NS委譲 vs 親ゾーン直接追加

操作	NS委譲	親ゾーン直接追加
ALB Aliasレコード	新アカウントのゾーンで管理	親ゾーン（本番アカウント）を毎回触る
ACM検証CNAME	新アカウントのゾーンで管理	親ゾーンを触る
SES DKIM CNAME	新アカウントのゾーンで管理	親ゾーンを触る
将来の追加レコード	新アカウント内で完結	親ゾーンを触る都度
親ゾーンへの変更	NSレコード追加1回だけ	変更のたびに必要

本番アカウントへの接触機会が増えるほど、オペレーションミスのリスクが上がる。NS委譲なら 初回のNSレコード追加1回だけ で以降は新アカウントに完全委譲できる。

手順

Step 1: 新アカウントに子ゾーンを作成

aws route53 create-hosted-zone \
  --name "stg.example.com" \
  --caller-reference "$(date +%s)" \
  --profile new-account

レスポンスの NameServers（4件）をメモする。

Step 2: 親ゾーンにNSレコードを追加（これだけ本番アカウントを触る）

{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "stg.example.com",
      "Type": "NS",
      "TTL": 300,
      "ResourceRecords": [
        {"Value": "ns-xxx.awsdns-xx.com."},
        {"Value": "ns-xxx.awsdns-xx.net."},
        {"Value": "ns-xxx.awsdns-xx.org."},
        {"Value": "ns-xxx.awsdns-xx.co.uk."}
      ]
    }
  }]
}

Step 3: 以降はすべて新アカウントのゾーンで管理

# 新アカウントのTerraformで完結する
resource "aws_route53_record" "alb" {
  zone_id = aws_route53_zone.stg.zone_id
  name    = "stg.example.com"
  type    = "A"
  alias { ... }
}

resource "aws_route53_record" "ses_dkim" {
  zone_id = aws_route53_zone.stg.zone_id
  name    = "xxx._domainkey.stg.example.com"
  type    = "CNAME"
  records = ["xxx.dkim.amazonses.com"]
  ttl     = 300
}

SESのDNS認証も子ゾーン内に収められる

SESのdomain identityを stg.example.com で作成すると、DKIM検証CNAMEが stg.example.com 配下に生成される。

xxx._domainkey.stg.example.com CNAME → xxx.dkim.amazonses.com
_amazonses.stg.example.com TXT → 検証トークン

これらはすべて委譲ゾーン内に収まるため、本番アカウントへの追加操作が不要になる。

トレードオフとして 送信元アドレスのドメインが変わる（@stg.example.com）が、staging環境では許容できることが多い。

動作確認コマンド

# NSレコードが委譲されているか確認
dig stg.example.com NS

# 名前解決のトレースで委譲パスを確認
dig +trace stg.example.com A

委譲が正しく機能していれば、dig +trace の出力に新アカウントのNSサーバーが表示される。