Sometimes, you just need to change the data center where you’re running your virtual machines. You could be doing this for disaster recovery reasons, network latency reasons, or just because you’re shutting down a region. In an on-prem environment, you might move workloads to a different data center by vMotion, VMware Site Recovery Manager, Zerto, Recoverpoint for VMs, Veeam, or one of the other great tools for a virtualized environment. But how about if that VM is running in an AWS region and you want to move it to another region?

This post aims to explain how you can move a running EC2 instance within one region, to another region. I’ll take an EC2 instance running my (incredibly sophisticated) Apache website from the US-East-1 (Northern Virginia) region over to US-East-2 (Ohio) region.

Snapshot the EC2 Instance

Before we begin, lets make sure my web server is running in an optimal state. I’ll go to the EC2 console and find the public address for my EC2 instance and browse to it through my web browser. Yep, my EC2 instance is providing my web page which lists the internal IP Address and my logo. This internal IP Address is automatically added to the web page through the user data parameters provided at boot up.

Next we want to take a snapshot of the instance from the EC2 console. Go to your EC2 console and navigate to the “Snapshots” item in the left hand menu.

Click “Create Snapshot” to open up the snapshot window. From there select the volume that’s attached to your EC2 instance (this post assumes only a root volume) and then name your snapshot. You should also add a good description here for reference purposes later on down the road. When you’re done, click the “Create” button.

NOTE: notice the Encrypted option is set to No.

Replicate the Snapshot to the New Region

Once your snapshot has been created, select it from the menu and click the “Actions” button and then select “Copy” from the drop down menu.

Here we select the region where we want the new instance to be created. We can modify the description and then notice that we have an option to encrypt the volume as part of the copy command. If we encrypt the volume we’ll need to select the key from the AWS KMS service that would be used to encrypt the volume. When you’ve set your configurations click the “Copy” button.

You should receive a success message that the operation has started. Click the “Close” button.

The New Region

Now, if we change to the destination region in our AWS console, we can look for any snapshots that exist in that region. Depending on how long you wait before switching regions, you may see the snapshot that we’re in the process of copying over is in a pending state. Wait until the snapshot has finished copying to the new location before proceeding.

Once the snapshot is ready, select it and then click the “Actions” button and then the “Create Image” item in the drop down menu. This process takes the snapshot and creates an Amazon Machine Image (AMI – Pronounced: Ah-mee) which can be used to spin up new EC2 instances. Provide a name, the architecture, a description, the virtualization type and any size differences that you might want to make here. You’ll notice that the root volume here will be encrypted since we encrypted our snapshot when we copied it to the secondary region. When you’re done, click the “Create” button.

If all goes well, you should get a success message that your snapshot was created correctly. Click the “Close” button.

Now, if you navigate to the AMIs section of the EC2 console, you should see a new AMI with the name that you gave it in the previous step. From here, you can launch a new EC2 instance using this image and place it in whichever Availability Zone, subnet and security group that makes sense in your new region.

The Results

After deploying my new AMI in the Ohio region, I test my application by finding the IP Address from the EC2 console and browsing to it with my web browser. Notice that the metadata in the website still shows my previous IP Address that we saw in the first screenshot in this post. Thats because the image is identical to the snapshot we made from the US-East-1 instance. When i started up this snapshotted AMI I didn’t provide any user data to change this so it used what it already had which is left over from the previous region. In your case, this probably won’t matter, but I did it to show that it’s an exact copy of the instance from US-East-1.

Summary

So moving an instance from one region to another isn’t quite as neat as using long-distance vMotion but it does the job adequately enough. Remember that in the cloud world we’re likely more interested in re-creating an instance quickly through automation, than moving a live workload like we used to do. This process keeps the primary instance running the entire time while using a replicated snapshot to run a new instance in another region. Whether you need to power down the original instance or not, is something you’ll have to decide for your use case. Thanks for reading.