EC2インスタンスは、起動後に所属するアベイラビリティーゾーン（AZ）だけを変更できません。AZ障害時に別AZで復旧し、障害復旧後に元のAZへ切り戻す場合も、現在のインスタンスを移動するのではなく、AMIなどから元のAZに新しいインスタンスを作成します。
この記事の結論
- 既存のEC2インスタンスを別AZへ直接移動する操作はない
- 移動先AZのサブネットを指定し、AMIから新しいインスタンスを起動する
- 別AZから元のAZへ切り戻すときも同じ手順になる
- 新しいインスタンスID、プライベートIP、ネットワークインターフェイスになる
- Systems Managerの
AWSSupport-CopyEC2Instanceで作業を自動化できる
なぜ停止・起動だけではAZを変更できないのか
EC2インスタンスは、起動時に選択したサブネットのAZへ配置されます。停止してから再起動しても同じインスタンスであり、所属サブネットとAZは変わりません。AZを変えるには、移動先AZに属する別のサブネットで新規インスタンスを起動する必要があります。
AMIを使ったAZ移動の基本手順
- ソースEC2への書き込みを停止または整合性が取れる状態にする
- ソースEC2からAMIを作成する
- AMIと関連EBSスナップショットが利用可能になるまで待つ
- 移動先AZのサブネットを指定して新しいEC2を起動する
- セキュリティグループ、IAMロール、タグ、ユーザーデータなどを確認する
- アプリケーションと監視の動作を確認する
- DNS、ロードバランサー、Elastic IPなどの接続先を切り替える
- 切り戻し期間を経て、旧インスタンスや不要なAMIを整理する
AMI作成時の再起動を無効にすると停止時間を抑えられますが、ファイルシステム整合性は保証されません。データベースなど書き込みの多いワークロードでは、アプリケーション停止、フラッシュ、データベース固有のバックアップを含めて設計します。
切り戻しも「再度新規作成」になる
AZ障害中にAZ-Bへ復旧し、後日AZ-Aへ戻す場合、AZ-BのインスタンスをAZ-Aへ直接移すことはできません。AZ-Bで更新された最新状態をAMIへ反映し、そのAMIからAZ-Aのサブネットへ新しいEC2を起動します。
古いAMIを使うと、復旧後に発生したOS設定やアプリケーションデータの変更が失われる可能性があります。切り戻し時点の正しいデータ源が、AMI、外部データベース、EFS、S3、レプリケーション先のどれなのかを先に決めてください。
引き継がれない・確認が必要な項目
| 項目 | 移動後の扱い |
|---|---|
| インスタンスID | 新しいIDになる |
| プライベートIPv4 | 移動先サブネットの範囲から割り当てられる |
| 自動割り当てのパブリックIP | 通常は新しい値になる |
| Elastic IP | 同一リージョン・同一ネットワーク境界グループなどの条件を満たせば再関連付けを検討できる |
| ENI | AZに属するため、別AZのインスタンスへそのまま移せない |
| セキュリティグループ | 同一VPCなら選択可能。別VPC・別リージョンでは作り直しが必要 |
| IAMロール | 新しいインスタンスへインスタンスプロファイルを関連付ける |
| インスタンスストア | AMIには保存されないため別途退避が必要 |
| CloudWatch Alarm | InstanceIdを参照するアラームは新しいIDへ更新する |
Systems Manager Automationで自動化する
AWS管理のAutomationランブックAWSSupport-CopyEC2Instanceは、AMIの作成と指定サブネットでの新規インスタンス起動を自動化します。SubnetIdに移動先AZのサブネットを指定すると、同一リージョン内の別AZへのコピーに利用できます。
InstanceId：コピー元のEC2SubnetId：移動先AZのサブネットSecurityGroupIds：新しいEC2へ割り当てるセキュリティグループInstanceType：移動先AZで利用できるインスタンスタイプNoRebootInstanceBeforeTakingImage：AMI作成前の再起動を省略するかKeepImageSourceRegion：作成したAMIを保持するか
このランブックはEC2のコピーを自動化しますが、DNS切り替え、ロードバランサーへの登録、アプリケーション整合性確認、旧環境の削除判断まで自動で完結するわけではありません。
切り替え前の確認項目
- 移動先AZで対象インスタンスタイプのキャパシティを確保できるか
- サブネットの空きIPアドレスがあるか
- ルートテーブル、NACL、VPCエンドポイントの経路が同等か
- 追加EBSボリュームがAMIへ含まれているか
- KMSキーを新しいインスタンスから利用できるか
- ライセンスやホスト名、Active Directory参加に影響がないか
- DNS TTLと既存接続の再接続時間を考慮したか
- 監視、バックアップ、パッチ管理の対象へ新しいIDを登録したか
DNSを使った接続先変更の考え方は、EC2復元後にRoute 53レコードを更新する方法も参考にしてください。
AZ障害のたびに手動復元しない構成
単一EC2をAMIから復元する方式は、バックアップ＆リストア型のDRです。復旧時間を短縮したい場合は、複数AZのAuto Scalingグループ、Application Load Balancer、外部データストアなどを組み合わせ、障害AZを避けて別AZに自動起動できる構成を検討します。
元のAZへ必ず戻す必要があるかも再確認します。復旧先AZで必要な可用性と運用要件を満たしていれば、切り戻しによる追加停止やデータ同期リスクを避け、そのまま運用する判断もあります。
まとめ
EC2はAZを直接変更できません。別AZへの復旧も元のAZへの切り戻しも、最新状態からAMIを作り、目的のAZのサブネットで新しいインスタンスを起動するのが基本です。インスタンスIDやIPアドレスなどは変わるため、ネットワーク、監視、バックアップ、DNSまで含めて切り替え手順を作成してください。
