Route 53のレコードは、別のAWSアカウントに作ったホストゾーンへコピーできます。また、コピー前にIPアドレスや参照先を編集することも可能です。ただし、一覧取得のJSONと、登録用のJSONは形式が異なります。エクスポートしたファイルをそのまま登録コマンドへ渡すだけでは移行できません。
この記事では、パブリックホストゾーンのレコードをAWS CLIで取り出し、必要な変更を加えて別アカウントへ登録する流れを説明します。DNSの委任先を切り替える前の「新しいゾーンに正しいレコードをそろえる」作業が中心です。
ゾーンファイルとAWS CLIのどちらを使う？
| 方法 | 向いている場面 | 確認する点 |
|---|---|---|
| ゾーンファイルのインポート | 既に標準的なゾーンファイルを持っている | Route 53にはゾーンファイル形式のエクスポート機能がない |
| AWS CLIでJSONを取得・変換 | 既存Route 53のレコードを確認しながらコピーする | 登録用の形式への変換と参照先の見直しが必要 |
| コンソールで手動作成 | レコードがごく少ない | 入力漏れ・転記ミスを照合する |
ゾーンファイルのインポートでは、Route 53固有のエイリアスレコードは作成できません。エイリアスなどを使う既存ゾーンを移すなら、CLIのJSONを基に整理すると対象を把握しやすくなります。インポートの制約は公式のゾーンファイル手順で確認できます。
1. 元のレコードを保存する
まず、移行元用と移行先用のAWS CLIプロファイルを用意します。以下の名前とゾーンIDは例なので、自分の環境に置き換えてください。コマンドはBash系シェルでの例です。
aws route53 list-resource-record-sets --profile source --hosted-zone-id Z_SOURCE_ZONE --output json > source-records.json取得した原本は残し、編集は別ファイルで行います。CLIは通常、ページ分割された結果を自動で取得します。全件を保存したいときに --no-paginate などで取得範囲を狭めないようにしてください。仕様はlist-resource-record-setsを参照できます。
2. 登録用JSONに組み直し、変更する値を選ぶ
一覧の ResourceRecordSets 配列から、登録したいレコードを選びます。登録用ファイルは Changes 配列に、操作を表す Action と、レコード内容を表す単数形の ResourceRecordSet を入れる構造です。
たとえば、移行先のWebサーバーに合わせてAレコードを変更するなら、次のような changes.json を作ります。IPアドレスは説明用です。
{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com.",
"Type": "A",
"TTL": 300,
"ResourceRecords": [
{ "Value": "192.0.2.20" }
]
}
}
]
}これは単純なAレコード1件の例です。重み付けやフェイルオーバーなどのレコードを、この例の項目だけに削ってはいけません。ルーティングポリシーに必要な属性も維持します。
一括置換する前に確認したい3か所
- ゾーン頂点のNS・SOA：移行先が自動作成したものを使い、旧ゾーンの値で上書きしません。一方、子ドメインの委任用NSまで一律に除外しないよう、種類だけでなく名前も確認します。
- エイリアスのHostedZoneId：同一ゾーン内の別レコードを参照する場合と、ALBなどのAWSリソースを参照する場合では意味が異なります。すべてを移行先ゾーンIDへ置換しないでください。
- ヘルスチェックの参照：移行先で作り直した場合は新しいIDへ変更します。JSONのコピーだけでヘルスチェックそのものが作られるわけではありません。
同一ゾーン内のエイリアスでは、参照されるレコードを先に作る順序も確認します。Traffic Flowを使っている場合は、通常のレコードコピーとは別に関連する設定を確認してください。これらの扱いはAWS公式のアカウント間移行手順に整理されています。
3. 移行先へ登録し、差分を確認する
新しいゾーンに対象レコードがまだ存在しないことを確認し、移行先プロファイルで登録します。
aws route53 change-resource-record-sets --profile destination --hosted-zone-id Z_DESTINATION_ZONE --change-batch file://changes.jsonCREATE は新規作成、UPSERT は存在するレコードの更新も行います。新規ゾーンへの初回投入では、既存レコードとの衝突を確認できるCREATEから検討します。エラーが出たからといって無条件にUPSERTへ変えると、意図しない上書きにつながります。
リクエスト単位では変更全体が検証され、全部適用されるか、全部適用されないかの動作になります。大量のレコードを複数リクエストに分けた場合、移行全体が1つのトランザクションになるわけではありません。操作と制約はchange-resource-record-setsで確認できます。
登録後は移行先でも一覧を取得し、レコード名・種類・値・TTL・ルーティング設定を照合します。意図して変更した値と、変わってはいけない値を別々に確認すると、差分の見落としを減らせます。
レコードのコピーとDNSの切り替えは別の工程
新ゾーンへレコードを入れても、利用者の問い合わせ先が自動で新ゾーンになるわけではありません。新ゾーンの権威DNSで回答を検証した後、ドメイン登録側や親ゾーン側の委任先を切り替えます。DNSSECを使う場合はDSと署名設定も移行計画に含めます。
切り替え中はDNSキャッシュが残るため、旧ゾーンも維持します。移行中にレコード更新が発生する場合は、新旧の内容をどうそろえるかを事前に決めておきます。サブドメインの委任については、サブドメインだけ別アカウントへ移す手順も参照してください。
サーバー復元に伴うIP変更が目的なら、EC2復元後のAレコード更新とTTLの注意点も関連します。
