By Samuel A.
AWS customers are in various stages of their cloud journey. Frequently, enterprises begin that journey by rehosting (lift-and-shift migrating) their on-premises workloads into AWS and running Amazon Elastic Compute Cloud (Amazon EC2) instances. You can rehost using AWS Application Migration Service (MGN), a cloud-native migration tool.
You may need to relocate instances and workloads to a Region closer in proximity to one of your offices or data centers. Or you may have a resilience requirement to balance your workloads across multiple Regions. This rehosting migration pattern with AWS MGN can also be used to migrate Amazon EC2-hosted workloads from one AWS Region to another.
We will show you how to configure AWS MGN for migrating your workloads from one AWS Region to another.
Overview of AWS MGN migration
AWS MGN, an AWS native service, minimizes time-intensive, error-prone, manual processes by automatically converting your source servers from physical, virtual, or cloud infrastructure to run natively on AWS. It reduces overall migration costs, such as investment in multiple migration solutions, specialized cloud development, or application-specific skills. With AWS MGN, you can migrate your applications from physical infrastructure, VMware vSphere, Microsoft Hyper-V, Amazon EC2, and Amazon Virtual Private Cloud (Amazon VPC) to AWS.
To migrate to AWS, install the AWS MGN Replication Agent on your source servers and define replication settings in the AWS MGN console, shown in Figure 1. Replication servers receive data from an agent running on source servers and write this data to the Amazon Elastic Block Store (EBS) volumes. Your replicated data is compressed and encrypted in transit and at rest using EBS encryption.
AWS MGN keeps your source servers up to date on AWS using nearly continuous, block-level data replication. It uses your defined launch settings to launch instances when you conduct non-disruptive tests or perform a cutover. After confirming that your launched instances are operating properly on AWS, you can decommission your source servers.
Steps for Migration with AWS MGN
This tutorial assumes that you already have your source AWS Region set up with Amazon EC2-hosted workloads running and a target AWS Region defined.
Migrating Amazon EC2 workload across AWS Regions include the following steps:
- Create the Replication Settings template. These settings are used to create and manage your staging area subnet with lightweight Amazon EC2 instances. These instances act as replication servers used to replicate data between your source servers and AWS.
- Install the AWS Replication Agent on your source instances to add them to the AWS MGN console.
- Configure the launch settings for each source server. These are a set of instructions that determine how a Test or Cutover instance will be launched for each source server on AWS.
- Initiate the test/cutover to the target Region.
Prerequisites
The following are the prerequisites:
- AWS Identity and Access Management (IAM) user with required credentials, as defined in the AWS MGN documentation
- A staging area subnet created in the target Region, as defined in the AWS MGN documentation
- A VPC and subnet in the target Region where target instances will be launched
- Security groups that will be attached to migrated instances.
- Network preparations in both Regions as defined in the AWS MGN documentation
Setting up AWS MGN for Multi-Region Migration
This section will guide you through AWS MGN configuration setup for multi-Region migration.
Log into your AWS account, select the target AWS Region, and complete the prerequisites. Then you are ready to configure AWS MGN:
1. Choose Get started on the AWS MGN landing page.
2. Create the Replication Settings template
3. Add source servers to AWS MGN. After successful agent installation, the source server is listed on the Source Servers page. Data replication begins after completion of the Initial Sync steps.
4. Monitor the Initial Sync Status:
5. Configure Launch Settings for each server:
6. Provide values for Launch Template:
7. Every time you modify the Launch template, a new version is created. Set the launch template that you want to use with MGN as the default:
8. Launch a test instance and perform a Test prior to Cutover to identify potential problems and solve them before the actual Cutover takes place:
9. Validate launch of test instance
10. SSH/ RDP into Test instance (view from EC2 console) and validate connectivity. Perform acceptance tests for your application as required. Revert the test if you encounter any issues.
11. Terminate Test instances after successful testing:
12. Validate the status of termination job and cutover readiness:
13. Perform the final cutover at a set date and time:
14. Monitor the indicators to validate the success of the launch of your Cutover instance (shown in Figure 9):
15. Test Cutover Instance:
16. Finalize the cutover after successful validation:
17. The cutover is now complete, and the migration has been performed successfully. Data replication has also stopped, and all replicated data will now be discarded.
18. Archive your source servers that have launched Cutover instances to clean up your Source Servers page.
Summary
In this post, we demonstrated how AWS MGN simplifies, expedites, and reduces the cost of migrating Amazon EC2-hosted workloads from one AWS Region to another. It integrates with AWS Migration Hub, enabling you to organize your servers into applications. You can track the progress of all your MGN at the server and app level, even as you move servers into multiple AWS Regions. Choose a Migration Hub Home Region for MGN to work with the Migration Hub.
Here are the AWS MGN supported AWS Regions. If your preferred AWS Region isn’t currently supported or you cannot install agents on your source servers, consider using CloudEndure Migration or AWS Server Migration Service respectively. CloudEndure Migration will be discontinued in all AWS Regions on December 30, 2022. Refer to CloudEndure Migration EOL for more information.
For more information on AWS Migration Services, please contact [email protected].
