How to Move an EC2 Instance to a Different Region (us-east-1 to ap-northeast-2)

You launched an EC2 instance in us-east-1, configured it, maybe even installed your stack — then realized the region is wrong. There is no direct 'move instance' button in the console, and the AWS API has no migrate-instance call. The only supported path is: create an AMI from the instance, copy that AMI to the target region, and launch a new instance from it.

TL;DR: Moving an EC2 Instance Across Regions

StepActionWhere It Runs
1Create AMI from source instanceus-east-1
2Copy AMI to target regionInitiated from ap-northeast-2
3Launch new instance from copied AMIap-northeast-2
4Verify, then terminate sourceus-east-1

How EC2 Region Migration Works

EC2 instances are region-bound. The underlying host, EBS volumes, ENIs, security groups, and key pairs all exist within a single region and cannot be relocated. What can cross regions is an AMI — a snapshot-backed machine image that captures the root volume (and optionally data volumes) plus launch configuration metadata.

The copy-AMI operation transfers the EBS snapshot data from the source region to the destination. Once the copy completes, the AMI in the target region is fully independent. Encryption keys, if used, must be accessible in both regions — more on that below.

One thing that does not transfer automatically: Elastic IPs, security groups, key pairs, IAM instance profiles, VPC/subnet configuration, and any data volumes not included in the AMI. You will need to recreate or reassign those in ap-northeast-2.

graph LR A["EC2 Instance
us-east-1"] -->|"CreateImage"| B["Source AMI
us-east-1"] B -->|"CopyImage
(initiated from target)"| C["Target AMI
ap-northeast-2"] C -->|"RunInstances"| D["New EC2 Instance
ap-northeast-2"] E["EBS Snapshots
us-east-1"] -.->|"backing store"| B C -.->|"new backing snapshots"| F["EBS Snapshots
ap-northeast-2"]
  1. Source instance (us-east-1): The running or stopped EC2 instance you want to move.
  2. CreateImage: AWS creates an AMI backed by EBS snapshots of the root (and optionally data) volumes.
  3. CopyImage: Initiated from the target region. AWS transfers the snapshot data across regions.
  4. Target AMI (ap-northeast-2): A fully independent AMI ready for launch.
  5. New instance: Launched from the copied AMI with target-region networking, security groups, and key pairs.

Step 1: Create an AMI from the Source EC2 Instance

Stop the instance before creating the AMI if you need a crash-consistent snapshot. For a running instance, AWS will attempt a live snapshot, but stopping first eliminates any risk of filesystem inconsistency on the root volume.

# Stop the instance first (recommended)
aws ec2 stop-instances \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1

# Wait until the instance is stopped
aws ec2 wait instance-stopped \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1

# Create the AMI
aws ec2 create-image \
  --instance-id i-0abcdef1234567890 \
  --name "my-app-migration-$(date +%Y%m%d)" \
  --no-reboot \
  --region us-east-1

The --no-reboot flag prevents AWS from rebooting the instance during AMI creation. Since you already stopped it manually, this is safe. The command returns an AMI ID — note it down. AMI creation is asynchronous; wait for the available state before proceeding.

# Poll until the AMI is available
aws ec2 wait image-available \
  --image-ids ami-0SOURCE123456789 \
  --region us-east-1

Step 2: Copy the AMI to ap-northeast-2

The copy operation is initiated from the destination region, not the source. This is a common point of confusion — you run the command targeting ap-northeast-2, and AWS pulls the snapshot data from us-east-1.

aws ec2 copy-image \
  --source-image-id ami-0SOURCE123456789 \
  --source-region us-east-1 \
  --name "my-app-migration-ap" \
  --region ap-northeast-2

This returns a new AMI ID in ap-northeast-2. The copy can take anywhere from a few minutes to over an hour depending on the total snapshot size. Wait for it to reach available state before launching.

aws ec2 wait image-available \
  --image-ids ami-0TARGET123456789 \
  --region ap-northeast-2

If Your EBS Volumes Are Encrypted

If the source AMI uses EBS encryption with a customer-managed KMS key, you must specify a KMS key in the target region. The source region's KMS key is not usable in ap-northeast-2.

aws ec2 copy-image \
  --source-image-id ami-0SOURCE123456789 \
  --source-region us-east-1 \
  --name "my-app-migration-ap-encrypted" \
  --encrypted \
  --kms-key-id arn:aws:kms:ap-northeast-2:123456789012:key/your-key-id \
  --region ap-northeast-2

If the source uses the AWS-managed key (aws/ebs), the copy will automatically re-encrypt with the AWS-managed key in the target region — no extra flag needed.

Step 3: Recreate Supporting Resources in ap-northeast-2

Before launching, make sure these exist in the target region — none of them transfer with the AMI:

  • Key pair: Either import your existing public key or create a new one in ap-northeast-2.
  • Security groups: Recreate your inbound/outbound rules. The AMI carries no security group config.
  • VPC/subnet: Use the default VPC or create a new one matching your source network layout.
  • IAM instance profile: IAM is global — the role itself exists, but you need to reference it by name at launch time.
# Import an existing public key to ap-northeast-2
aws ec2 import-key-pair \
  --key-name "my-keypair" \
  --public-key-material fileb://~/.ssh/id_rsa.pub \
  --region ap-northeast-2

Step 4: Launch the New Instance from the Copied AMI

aws ec2 run-instances \
  --image-id ami-0TARGET123456789 \
  --instance-type t3.medium \
  --key-name my-keypair \
  --security-group-ids sg-0TARGET123456789 \
  --subnet-id subnet-0TARGET123456789 \
  --iam-instance-profile Name=my-instance-profile \
  --region ap-northeast-2

Once the instance passes both status checks, validate your application. SSH in, confirm services are running, check any application-level health endpoints.

Step 5: Handle Data Volumes Not Included in the AMI

If your source instance had additional EBS volumes (beyond root) that were not included in the AMI block device mapping, you need to migrate those separately.

# Create a snapshot of the data volume in us-east-1
aws ec2 create-snapshot \
  --volume-id vol-0DATAVOLUME123456 \
  --description "data-volume-migration" \
  --region us-east-1

# Copy the snapshot to ap-northeast-2
aws ec2 copy-snapshot \
  --source-snapshot-id snap-0SOURCE123456789 \
  --source-region us-east-1 \
  --description "data-volume-ap" \
  --region ap-northeast-2

# Create a volume from the snapshot in ap-northeast-2
aws ec2 create-volume \
  --snapshot-id snap-0TARGET123456789 \
  --availability-zone ap-northeast-2a \
  --region ap-northeast-2

Then attach the new volume to your migrated instance and verify the mount point and filesystem are intact.

A Real Migration Failure Pattern Worth Knowing

Here is a failure pattern that catches engineers off guard: the instance launches cleanly in ap-northeast-2, passes EC2 status checks, but the application fails to start. The symptom looks like a broken AMI or a missing package.

The actual cause is almost always one of two things. First, the application was configured with a hardcoded endpoint — an RDS hostname, an ElastiCache endpoint, or an internal load balancer DNS name — that only resolves inside us-east-1. The instance boots fine; the app just cannot reach its dependencies. Second, an IAM role with a resource-level condition scoped to a specific region or VPC is silently denying API calls the app depends on at startup.

Neither failure produces a clear error at the OS level. Check your application logs first, not the EC2 system log. If the app log shows connection timeouts or permission denied errors on AWS API calls, those are your actual root causes — not the AMI.

Step 6: Clean Up the Source Region

Once you have validated the new instance in ap-northeast-2, clean up to avoid ongoing EBS snapshot charges in us-east-1.

# Deregister the source AMI
aws ec2 deregister-image \
  --image-id ami-0SOURCE123456789 \
  --region us-east-1

# Delete the backing snapshots (list them first)
aws ec2 describe-snapshots \
  --filters Name=description,Values="Created by CreateImage*" \
  --owner-ids self \
  --region us-east-1

# Delete each snapshot
aws ec2 delete-snapshot \
  --snapshot-id snap-0SOURCE123456789 \
  --region us-east-1

# Terminate the source instance
aws ec2 terminate-instances \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1

Deregistering an AMI does not automatically delete its backing snapshots. You must delete them separately — otherwise you will keep paying for snapshot storage in us-east-1 indefinitely.

IAM Permissions Required for EC2 Region Migration

🔽 Click to expand — minimum IAM policy for this migration
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2MigrationPermissions",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateImage",
        "ec2:CopyImage",
        "ec2:CopySnapshot",
        "ec2:CreateSnapshot",
        "ec2:CreateVolume",
        "ec2:RunInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:DeregisterImage",
        "ec2:DeleteSnapshot",
        "ec2:DescribeImages",
        "ec2:DescribeSnapshots",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus",
        "ec2:ImportKeyPair",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    },
    {
      "Sid": "KMSForEncryptedVolumes",
      "Effect": "Allow",
      "Action": [
        "kms:CreateGrant",
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:ReEncrypt*"
      ],
      "Resource": "arn:aws:kms:ap-northeast-2:123456789012:key/your-key-id"
    }
  ]
}

The KMS block is only required if you are copying encrypted AMIs. For unencrypted volumes, the EC2 block alone is sufficient. Several Describe and List actions require "Resource": "*" — the Service Authorization Reference confirms these cannot be scoped to specific resource ARNs.

Wrap-Up: Moving EC2 Instances Across Regions

There is no direct EC2 region migration API. The supported path — create AMI, copy AMI, launch new instance — is straightforward but has several non-obvious failure points: encrypted volume key scoping, data volumes outside the AMI, and application-level dependencies that only exist in the source region. Work through each step in order, validate before terminating the source, and delete the backing snapshots explicitly after deregistering the AMI.

For the full AMI copy API reference, see the AWS documentation on copying AMIs. For KMS cross-region key behavior with EBS encryption, see the EBS encryption documentation.

Glossary

TermDefinition
AMI (Amazon Machine Image)A snapshot-backed image containing the OS, configuration, and optionally data volumes used to launch EC2 instances.
EBS SnapshotA point-in-time backup of an EBS volume stored in S3, used as the backing store for AMIs.
CopyImageThe EC2 API action that transfers an AMI and its backing snapshots from one region to another.
Customer-Managed KMS Key (CMK)A KMS key you control, scoped to a specific region. Required when copying encrypted AMIs to a region where the source key is not available.
IAM Instance ProfileA container for an IAM role that can be attached to an EC2 instance, granting it permissions to call AWS APIs.

Related Posts

Comments

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 SSH Connection Timeout: Which Security Group Rules to Check

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?