Although many organizations have found that it's more cost effective to host VMs in the cloud, there are occasionally...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
reasons to move a back into an on-premises data center. For organizations that host VMs -- which Amazon refers to as instances -- on Amazon Web Services, the export process is relatively easy to work through, but comes with some significant restrictions.
The most significant limitation to exporting an Amazon Web Services (AWS) instance is that you can only export one that was previously imported from your on-premises virtualization environment. To be more technically precise, Amazon doesn't care where the VM originated from, so long as the VM was imported rather than created natively in AWS.
Amazon also places some very significant restrictions on the instance's virtual hardware. An AWS instance, for example, must only be equipped with a single virtual hard disk (VHD) and a single network interface. Otherwise, you won't be able to export the instance. Furthermore, you can't export an instance configured to use VHDs, nor can you export Amazon Elastic Block Store data volumes.
Assuming your VM meets all of Amazon's criteria and hasn't been shared by another AWS account -- which also prevents the export process -- the first step is to decide what format you want to use for the exported virtual hard disk. Your options are to export the virtual hard disk as an OVA file, a VMDK file -- supported by VMware vSphere -- or a VHD file -- compatible with Citrix and Microsoft Hyper-V.
The export process works by placing the exported virtual hard disk into an Amazon Simple Storage Service (S3) bucket. You can then download the virtual hard disk from the bucket.
There isn't anything difficult about creating a bucket. You can simply go into the AWS S3 console and use the create-bucket command. However, every bucket is assigned a name, and the name you use must be globally unique. In other words, you can't use a bucket name that has been used by any other AWS subscriber in the past. I usually get around this restriction by incorporating a variation of my name into the bucket name.
Once the necessary bucket is in place, the next step in the process is to give AWS permission to use the bucket as a repository for exporting instances. You can accomplish this task by selecting the bucket you wish to use and then clicking the Permissions tab. Now, select the Access Control List tab and click the Add Users button. You need to enter firstname.lastname@example.org as the user name and set the object access to Read/Write. You can see what this looks like in Figure A.
The last step in the process is to actually export the AWS instance. There are a few key pieces of information you need before you begin the export. First, you need to know the instance ID of the instance you want to export. You also need to know the target hypervisor. The export process is command line-driven and the target hypervisor must be entered as vmware, citrix or microsoft -- lower case.
As previously mentioned, you are also going to need to specify the disk image format. According to Amazon's documentation, this must be entered as either VMDK or VHD. Finally, you need to know the name of the S3 bucket you intend to use as well as any S3 prefix you want to use.
The command syntax is as follows:
Aws ec2 create-instance-export-task –instance-id <the instance ID> --target-environment <your chosen hypervisor type> \ --export-to-s3-task DiskImageFormat=<your chosen disk image format>,ContainerFormat=<the container format is optional and used for specifying OVA>,S3Prefix=<your S3 prefix>
As you can see, there is nothing overly difficult about exporting an AWS instance, but there are a lot of limitations to consider.
Figure out when to use EC2 Dedicated Instances