Web Analytics

FireOak Strategies Blog

Insights and articles related to knowledge management, information security, technology, data and analytics, business process automation, platform management, and other related topics, from our experienced team of consultants.

Part 2: Restore and Boot from an AWS EC2 Volume Image

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.


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.

Copy Image into EC2

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.

Create a New Instance

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.

Attach the New Volume to the 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. 

Use fdisk to Locate the Attached Volume

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 
Copy the Image File Contents to the Volume

Step 5: Test the New Volume

Once the copy is complete, mount the volume to confirm that the copy worked correctly.

Check the Restored Volume

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.

Attach a Volume as a New Boot Volume

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.

Console Screenshot of the Instance

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.

Read next post

From the FireOak Blog

News and insights from the FireOak team about managing, securing, and sharing knowledge