Route 53でサブドメインだけ別アカウントへ移す方法｜親ゾーンのNS委任と切替手順

2026年10月5日

部署やシステムごとにAWSアカウントを分けるとき、example.comの管理は共通基盤に残し、sub1.example.comだけを別アカウントで管理したいことがあります。

親ドメインとサブドメインのパブリックホストゾーンは、異なるAWSアカウントで管理できます。移行先に子ゾーンを作り、親ゾーンにある委任用NSレコードを新しいネームサーバーへ変更するのが基本です。ここでは、既に子ゾーンが分かれている構成の移行を扱います。プライベートホストゾーンのVPC関連付けとは別の話です。

アカウントの境界ではなく、DNSの委任でつながる

親ゾーンは「sub1.example.com以下の問い合わせは、このネームサーバーへ」という情報をNSレコードで示します。そのネームサーバーが別AWSアカウントのRoute 53に属していても、DNSの委任は成立します。

管理対象	移行前	移行後
親ゾーン example.com	アカウントA	アカウントAに残す
子ゾーン sub1.example.com	アカウントA	アカウントBに新規作成する
親ゾーンの sub1.example.com のNS	旧子ゾーンのネームサーバー	新子ゾーンのネームサーバーへ更新する

この作業では、example.com自体のドメイン登録先や親ゾーンのネームサーバーを変更する必要はありません。ホストゾーンの所有アカウントを直接書き換えるのではなく、新しいゾーンを準備して委任先を切り替えます。

最初に、切替対象のNSを区別する

Route 53の画面には、親ゾーン自身のNS、親に置く子への委任用NS、子ゾーン自身のNSが登場します。同じNSという種類でも役割が違います。

今回変更するのは、親ゾーン内の「sub1.example.com」という名前の委任用NSレコードです。親ゾーン自身のexample.comのNSを変更すると、親ドメイン全体へ影響するため、レコード名まで確認します。

子ゾーン作成時にRoute 53が用意するゾーン頂点のNSとSOAは、その新しいゾーンの設定を維持します。旧子ゾーンのNS・SOAをそのまま上書きコピーする操作とは分けて考えてください。委任の流れは親ドメインを移行せずにサブドメインのDNSを移す公式手順で確認できます。

1. レコードを控え、移行先の子ゾーンを準備する

まず、旧子ゾーンのレコードと親の委任設定を保存します。Web用のA・AAAAだけでなく、メール用のMX、TXT、ACMのDNS検証用CNAMEなども対象です。エイリアス、ルーティングポリシー、ヘルスチェックがある場合は、その参照先も確認します。

次にアカウントBで、同じ名前のパブリックホストゾーンsub1.example.comを作ります。必要なレコードを登録し、旧ゾーンと名前・種類・値を照合します。DNSを移すだけなら、アプリケーションの接続先まで同時に変える必要はありません。変更を分けると、問題が起きた際に原因を追いやすくなります。

2. TTLを考慮して親の委任先を切り替える

キャッシュされた古いNS情報は、レコード変更と同時には消えません。TTLを短くして切替の影響時間を抑える場合は、変更前のTTLが経過する時間を見込んで準備します。切替直前にTTLだけ短くしても、既に保持された長いTTLのキャッシュは残ります。

新子ゾーンのレコードを確認した後、親ゾーンの委任用NSを、新子ゾーンに割り当てられた4つのネームサーバーへ更新します。旧・新のNSを混ぜたまま、異なる内容を返す状態にしないようにします。

Route 53側の変更が反映されることと、利用者側のDNSキャッシュが更新されることは別です。切替中は旧子ゾーンも維持し、レコード更新が必要なら新旧の内容が食い違わないよう管理します。移行準備とレコード照合の観点はホストゾーンを別AWSアカウントへ移行する公式資料も参考になります。

3. 新しい委任と実際のサービスを確認する

親ゾーンの委任用NSが、新子ゾーンのネームサーバーと一致しているか。
新子ゾーンの権威DNSへ問い合わせて、期待するレコードが返るか。
通常利用するDNSリゾルバー経由でも、必要な名前が解決できるか。
Web、メール、証明書検証など、対象の用途で動作が変わっていないか。

名前解決だけではHTTPSの証明書やアプリケーションまで正常とは判断できません。DNS切替とサービス確認を分けて実施し、旧ゾーンの削除はキャッシュと切り戻しの必要性を確認してから行います。

DNSSECを使っている場合はDSも確認する

DNSSECを有効にしている子ゾーンでは、親のDSレコードと移行先の署名設定も移行計画に含めます。旧ゾーン用のDSを残したまま署名の異なる新ゾーンへ切り替えると、検証に失敗する可能性があります。上記の公式移行資料にあるDNSSECの準備・再設定手順を確認し、NSだけを変更して完了としないでください。