Skip to content

AWS Updated 2026-07-04

Moving an EC2 instance to another AZ or Region: the AMI copy runbook

You cannot move an EC2 instance directly — you image it and relaunch. The full runbook for moving an instance to another Availability Zone or Region: AMI creation, copy-image, networking, and cutover.

There is no “move” button for an EC2 instance: instances are pinned to the Availability Zone their volumes live in for their whole life. The move is always image-and-relaunch — create an AMI of the instance, copy it to the target Region if you are crossing Regions (an AZ move within the same Region skips the copy), launch a new instance from it in the target subnet, re-point networking and DNS, and retire the original. Done in order, it is a low-drama runbook with one planned cutover window sized by how much data changes between snapshot and switch.

What’s happening

An EC2 instance is metadata wrapped around EBS volumes, and EBS volumes physically exist in exactly one AZ. That is why AZ and Region moves are the same operation at different radii: package the root (and data) volumes into an AMI — which is really a set of EBS snapshots plus launch metadata — then instantiate it where you want it. Snapshots are Region-scoped, so a cross-Region move adds aws ec2 copy-image to ship them; an AZ move only requires launching into a subnet in the target AZ, since AMIs are usable Region-wide.

What does not travel with the AMI matters as much as what does: the private IP (subnet-specific), the Elastic IP (Region-specific — reassociable across AZs in the same Region, useless across Regions), instance store volumes (ephemeral, never captured in an AMI), the instance ID (anything keyed to it — monitoring, licences — must be updated), and IAM instance profiles plus security groups across Regions (security groups are Region-scoped and must exist in the target first). Encrypted volumes travel fine, but a cross-Region copy re-encrypts with a KMS key in the destination Region, which you should choose explicitly rather than defaulting.

What to check first

  • Instance store volumes. aws ec2 describe-instances block device mappings: anything on instance store dies with the instance and needs an rsync/backup path of its own.
  • What is pinned to the current IPs — DNS records, partner allowlists, application configs with hardcoded addresses. Cross-Region means new public IPs, full stop.
  • Data change rate. A busy database diverges from its AMI within minutes; the cutover plan (freeze, final sync, or replication) depends on it.
  • Target-side prerequisites: VPC, subnets, security groups, key pairs, instance profile availability, and whether the instance type exists in the target AZ or Region.
  • Marketplace or licence constraints. Some Marketplace AMIs restrict Region copies; bring-your-own licences may be Region-bound.

How to verify

Map what you are about to move:

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[InstanceType,Placement.AvailabilityZone,SubnetId,PublicIpAddress,BlockDeviceMappings[].Ebs.VolumeId]'

Confirm the target offers the instance type:

aws ec2 describe-instance-type-offerings \
  --region ca-central-1 --location-type availability-zone \
  --filters "Name=instance-type,Values=m7g.large" \
  --query 'InstanceTypeOfferings[].Location'

After imaging, watch AMI and copy progress in EC2 > AMIs (state must reach available before launch) or:

aws ec2 describe-images --image-ids ami-0abc1234def567890 \
  --query 'Images[].[State,BlockDeviceMappings[].Ebs.SnapshotId]'

The runbook

  1. Quiesce and image. For anything stateful, stop writes (application maintenance mode or a clean stop of the instance) and create the AMI without --no-reboot so the filesystem is consistent:

    aws ec2 create-image --instance-id i-0123456789abcdef0 \
  --name "web01-move-2026-07-04" \
  --description "Pre-move image incl. all EBS volumes"

    A hot image with --no-reboot is acceptable for mostly-static servers; databases deserve the reboot or their own dump/replication.

  2. Cross-Region only — copy the AMI (skip for an AZ move):

    aws ec2 copy-image --source-region us-east-1 --region ca-central-1 \
  --source-image-id ami-0abc1234def567890 \
  --name "web01-move-2026-07-04" --encrypted

    Copy time scales with snapshot size; large volumes can take hours, so do this well before the window.

  3. Prepare the landing zone: security groups recreated (rules re-pointed at target-side groups per the security group cookbook), a subnet in the target AZ chosen deliberately — subnet design questions are covered in multi-AZ subnet design — key pair present, instance profile attached at launch.

  4. Launch and verify in isolation. Boot the new instance from the copied AMI, then test it directly (its own IP, /etc/hosts override, or a staging DNS name) before any traffic moves. Check the app, the agents, cron, and outbound connectivity.

  5. Sync the delta for stateful data. Between image time and cutover, rsync changed files or replay database changes (native replication if you have it). For a same-Region AZ move of a data volume, a fresh snapshot restored into the target AZ is often simpler than file-level sync.

  6. Cut over. Same Region: re-associate the Elastic IP to the new instance — seconds of blip. Cross-Region: lower DNS TTL in advance, then flip records to the new address, and expect stragglers for as long as the old TTL. Keep the old instance stopped, not terminated.

  7. Retire deliberately. After a burn-in period (days, not minutes), terminate the source, delete leftover volumes, and deregister interim AMIs and snapshots you no longer need — they bill as snapshot storage forever otherwise.

When this is the wrong move

If the instance is in an Auto Scaling group, do none of this — update the launch template’s subnets/AZs and let the ASG replace instances; hand-moving ASG members fights the automation. If the real goal is surviving AZ failure, one instance moved to another AZ is the same single point of failure at a new address — you want two instances behind a load balancer. And for large fleets or continuous replication needs, AWS offers migration tooling (AWS DRS / Application Migration Service) that beats hand-run AMI copies; see the EC2 documentation for the current options.

Common mistakes

  • Imaging a busy database with --no-reboot and discovering the copy is crash-inconsistent when it matters most.
  • Forgetting the Elastic IP cannot follow across Regions, then hunting for why partners still hit the old Region.
  • Launching the copy into a subnet whose route table or NACLs differ from the source, so “the same server” behaves differently.
  • Terminating the source the same afternoon. The old instance is your rollback; keep it stopped until the new one has survived real traffic.

Prevention

  • Keep golden AMIs and IaC definitions current so “move” becomes “launch our standard build over there” — the discipline from the golden AMI pipeline pays off exactly here.
  • Never let production identity live on an instance: DNS names, not IPs, in every config.
  • Run stateful services on managed platforms (RDS, EFS) whose cross-AZ story is built in.
  • Rehearse the runbook on a staging instance once; the first execution should not be the production one.

Image, copy, launch, sync, flip, retire — the move itself is mechanical; the judgment is in the data sync and the cutover timing. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.