2026年6月8日
2026年6月8日
Route 53 で複数ドメインを管理する方法|ホストゾーンの棚卸し・権限の分け方・一括バックアップ
Route 53 で複数のドメインを管理するときは、「1ドメイン1ホストゾーン」を守り、タグで用途と担当を記録し、IAM でホストゾーンごとに編集できる人を分け、AWS CLI で定期的に全ゾーンを書き出す、という4つを仕組みにすると運用が安定します。この記事では、1つの AWS アカウントで数十件のドメインを扱う場面を想定し、重複したホストゾーンの見つけ方、権限の分け方、バックアップと一括確認の方法を、コマンド例とあわせて説明します。
Route 53 の画面構成、サービスの上限値、機能の提供範囲は変わることがあります(2026年10月現在)。コマンドは例として示すので、自分の環境に合わせて書き換え、変更系の操作は検証用のドメインで試してから本番に使ってください。料金は扱いません。
前提:ドメインの登録とホストゾーンは別のもの
Route 53 には、ドメインを登録・更新する「Route 53 Domains」と、DNS のレコードを置く「ホストゾーン」があります。Route 53 でドメインを登録すると同名のホストゾーンが自動で作られることが多いですが、両者は別の資源です。他社で登録したドメインのホストゾーンだけを Route 53 に置くこともできます。
複数ドメインの管理では、この2つを分けて考えます。
- 登録側: 更新期限、自動更新、連絡先、移管ロック、そしてネームサーバーの指定
- DNS 側: ホストゾーンとその中のレコード
ホストゾーンのレコードが使われるのは、登録側(レジストラ)でそのホストゾーンのネームサーバーが指定されている場合だけです。
手順1:全ホストゾーンを一覧にする
まず、アカウント内のホストゾーンを一覧にします。
aws route53 list-hosted-zones \
--query 'HostedZones[].[Id,Name,Config.PrivateZone,ResourceRecordSetCount]' \
--output text
ID、ドメイン名、プライベートゾーンかどうか、レコード数が並びます。ここで同じドメイン名が2回以上出てきたら、重複したホストゾーンがあるということです。
重複したホストゾーンを見つける
Route 53 では、同じドメイン名のホストゾーンを複数作れてしまいます。作業のやり直しや、Terraform などのツールと手作業の混在でよく起きます。ホストゾーンごとに割り当てられるネームサーバーは異なるため、インターネットから使われているのは、レジストラに登録されたネームサーバーを持つ1つだけです。もう一方を編集しても何も変わりません。
どのホストゾーンが実際に使われているかは、ホストゾーンのネームサーバーと、公開 DNS で引ける NS を比べると分かります。
#!/usr/bin/env bash
# パブリックホストゾーンごとに、割り当てられた NS と実際に使われている NS を比べる
for id in $(aws route53 list-hosted-zones \
--query 'HostedZones[?Config.PrivateZone==`false`].Id' --output text); do
zid=${id##*/}
name=$(aws route53 get-hosted-zone --id "$zid" --query 'HostedZone.Name' --output text)
zone_ns=$(aws route53 get-hosted-zone --id "$zid" \
--query 'DelegationSet.NameServers' --output text | tr '\t' '\n' | sort | tr '\n' ' ')
live_ns=$(dig +short "$name" NS | sed 's/\.$//' | sort | tr '\n' ' ')
if [ "$zone_ns" = "$live_ns" ]; then
echo "使用中 $zid $name"
else
echo "未使用? $zid $name"
fi
done
「未使用?」と出たホストゾーンは、使われていない重複か、ネームサーバーの切り替えがまだのドメインです。重複だと分かっても、すぐには削除しません。中のレコードを書き出して、使用中のゾーンに足りないレコードがないかを確かめてから整理します。なお、ホストゾーンを削除するには、NS と SOA 以外のレコードを先に削除する必要があります。
新しいドメインを追加するたびに、全ドメインで同じネームサーバーを使いたい場合は、再利用可能な委任セットを作ってからホストゾーンを作る方法があります。既存のホストゾーンに後から委任セットを付け替えることはできないため、使うなら最初に決めておきます。
手順2:タグで用途と担当を記録する
ドメインが増えると、「このドメインは何に使っているのか」「誰に確認すればよいのか」が分からなくなります。ホストゾーンにはタグを付けられるので、用途や担当をゾーンそのものに記録しておきます。
aws route53 change-tags-for-resource \
--resource-type hostedzone \
--resource-id Z0123456789EXAMPLE \
--add-tags Key=Purpose,Value=wordpress-prod Key=Owner,Value=web-team
タグの名前と値は例です。組織で決めたルールに合わせます。タグを付けておくと、費用の配分や、後述する一括確認の対象の絞り込みにも使えます。
手順3:IAM でホストゾーンごとに権限を分ける
複数の部署や取引先のドメインを同じアカウントで管理していると、「このサイトの担当者は、このドメインのレコードだけを変更できるようにしたい」という要望が出ます。IAM では、ホストゾーンの ARN を指定して、変更できる範囲を絞れます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:GetHostedZone",
"route53:ListResourceRecordSets",
"route53:ChangeResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/Z0123456789EXAMPLE"
},
{
"Effect": "Allow",
"Action": [
"route53:ListHostedZones",
"route53:GetChange"
],
"Resource": "*"
}
]
}
1つ目の文で、指定したホストゾーンの参照と変更を許可しています。2つ目の文は、ゾーンの一覧表示と変更の進み具合の確認に必要なもので、ARN で絞れない操作です。
さらに細かく、変更できるレコードの名前や種類を条件キーで制限することもできます。例えば「www の A レコードだけ」「TXT は変更させない」といった制御です。使える条件キーと書き方は IAM のドキュメントで確認してください。
担当の範囲が会社や部署ごとに分かれていて、請求や監査も分けたい場合は、AWS Organizations でアカウント自体を分け、ドメインごとに置き場所を決める方法もあります。サブドメインだけを別のアカウントに任せる場合は、親のゾーンに NS レコードを置いて委任します。
手順4:全ゾーンを定期的に書き出す
Route 53 のコンソールには、ゾーンファイルを取り込む機能はありますが、全レコードを書き出す操作は CLI や API で行うのが基本です。誤ってレコードを消したときに戻せるよう、全ホストゾーンのレコードを JSON で保存しておきます。
#!/usr/bin/env bash
out="r53-backup-$(date +%Y%m%d)"
mkdir -p "$out"
for id in $(aws route53 list-hosted-zones --query 'HostedZones[].Id' --output text); do
zid=${id##*/}
name=$(aws route53 get-hosted-zone --id "$zid" --query 'HostedZone.Name' --output text)
aws route53 list-resource-record-sets --hosted-zone-id "$zid" \
--output json > "$out/${name}${zid}.json"
done
echo "saved to $out"
月に1回など決まった間隔で実行し、前回の結果と比べると、意図しない変更に気づけます。
diff -r r53-backup-20260901 r53-backup-20261001
保存した JSON には、内部向けのホスト名や IP アドレスが含まれます。保存先は関係者だけが読める場所にし、公開リポジトリには置かないでください。誰がいつ変更したかを追いたい場合は、CloudTrail で Route 53 の API 呼び出しの記録を確認できます。
複数ドメインに同じ変更を入れるとき
サーバー移転で多数のドメインの A レコードを書き換える場合は、変更内容を JSON に書いて change-resource-record-sets で適用します。UPSERT は「なければ作成、あれば置き換え」です。
cat > change.json <<'EOF'
{
"Comment": "move to new server",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "example.com.",
"Type": "A",
"TTL": 300,
"ResourceRecords": [{ "Value": "203.0.113.20" }]
}
}
]
}
EOF
aws route53 change-resource-record-sets \
--hosted-zone-id Z0123456789EXAMPLE --change-batch file://change.json
一度に全ドメインへ適用せず、影響の小さいドメインから1件ずつ進めます。返ってきた変更 ID を aws route53 get-change --id 変更ID で確認し、状態が INSYNC になってから、権威サーバーに直接問い合わせて値を確かめます。
dig +short example.com A @ns-123.awsdns-45.com
ネームサーバー名は、そのホストゾーンに割り当てられたものに置き換えます。頂点が CloudFront やロードバランサーを指すエイリアスレコードの場合は、ResourceRecords ではなく AliasTarget を使う書き方になるので、書き換える前に既存のレコードの形を確認します。
同じ作業を繰り返すようになったら、Terraform などでドメインの一覧から全ゾーンを管理する方法に移ると、変更の履歴とレビューを残せます。
登録側の設定も定期的に見直す
Route 53 Domains でドメインを登録している場合は、ドメインごとの自動更新、連絡先、移管ロックも確認します。連絡先のメールアドレスが受信できないと、gTLD では登録者情報の確認に対応できず、ドメインが利用停止になることがあります。ドメイン数やホストゾーン数にはアカウントごとの上限があるので、件数が多い場合は Service Quotas で現在の上限を確認しておきます。
まとめ
- 登録(Route 53 Domains)とホストゾーンは別の資源です。レコードが使われるのは、レジストラに登録されたネームサーバーを持つホストゾーンだけです。
list-hosted-zonesで全ゾーンを一覧にし、ゾーンの NS と実際の NS を比べて重複を見つけます。削除はレコードを書き出してから行います。- タグで用途と担当を記録し、IAM のリソース指定でホストゾーンごとに変更できる人を分けます。
- 全ゾーンを定期的に JSON で書き出し、差分で意図しない変更に気づけるようにします。
- 一括変更は1件ずつ進め、
INSYNCを確かめてから権威サーバーで値を確認します。