So, you want to migrate your workloads to AWS. Perfect! Even more so, as this process can be done for free, no matter what software you use. Some time ago AWS bought a company called CloudEndure. In their portfolio, they have a product called CloudEndure Migration. This solution helps you simplify, expedite, and automate large-scale migration to AWS. Continuous Data Replication takes place in the background, without application disruption or performance impact, which ensures that data is synced in real-time and minimizes cutover windows. When migration cutover is initiated, CloudEndure executes a highly automated machine conversion and orchestration process, allowing even the most complex applications and databases to run natively on AWS, without compatibility issues and with minimal IT skills necessary. Long story short – you can get your data for free into AWS without much effort. We tested this solution, and honestly, it works as advertised. But let’s start from the beginning.
How Cloud Migration Works
Let’s take a quick look at the following diagram, and start from the left.
We have our corporate soft, tender and silky-smooth Data Center or, as some people like to call it, Private Cloud. On this cloud, we run an application stack based on VM’s and some bare metal servers (yes we can migrate them as well). Now, we want to move it info AWS. In order to do that we need to setup CloudEndure application – it’s SaaS, so there is no need to install anything. After simple configuration (we will do it in a moment) two Areas are created – Staging and Target. Staging is responsible for receiving data form agents lying on-prem and packing those data into EBS volumes. During replication those volumes are connected to a CloudEndure proxy VM running on our AWS infra. Once replication is finished, we can start Test or Cutover – the final VM in AWS. All communications, both data-plane and config-plane, work over SSL.
Ok, enough with theory, let’s do some configuring. First, we need to install this software on our on-prem servers. This task is pretty easy – just install agent at the desired VM. Yes, this VM needs to have access to the Internet or VPN connection, or preferably Direct Connect. Then, we log into CloudEndure console:
After login we will see something like this:
Let’s create our first migration project. Hit (+) and give it a fancy name. I called mine Alulim, like the first and the oldest of the Sumerian Kings. Good, we have a fancy name. Now, we need to give it the power to operate. The first step is to create AWS Access KeyID and AWS Secret Access Key and put them in here:
This will allow CloudEndure to connect with our AWS Account. Of course, it’s best to use a dedicated account for Migration/DR purposes with a specific set of permissions. When we click Save, application is going to validate the keys and connect to our account. Good, our connection is set. Next move – replication settings:
Click on migration source and choose “Other Infrastructure”:
This means that you plan to copy from a non-AWS infra, in my case VMware, into Migration Target, here, it’s AWS EU (Frankfurt). More options appear below. If you want, you can change “Choose the Replication Server instance type” from default, which is c3.large, to something more convenient for you. I’ll leave it as it is. The same goes for dedicated replication servers and disk. One thing we will change tho:
Default subnet for CloudEndure Replication Appliance is a Subnet-INFRA-CloudEndure and SecurityGroup chooses a simmilar default option. If you are a security freak or your data contain a guide on „How to build a nuclear bomb out of old Pepsi cans and McDonald’s leftovers”, then you should definitely choose Enable volume-encryption. Last option is throttling – this feature allows you to limit bandwidth for replication. This is quite useful when you have a slow connection to your on-prem datacenter and replication traffic is likely to eat it all up.
Ok, final prep step and we are ready to go – agent installation on the source server. Go to Machines menu:
Here you have all of the necessary info on how to set up your agent on Linux and Windows machines. To set it up on Windows machine, download software, open the elevated command prompt, and run cmd:
After the installation your console should look like this:
Next, go back to CloudEndure. After you set up your first VM, the view will change to something similar to this:
Click on VM and check the Blueprint tab on the right side:
You’ll have a few obvious options. For us the most important one is subnet. Again, I created a dedicated subnet. If you choose a default option, Cloudendure will create it for you but with some crazy IP scope. When you move VM/server from your on-prem infra, you probably want to keep your old IP as well, so you wouldn’t have to reconfigure guest operating system and keep it like it was. This lowers the risk of migration failure and, in general, is a much easier approach. Let’s take a look into AWS Console:
During replication, we have one Replication Server up and running, and this EC2 have EBS volume attached:
Volume has the same size as a disk on source on-prem machine. But let’s go back to CloudEndure console. It’s been a while since the last sync, and we have some data to transfer. The good thing about CloudEndure is that it doen’t transfer the same data over an over again. Only new data and changed blocks are copied – this increased speed of operation is quite impressive. But still we need to wait a moment:
When ready, push the button „Launch target machine” and choose Test Mode:
This will create a new EC2 which you can see in AWS Console – it will appear as a Converter responsible for preparation of the VM:
And just a couple moments later we can observe our Windows-based VM up and running (activation is preserved):
If you feel comfortable with VM, you can push Launch in Cutover Mode – this means running a copied machine and terminating replication. And… Congrats! That’s all folks, your machine or application is lifted and shifted into cloud. Pretty cool and easy, huh? Next step, DR. Stay tuned.