With the recent release of Veeam 9.5 Update 4, long awaited cloud capabilities finally came to fruition. One example of this is the ability to restore a virtual machine into AWS as a native EC2 instance. I finally had the time to play around with this process in the lab, and it certainly works as advertised. Even with the restore to AWS option now natively available within the Veeam Backup and Replication console, there are still (as with just about anything) a couple of caveats to be aware of.
To begin this process, I deployed a new Windows Server 2016 VM in the lab. I didn’t do anything fancy, just had the base Windows install on the server and created a new text file on the desktop with a little blurb about this being a test VM for restoring into AWS.
Once the new VM was ready to go, I loaded up Veeam B&R and created a new backup job for this VM. I kicked off the job and let it complete the first backup run. As soon as I had a backup file available, I found my new backup, right clicked and selected Restore to Amazon EC2. With Veeam B&R there is typically more than one way to skin a cat, as there is also a large icon for Amazon EC2 within the Restore to Cloud menu option.
Starting this process brought up a familiar looking Veeam wizard, although with a host of new AWS specific options. The first step in the wizard is to choose the specific machine to restore into AWS. Since I had already essentially “chosen” that by right clicking my backup file, I started off with the next step which is choosing the AWS account and region to restore into. Interestingly enough, a warning pops up after this step about a “potential data sovereignty violation,” which I assume is just to remind users to be extra certain there are no reasons this data should not exist in a particular location. Once the AWS account is selected, you choose the name for the newly created EC2 instance, which by default is populated with the existing VM name. The next step is to select the EC2 instance type. Certainly this would have been a good reason to have run some kind of cloud optimization assessment against my on-prem workload for right sizing into the cloud, but for testing purposes I just selected an instance with the same CPU/RAM as provisioned within vSphere. Veeam gives an estimated monthly price for the instance, which allows you to consider cost and make changes before completing the restore.
The next step is to select the network settings for the restore. You must choose a VPC and corresponding subnet / security group within that VPC for the network settings. For testing purposes, I selected a subnet that I knew had public access and a wide open security group. In a real production migration scenario, I would spend some time ensuring the necessary security for this workload.
After the network settings are locked in, the wizard steps over to another cool feature in Update 4, Secure Restore. You have the option to scan the VM for malware prior to completing the recovery if you so desire. I did not enable this option, although it would be a cool feature to test out in the future. The final option is to select whether or not you want to use a proxy appliance to perform the restore. Veeam’s recommendation is to use the appliance, and this option similarly gives you the ability to select the instance type, subnet and security group for the appliance. In this test run, I got errors when selecting an appliance instance type <= restored VM instance type saying that the proxy did not have sufficient resources, so I selected a t2 instance one step up from my restore type, which allowed me to continue.
I kicked off the restore and immediately saw the progress window pop up to start the process. One of the first steps is Preparing proxy appliance VM, during which I bounced over to my lab AWS console and saw the new proxy EC2 instance spinning up.
The proxy appliance eventually deployed successfully, and the actual restore of the VM began. This would also be a good time to note that the Internet connection in my lab is not good (hard to justify a good Internet subscription for a lab), and I may have been better off running this whole thing off my cell phone. Just another reminder that YMMV depending on your infrastructure. Regardless, the process did complete successfully.
Switching back over to the AWS console showed a new EC2 instance with the same name as my on-prem VM and all of the characteristics I had defined within the restore wizard. The proxy appliance also appeared, but in a terminated state.
I clicked on my EC2 instance and clicked on the Connect button at the top of the console to download the RDP file. I entered the login creds, and BOOM! An error message pops up saying The function requested is not supported … This provided a little bit of troubleshooting and some great experience for things to consider prior to performing a restore to AWS, which I will post as a follow up to this.
I eventually fixed my login issues and was able to get to my desktop and open up the text file I had created while the VM lived on-prem, prior to the initial Veeam backup. Everything appeared as expected, just now running as an EC2 instance within AWS! Granted, this is a vanilla VM so there were no production workloads or any type of apps whatsoever, but the bits were still there. This proved that Veeam 9.5 U4 is more than capable of restoring/migrating VMs into AWS. At the end of the day, a little planning can go a long way towards making sure your workloads perform as expected when moved to the cloud, but Veeam makes the process of getting them there fairly pain free.
The blog was absolutely fantastic| Lot of great innovative information which can be very helpful. Thanks for sharing such wonderful information.