
This blog post is part two of a 3-part series describing a technique for how to export and import Amazon Web Services (AWS) instance volume images. Read the full introduction for more details. Part 1 is available here.
About the Demonstration
In this post, I’ll demonstrate a technique using standard Linux tools to create a bootable AWS EC2 instance from an imported AWS volume image. For the demonstration, I will restore and boot a Windows domain controller from an archival disk image that had been stored in Google Drive.
I used a Linux server running in EC2 to import and work with the volume images. Any flavor of Linux works; I used Ubuntu 16.04. I refer to this Linux server running in EC2 as the “build” server. On the build server, you’ll need at least twice as much free storage space as the size of the EC2 volume image.
How to Restore and Boot from an EC2 Volume Image
Step 1: Copy the Image into EC2
The first step is to copy the archived volume image to the build server in EC2.
For this demonstration, I used rclone to copy an image of a Windows 2016 domain controller from Google Drive to the build server.
After your image has been transferred and uncompressed, use fdisk to perform a quick sanity check on your image.

The partition table within the image confirms that it is a 30GiB image with a single NTFS partition, which makes sense for a windows server.
Step 2: Create a New EC2 instance
It doesn’t matter which Amazon Machine Image (AMI) you choose, since the operating system will be loaded from your disk image. Select an appropriate instance type based on your specific CPU and RAM requirements. Create the instance with a root volume the same size as your image.

Be sure to launch the instance in the same availability zone as your build server. If you have specific IP address requirements for this server, specify them during the instance setup process since you can’t easily change them later.
After the instance is created, stop it and detach the root volume. You will overwrite this newly-created volume with the volume image.
Step 3: Attach the Volume to the Build Server
The next step is to attach the volume to your build server.

On the build server, use the “fdisk -l” command to find the device name of the new volume. In this example, the volume is available as /dev/xvdf.

Step 4: Copy the Image
Copy the image to the new volume using the “dd” command.
# dd if=FireOakDC04.24Jan2019.img bs=1M of=/dev/xvdf status=progress

Step 5: Test the New Volume
Once the copy is complete, mount the volume to confirm that the copy worked correctly.

In this case, we have an NTFS partition that contains a Windows volume.
Unmount the volume from the build server, and then use the AWS webUI to detach the volume from the build server.
Step 6: Boot the Restored Instance
Once detached, attach the volume back to the instance we created in Step 2. Be sure to attach the device as /dev/sda1 so that the instance will use it as a boot drive.

Note: This nomenclature is confusing; the volume contains a disk image, not a partition, so I would think /dev/sda would be the proper attachment point. But the server will not boot unless you specify /dev/sda1 as shown here.
You can now start the instance. The “Get Instance Screenshot” feature in EC2 webUI provides a quick way to see what is happening on your virtual server’s console.

The instance should now be up and running.
In Part 3 of this series, I’ll demonstrate how to automate the process of creating and archiving disk images.