██FR█████ █INTELL███████████

Migrating EC2 Instances Across Accounts & Regions Using AMI Sharing


This content originally appeared on DEV Community and was authored by Venkata Pavan Vishnu Rachapudi

When you think of moving an application from one EC2 instance to another, the first things that usually come to mind are:

  • Taking database dumps
  • Copying application files manually
  • Using third-party migration tools or plugins

While these methods work, they are often time-consuming, error-prone, and application-specific.

But here’s the shiner ✨ — a method we sometimes forget:

👉 AMI Sharing + Copying Across Regions.

🔑 Why AMI Sharing is Worth Remembering

Instead of migrating components individually (files, DB, configs), you simply capture the entire server as a machine image (AMI).
This guarantees that:

  • Your OS, application, database, configs, SSL certs, cron jobs, and dependencies move together.
  • Migration is faster and more reliable.
  • It works for any workload, not just specific apps.

🛠 Step-by-Step: Migrating EC2 with AMI Sharing

1. Create an AMI from the Source EC2

In AWS Console:

  • Go to EC2 → Instances → Create Image (AMI).

AWS CLI:

aws ec2 create-image\
  --instance-id i-0123456789abcdef0\
  --name "my-server-ami"\
  --description "AMI for migration"

2. Share the AMI with the Destination Account

In Console:

  • EC2 → AMIs → Modify Image Permissions → Add the AWS Account ID of the destination.

AWS CLI (make it public or shared with specific account):

aws ec2 modify-image-attribute\
  --image-id ami-1234567890abcdef0\
  --launch-permission "Add=[{UserId=111122223333}]"

⚠ If the AMI uses encrypted EBS volumes, also share the snapshot:

aws ec2 modify-snapshot-attribute\
  --snapshot-id snap-1234567890abcdef0\
  --attribute createVolumePermission\
  --operation-type add\
  --user-ids 111122223333

And if using a KMS key for encryption:

aws kms create-grant\
  --key-id <kms-key-id>\
  --grantee-principal <arn:aws:iam::<dest-account-id>:root>\
  --operations Decrypt,Encrypt,GenerateDataKey

3. Copy the AMI to the Destination Region

AMIs are region-specific. You need to copy it to your target region.

AWS Console:

  • In destination account, go to Shared AMIs → Copy AMI → Select target region.

AWS CLI:

aws ec2 copy-image\
  --source-image-id ami-1234567890abcdef0\
  --source-region us-east-1\
  --region us-west-1\
  --name "my-server-ami-copy"

4. Launch a New EC2 Instance

From the copied AMI, you can launch your new instance.

AWS CLI:

aws ec2 run-instances\
  --image-id ami-0987654321fedcba0\
  --count 1\
  --instance-type t3.medium\
  --key-name my-key\
  --security-group-ids sg-0123456789abcdef0\
  --subnet-id subnet-0123456789abcdef0

✅ Advantages

  • Universal → Works for any EC2 workload (WordPress, LAMP, Node.js, custom apps).

  • Faster & simpler than app-specific migration methods.

  • Reliable → No missing configs or dependencies.

  • Secure → Controlled sharing with account IDs.

⚠ Things to Keep in Mind

  • Networking (VPCs, SGs, IAM roles, Elastic IPs) don’t move → must be recreated.

  • Encrypted Volumes → require snapshot & KMS key sharing.

  • Licensing → commercial software may not migrate cleanly without reactivation.

After you migrate an EC2 instance via AMI → new instance, the new root volume may be larger than needed, and you want to shrink it down to save costs.

Since AWS doesn’t allow direct shrinking of EBS volumes, the workaround after launching from an AMI looks like this:

🛠 Shrinking EC2 Root Volume After AMI Migration

1. Check Actual Disk Usage

On the new EC2 instance:

df -h
lsblk

If the root volume is 100GB but your used space is only 20GB, you can safely shrink.

2. Create a Snapshot of the Current Root Volume 

aws ec2 create-snapshot\
  --volume-id vol-0123456789abcdef0\
  --description "Root snapshot before shrink"

3. Create a New, Smaller Volume from Snapshot

When creating a volume from snapshot, AWS will let you specify a smaller size only if the snapshot’s used data fits.

aws ec2 create-volume\
  --snapshot-id snap-0123456789abcdef0\
  --availability-zone us-west-1a\
  --size 30\
  --volume-type gp3

⚠ Make sure 30GB is larger than the actual data used on root FS.

4. Stop Instance & Swap Volumes

  1. Stop your instance: 
 aws ec2 stop-instances --instance-ids i-0123456789abcdef0
  1. Detach the large root volume: 
 aws ec2 detach-volume --volume-id vol-0123456789abcdef0
  1. Attach the smaller volume as root (/dev/sda1 or /dev/xvda depending on AMI): 
 aws ec2 attach-volume\
      --volume-id vol-0987654321fedcba0\
      --instance-id i-0123456789abcdef0\
      --device /dev/sda1
  1. Start the instance again.

5. Validate & Clean Up

  • Boot the instance and verify it works.

  • Run df -h to confirm root volume size is smaller.

  • Once tested, delete the old large volume to save costs.

✅ Key Notes

  • Works well when you move via AMI but want a tighter root volume size.

  • AWS Console allows you to edit root volume size at launch too (during EC2 creation step → “Advanced Volume settings”), but you can only shrink if the snapshot permits it.

  • If shrinking root FS fails, a safer path is:

    • Launch a fresh small EC2 instance
    • Mount both volumes (large & new small)
    • Copy data via rsync
    • Swap smaller volume as root

👉 So the trick is: AMI → snapshot → new smaller volume → swap root disk.\
That way you can shrink even after migrating an EC2 via AMI.

🚀 TL;DR

Next time you need to move an EC2 instance whether WordPress, LAMP, or a custom server -remember this shiner ✨:

  1. Create AMI

  2. Share AMI

  3. Copy AMI to target region

  4. Launch EC2

And your server is migrated, clean and simple. 🎯

👉 This method is not limited to WordPress – it’s applicable to all EC2-based workloads.


This content originally appeared on DEV Community and was authored by Venkata Pavan Vishnu Rachapudi