Accelerate VMware Migration to AWS with AWS Application Migration Service and the Agentless vCenter Client

20 minute read
Content level: Intermediate
3

This article will guide you through setting up and configuring agentless migration from VMware to Amazon EC2, demonstrating a streamlined process for seamless workload transition.

Introduction

In this guide, we'll explore how to set up and utilize the AWS Application Migration Service for migrating workloads from VMware Cloud on AWS to Amazon EC2. Note this guide will also work for your exisiting on-premises VMware based workloads. We'll start by setting up the service and deploying the AWS MGN vCenter Client in your VMware Cloud on AWS environment, once this is deployed, it allows you to manage the migrations for your VMware-based environments through the AWS console. I will show you how to configure the Replication Template, Launch temple and Post-launch template.

Once the initial setup is complete and the workloads are selected, I’ll walk you through the process of replicating these workloads to AWS using AWS Application Migration Service. This involves replicating your VMware workloads with the correct configuration of CPU, memory, networking and storage tailored to meet the demands of your workload in AWS. Once the initial replication is done, I will show you how to test the workload, and then finally cut over the workload to EC2 from VMware Cloud on AWS.

Migration Prerequisites

There are a number of prerequisites that should be considered with any migration:

  • Understand the networking requirements of your workloads and plan for the necessary network configuration in AWS. This includes VPC setup, subnets, routing tables, creating security groups, migrating exisiting security rules to AWS and any specific networking requirements like load balancing or VPN connectivity. Like any migration, networking is the area where most of the work and thought should be directed.
  • Changing of IP addresses, if you plan to change IP addresses during the migration, this will take some planning. If you plan to migrate entire networks to AWS from VMware Cloud on AWS, you might avoid changing IP addresses, though this still requires extensive planning.
  • Cost Optimisation: This is a great chance to do some optimisation, understand the pricing models of AWS services and perform cost analysis to optimise your spending. Consider reserved instances, spot instances, or other cost-saving strategies based on your workload requirements.
  • Security and Compliance: Evaluate the security and compliance requirements of your workloads and ensure that AWS meets those requirements. Familiarise yourself with AWS security services like AWS Identity and Access Management (IAM), AWS Security Groups, and AWS CloudTrail for auditing and logging.
  • High Availability and Disaster Recovery: Determine the high availability and disaster recovery requirements for your workloads and plan for the appropriate AWS services and configurations, such as Availability Zones, Auto Scaling, and AWS Backup.

Networking Prerequisites

Review the connectivity diagram below.

  • Staging Area Subnet: Create a dedicated subnet for AWS Application Migration Service (AWS MGN) as a staging area for data replication from source servers to AWS. Specify this subnet in the replication settings template.
  • Ensure the staging area subnet allows outbound traffic on TCP port 443 to the AWS MGN API endpoint. Source servers must allow outbound traffic to the staging area subnet and the AWS MGN API endpoint on TCP port 1500.
  • Operational Subnets: Test and cutover instances launch in subnets specified in the automatically created Amazon EC2 launch templates for each source server added to AWS MGN. More details for Network requirements can be found HERE

Enter image description here

Initial Deployment

The first four steps we need to complete are:

  • Activate AWS Application Migration Service
  • Configure Replication Template
  • Configure Launch Template
  • Configure Post-launch Template

Activate AWS Application Migration Service (MGN)

  1. Sign into the AWS console
  2. Change to the region you want to activate AWS MGN (this will most likely be the same region your VMware Cloud on AWS deployment is)
  3. Open the AWS MGN service Enter image description here
  4. On the right-hand side, select 'Get Started'
  5. Select Set up service. It will take about 1 - 2 minutes for everything to be setup, once completed you will see the message below. Enter image description here

Configure Replication Template

The replication template is a configuration template that defines the settings for replicating data from your source servers to AWS. By defining these settings in a centralised template, AWS MGN simplifies the configuration process and ensures consistent replication settings across multiple source servers. You can alter the Replication template per server as well, which allows for server-specific customisations when required.

  1. In the AWS MGN console, click on settings in the left hand menu and select Replication template
  2. Click Edit
  3. The replication settings template allows you to specify the following:
  • Staging Area Subnet: This is the dedicated subnet in your AWS account where AWS MGN will launch replication servers to receive and process the data replicated from your source servers.
  • Replication Server Instance Type: The EC2 instance type to be used for the replication servers launched by AWS MGN in the staging area subnet.
  • Replication Server Security Group: The security group to be applied to the replication servers, allowing necessary inbound and outbound traffic. Note: I have used the "Always use Application Migration Service Security Group" option
  • Data routing and throttling: This setting determines the data flow path from the external server to the replication servers. If you choose not to use a private IP, your replication servers will be automatically assigned a public IP, and data will be transmitted over the public internet. Alternatively, you have the option to set bandwidth throttling limits to regulate the network bandwidth utilised for data replication. Note: I have used Private IP as I have connectivity and routing configured from VMware Cloud on AWS to my AWS staging subnet via AWS TGW.
  • EBS Volume Configuration: Settings for the EBS volumes to be created and attached to the replication servers for storing replicated data.
  1. Once you have completed the above, click 'Save Template'

Configure Replication Template

The launch template plays a crucial role in defining the configuration for the test and cutover instances that will be launched during the migration process. You will generally modify the Launch template per source server (after they have been created in AWS MGN) as well, for things like assigning key pairs to your new EC2 instances.

  1. In the AWS MGN console, click on settings in the left hand menu and select Launch template
  2. Click Edit
  3. The launch settings template allows you to specify the following:
  • Activate instance type right-sizing, this will determine the best match instance type. If you don't want this, you can select the default instance type further down.
  • Start Instance upon launch, the default is to have turned the instance turn on
  • Copy Private IP, default is for this to be off
  • O/S licensing, either BYOL or use AWS provides license
  • Configure the default target subnet, security groups and any specific storage requirements. Note: I left these all as the default for this article.
  1. Click Save template

Configure Post-launch Template

The Post-launch template allows you to configure actions to be executed on every server, upon server launch

  1. In the AWS MGN console, click on settings in the left hand menu and select Post-launch template
  2. Click Edit
  3. Enable the toggle for installation of Systems Manager Agent
  4. For this article, I have selected the Deployment as Test and cutover instances Enter image description here
  5. Click Save template
  6. Once the above is completed you can configure and automate actions performed after the server is launched in AWS. You will see the options to create and action or use a templated action once you go back into the Post-launch template settings.

Deploy the Agentless vCenter client

We are now getting to the fun part, we are ready to deploy the AWS MGN Agentless vCenter Client.

Set IAM User

  1. The first step is to create a IAM user, to do this open AWS IAM in the AWS console
  2. Select users, then Create user
  3. Enter a User name (leave the "Provide user access to the AWS Management Console" un-ticked)
  4. Click Next
  5. Click Attach polices directly
  6. Search and select AWSApplicationMigrationVCenterClientPolicy and AWSApplicationMigrationAgentPolicy
  7. Click Next
  8. Select Create user
  9. Once created, open the user account and select the Security credential tab Enter image description here
  10. Click Create access key
  11. Select Command Line Interface, tick the "I understand the above recommendation and want to proceed to create an access key." message
  12. Click Next and Click Create access key
  13. You will need to save the Access key and Secret access key for the deployment

Install the vCenter Client

To install the vCenter Client, you must already have a virtual machine deployed; the vCenter client will be installed on the virtual machine. I have a used a basic linux virtual machine in VMware Cloud on AWS to act as the vCenter Client. The VM on which the AWS MGN vCenter Client is installed should meet the following RAM, CPU, and memory requirements:

  • Minimal requirements (these requirements will allow the replication of up to 5 servers in parallel) – 2 GiB RAM, 1 core, 10 GiB of free disk space
  • Optional performance requirements (these requirements will allow the replication of the maximum number of 50 servers in parallel) – 16 GiB RAM, 8 cores, 10 GiB of free disk space
  • Download the VMware VMware Virtual Disk Development Kit (VDDK) to the vCenter Client VM, you will need this during deployment. The download can be found HERE you will need a VMware login for this.
  1. SSH to the vCenter client VM
  2. Download the AWS MGN vCenter Client installer - https://aws-application-migration-service-(region).s3.(region).amazonaws.com/latest/vcenter-client/linux/aws-vcenter-client-installer-init.py
  3. For the above I used "wget https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/vcenter-client/linux/aws-vcenter-client-installer-init.py" Enter image description here
  4. To install the client run - sudo python3 aws-vcenter-client-installer-init.py
  5. Enter your AWS Access Key and Secret Access key you saved from the user you created earlier
  6. Enter the AWS Region for Deployment. This should be the same region VMware Cloud on AWS is in, unless you are migrating to a different region
  7. Enter the VMware Cloud on AWS vCenter IP or URL (I have used the URL, which is set to private in the VMware Cloud on AWS console)
  8. Enter the Port (443)

Enter image description here

  1. Enter the vCenter Username and Password
  2. Enter past the "Enter path to vCenter root CA certificate"
  3. Enter the path the VDDK tarball (make sure you include the file name i.e : "/path/to/VDDK/VMware-vix-disklib-7.0.3-21933544.x86_64.tar.gz"

Enter image description here

  1. Optional - Enter resource tags for the AWS vCentere Client
  2. Optional - Enter resource tags for source servers to be discovered by the AWS vCenter client
  3. Note: For the article I left the tags blank
  4. This will now download the AWS vCenter Client, install it, and register it with the AWS Application Migration Service. This should take about 2 minutes to complete. Give it about 15 minutes before you move on to the next step to allow the inventory to start (and potentially finish) collecting in the AWS MGN console.

Enter image description here

  1. To confirm you are now retrieving inventory details from your VMware Cloud on AWS vCenter, go back to the AWS MGN console, and select source servers

  2. Most likely you will see no source servers, don't worry this is easy to fix. On the drop down that shows "Active Source Servers" select "Agentless Source Servers"

Enter image description here

  1. You should now see all the inventory from your VMware Cloud on AWS vCenter. If you can see some of your inventory but not all, it most likely is still being loaded, so give it some time.

Ready to Migrate

If you have made it this far, well done. We are now ready to start to migrate virtual machines from VMware Cloud on AWS to EC2. Before we do that though, let me explain the way that MGN will work, this will be a 3 step process:

  1. Start the replication, this process performs an “initial sync” which sends the entire disk contents of the replicating VM into AWS. Following snapshot shipping processes will leverage CBT in order to only sync disk changes to the customer’s target AWS account. This means that MGN is continually shipping snapshot data from VMware Cloud on AWS to MGN , before you decide to do the final cutover.
  2. Test the instance / workload once the initial sync has completed
  3. Cutover the instance / workload when you have completed your testing and are happy everything is working as expected

There are two main ways we can start to replicate virtual machines from VMware Cloud on AWS to EC2, using MGN. The first way is to the find and select the source server in MGN, under "Source servers" (remember you need to choose from the drop down menu "Angetless discovered servers") once you have selected the servers you can then choose to replicate these. The second way is my preferred option as it allows you to setup you migration in waves, which allows you to migrate all the virtual machines that make an application, together.

Create a Application

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Applications from the left hand menu
  3. Select Add application Enter image description here
  4. Give the Application a name & description
  5. From the Servers drop down menu select the virtual machines that make up this application (If you have a naming convention for these servers type this in the search field to narrow down the number of virtual machines displayed) Enter image description here
  6. Select Add application, repeat this for any other applications you want need to migrate
  7. You should now see your list of applications Enter image description here

Create a Wave

Next we must create our migration waves, which can be made up of one or more applications

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu
  3. Select Add wave Enter image description here
  4. Give the Wave a name & description
  5. From the Application drop down menu you will see the applications that you created in the previous step, select the applications that will make up this migration wave Enter image description here
  6. Select Add wave, repeat this for your other migration waves
  7. You should now see your list of migration waves Enter image description here

Start replication

Now that you have setup your applications and your migration waves, you can start to replicate your selected applications.

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu
  3. Select the Wave or waves you want to start to replicate (this won't cut over your applications, it will only replicate the data)
  4. From the Actions drop down menu, select "Start data replication" Enter image description here
  5. Once this replication begins you can track it from the console, by clicking on the wave name (wave 1)

Enter image description here

  1. If you click on "Source servers" you can see more granular information on what is the status of the replication Enter image description here
  2. If you then click on one of the source servers you can then become even more granular of that specific server Enter image description here
  3. Once the initial sync is complete you will see the source servers are in a "Migration lifecycle" state of "Ready for testing" . You can also see in the image below, the time that the last snapshot was taken, this will continually take snapshots (changed blocks only) until you do the final cutover. Enter image description here

Preparation for Testing

Now that we have our initial syncs done of both our migration waves, we are ready to perform some testing. You will need to come up with your own testing criteria at this point, some suggestions though what to test:

  • Test instances successfully boot and can be accessed (SSH, RDP, etc)
  • Connectivity between the different instances in the application
  • Application specific testing, if doing benchmark tests, make sure you have run these same benchmarking tests in VMware Cloud on AWS
  • Application user acceptance testing, get your application owners or end users to test the application to ensure it works as expected

Now you have your test criteria ready, we can start to launch our test instances. One other thing to do before we click the "launch test instances" button, is to modify our EC2 launch template on the instances, this allows us to assign specific settings for each instance, such as key pairs.

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu, select the wave you are going to test
  3. Select the Source servers tab
  4. Select one of the source servers, and once this source server opens, select the Launch settings tab Enter image description here
  5. Select Modify under the EC2 Launch Template section, this will open a new browser tab
  6. Once the new tab opens, you can edit any of the launch template settings required, including creating or selecting a key pair
  7. Once complete, select Create template version
  8. Repeat this for any of the other source servers in your migration waves that requires any changes to their launch templates

Launch Test instances

You should now have everything setup for testing, including your test plan, lets begin

  1. Open the AWS console and open the AWS Application Migration Service

  2. Select Waves from the left hand menu, select the wave you are going to test

  3. Select the actions drop down menu, and select Launch test instances Enter image description here

  4. You will see a popup window, review the information and when ready, select Launch

  5. In the waves section in AWS MGN you can track the progress of the testing process, even more granular view can be seen when you select individual source servers

  6. While the test EC2 instance is being deployed you will see the below view on each source server, notice Launch Status shows "Waiting" Enter image description here

  7. Once all the source servers are ready for testing, in your migration wave view, under source servers you should see the "Migration lifecycle" show "Test in progress" Enter image description here

8.Select one of the source servers, you will see the below, notice the Launch status is "Launched" with the option to view in EC2 console, click on this to open the testing instance in the EC2 console (this will open a new tab in your browser) Enter image description here 9. You can now start your testing regime on your instances 10. Once your testing is complete you can now move to the next step which is cutover

Prepare for cutover

Well done, all your testing is complete, we are ready to move to the next stage. BUT! if you are not ready for the next stage, and want to roll the migration back from testing, do the following:

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu, select the wave you are going to roll back from testing
  3. Select the Actions drop down menu, and select Revert to "Ready for testing". This will delete the EC2 instances that were created, the snapshots between VMware Cloud on AWS and AWS MGN have continued through the testing phase, so you don't need to do anything else Enter image description here

If you are ready for cutover, lets begin.

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu, select the wave you are ready to cutover
  3. Select the Actions drop down menu and select Mark as "Ready for cutover" Enter image description here
  4. A popup will appear asking if you would like to delete the test EC2 instances, select to either terminate or to keep the EC2 instances, click Continue. (For this article selected to terminate launched test instances, which is the default option)

Enter image description here

  1. This will now terminate the test EC2 instances (if you selected the option) it will also move the "Migration lifecycle" state to "Ready for cutover"

Enter image description here 6. Within your migration wave console, select the Actions drop down menu, select "Launch cutover instances" 7. You will now notice the "Migration lifecycle" status is changed to "Cutover in progress" 8. Once your source servers are ready for cutover, they will display the "Launched" Status, wait for all your source servers in your migration wave to reach the same status Enter image description here 9. Before we perform the final cutover, open the Amazon EC2 Console and SSH or RDP into your cutover instances in order to ensure that they function correctly. Validate connectivity and perform acceptance tests for your application. 10. If you need to roll back, you can do this via the Actions Menu, by selecting Revert to "Ready for cutover"

Final Cutover

Once you have completed all your testing on your cutover EC2 instances, you are ready to perform the final cutover:

  1. Open the AWS console and open the AWS Application Migration Service
  2. Select Waves from the left hand menu, select the wave you are ready to cutover
  3. Select the Actions drop down menu and select Mark as Finalize cutover Enter image description here
  4. Once the cutover is complete you should see all of your source servers displaying the "Migration lifecycle" status or "Cutover Complete"
  5. If you view you migration wave console you should see the Migration status as "Completed" Enter image description here
  6. You are now ready to go through the process with your remaining migration waves

Conclusion

In conclusion, we've navigated through the complete process of migrating virtual machines from VMware Cloud on AWS to Amazon EC2, utilising AWS Application Migration Service. From setting up and configuring the AWS MGN vCenter Client to managing the detailed steps of replication and testing, this guide should give you the knowledge to execute a streamlined and efficient migration.

Thank you for spending the time going through this guide, I trust it has provided you with a clear pathway and practical insights to optimise your cloud infrastructure, harnessing the full spectrum of benefits that cloud computing has to offer. As you continue to adapt and refine your cloud strategy, remember that each step you take is a move towards more scalable, efficient, and cost-effective IT operations.

1 Comment

Can we please add the limitations :

AWS MGN partially supports vMotion, Storage vMotion, and other features based on virtual machine migration (such as DRS and Storage DRS) subject to the following limitations:

Migrating a virtual machine to a new ESXi host or datastore after one replication run ends, and before the next replication run begins, is supported as long as the vCenter account has sufficient permissions on the destination ESXi host, datastores, and datacenter, and on the virtual machine itself at the new location.

Migrating a virtual machine to a new ESXi host, datastore, and/or datacenter while a replication run is active – that is, while a virtual machine upload is in progress – is not supported. Cross vCenter vMotion is not supported for use with AWS MGN.

replied a day ago