EC2復元後のIP変更をRoute 53へ反映する方法｜Aレコード更新とTTLの注意点

2026年9月15日

EC2を別AZへ復元してプライベートIPが変わった場合、Route 53のAレコードはAPIで更新できます。ただし、EC2が起動しただけで任意のホストゾーンに自動登録されるわけではありません。復元先の正常性を確認し、DNS更新を復旧手順に組み込む必要があります。

対象はPrivate Hosted Zoneのシンプルルーティング・非AliasのAレコードを、1台のEC2のIPv4アドレスへ向ける構成です。複数値、フェイルオーバー、加重ルーティング、Aliasレコードはこの例をそのまま使わず、既存の設定を維持する手順を別途用意してください。仕様確認日：2026年9月15日。

Windowsの動的DNS登録とRoute 53 API更新を区別する

WindowsのDNS動的更新の設定を有効にすることと、Route 53のレコードをAPIで書き換えることは別の処理です。本記事ではChangeResourceRecordSets APIを使います。AD環境のDNS更新を調べている場合は、先にWindowsのDNS動的登録に必要な設定を確認してください。

復元から切替までの流れ

復元先のインスタンスID・アカウント・リージョンを特定する。
新しいIPを確認し、OS・アプリケーションの準備完了を確認する。
旧インスタンスが同時に本番処理を行わないよう、切替対象と役割を確認する。
変更前のDNSレコードを保存し、新IPへの更新を実行する。
Route 53の反映、利用側の名前解決、実際の業務接続を順に確認する。

EC2のrunning状態だけでアプリケーションの準備完了とは判断しません。起動イベントをそのままDNS更新に結び付けると、サービスが待ち受ける前に利用者が接続する可能性があります。

1. 変更前のレコードと新しいIPを確認する

以下のIDは例示用です。権限を持つ運用端末から対象環境に置き換えて実行します。1行ごとに独立したコマンドです。

aws route53 list-resource-record-sets --hosted-zone-id ZEXAMPLE123 --output json
aws ec2 describe-instances --region ap-northeast-1 --instance-ids i-0123456789abcdef0 --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name,PrivateIP:PrivateIpAddress,Subnet:SubnetId}' --output table

同名のPublic Hosted ZoneとPrivate Hosted Zoneを取り違えないよう、ホストゾーンIDと関連付け先VPCを確認します。複数ENI・複数IPがある場合は、表示されたプライマリIPがアプリケーションの接続先として適切かも確認してください。

2. Aレコードの更新用JSONを作る

次の内容をUTF-8のchange-batch.jsonとして保存します。app.internal.example.comと10.0.20.15は例です。TTLの60秒も説明用であり、システム全体の復旧時間を保証する値ではありません。

{
  "Comment": "Switch application to verified restored instance",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.internal.example.com.",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          { "Value": "10.0.20.15" }
        ]
      }
    }
  ]
}

UPSERTは、対象のレコードセットがなければ作成し、存在すれば指定内容に更新します。既存の複数IPに1個を追加する操作ではありません。既存値が複数ある場合にこの例を流用すると、意図した値を失うおそれがあります。ChangeResourceRecordSetsの仕様を確認してください。

3. 更新し、反映状態を確認する

aws route53 change-resource-record-sets --hosted-zone-id ZEXAMPLE123 --change-batch file://change-batch.json
aws route53 get-change --id /change/CEXAMPLE123

2行目の変更IDには、1行目の応答にあるChangeInfo.Idを指定します。GetChangeのStatusがINSYNCになったら、Route 53側の反映を確認できた状態です。アプリケーションやDNSキャッシュがすべて更新されたという意味ではありません。

TTLが60秒なら60秒で復旧する？

復旧時間には、復元・OS起動・アプリケーション準備・DNS更新・クライアントの再接続などが含まれます。DNSを変更する直前にTTLを短くしても、すでにキャッシュされた応答には以前のTTLが残り得ます。計画的な切替では事前にTTLを調整し、以前のキャッシュが失効する時間も考慮します。

また、既存のTCP接続やアプリケーション独自の名前解決キャッシュは、DNSレコード更新だけで切り替わるとは限りません。Route 53のTTLの説明と利用アプリケーションの接続動作を合わせて確認します。

自動化で追加する確認

確認点	設計例
対象の特定	復旧ジョブの結果とインスタンスIDを対応付け、同名タグだけで本番対象を決めない
準備完了	アプリケーション試験が成功してからDNS更新へ進む
重複実行	同じ復旧ジョブの再通知を区別し、古いジョブで新しいDNSを上書きしない
権限	対象ゾーン・レコード名・A型・UPSERTなど、必要な範囲に限定する
切り戻し	変更前のレコードと旧系の状態を記録し、旧IPへ戻してよい条件を定める