Case Study - AWS Application Migration Service (MGN)

In this post, I will demonstrate how AWS Application Migration Service (MGN) helped me out from the issue which I got in the project.

1. My issue
As you may know, in order to launch the instance with these kind of OS (e.g. CentOS, SUSE, RedHat), an AMI subscription from AWS Market Place must be required. I subscribed AMI CentOS 7 Updates HVM published by AWS and then launched an EC2 instance with this OS. A lot of applications and middleware was installed on the instance, and an AMI was created for further use.

A few weeks later, I needed to share the AMI (including applications and middleware) to new AWS account. The customer tried to restore the instance using the shared AMI but it was failed because that CentOS 7 Updates HVM image published by AWS was no longer available for a new customer at that time.
(Note: At the time I write this post, CentOS 7 Updates HVM image by AWS come back available for new customer).

So, how could the customer restore the instance with unavailable base image? The only way was to create a new instance with available image in AWS Market Place. But, installing applications and middleware from scratch is a nightmare to our customer.

It's time for AWS MGN to action! Let's started.

2. Introduction to AWS MGN
Previously, CloudEndure (https://www.cloudendure.com/) or AWS Server Migration Service (AWS SMS) was migration tools to replicate the servers from on-premises and other clouds to AWS. In 2019, AWS acquired CloudEndure and continue developing the product. In March 2022, AWS introduced a new migration powerful tool, namely the AWS Application Migration Service (AWS MGN), which is now highly recommended as the primary migration service for lift-and-shift migration to AWS. Customers are encouraged to use AWS MGN for further migration.

AWS MGN enables the customers to migrate their applications to AWS with minimal downtime and without having to make any changes to the applications and the source servers.

Refer to the official link for more information: https://aws.amazon.com/application-migration-service/?nc1=h_ls

3. How I used MGN to replicate the data:
AWS MGN will replicate every applications, middleware, and config files from old server to new one. It helped my customer avoid their nightmare. The below diagram shows my scenario:

The components are:

• Source server: The applications and middleware were running on. AWS replication agent has to be installed in the server to communicate with AWS MGN Service Manager via TCP port 443, with replication server via TCP port 1500 for data replication, and with S3 via VPC gateway endpoint.

• Replication sever: The server stays in Staging Area to continuously replicate the data from source server. It will connect to MGN Service Manager via TCP port 443 and with S3 via VPC gateway endpoint. The replicated data will be stored in EBS volume.

• Destination server: When data replication finish, I will do cut-over to launch a new server based on the pre-defined launch template. The EBS volume, which stores the replicated data, will be mounted to new server.

Let's go to step-by-step in AWS management console:

Step 1: Go to AWS Application Migration Service --> Add source server:

Installing replication agent in source server. The agent needs some permission to communicate with AWS MGN service Manager, so an IAM credentials (access key and secret key) is required. Following the guideline to create the required IAM credentials: https://docs.aws.amazon.com/mgn/latest/ug/credentials.html
or click on "Create IAM user":

Step 2: Download "aws-replication-installer-init.py" file:

wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-ap-southeast-1.s3.ap-southeast-1.amazonaws.com/latest/linux/aws-replication-installer-init.py

Step 3: Running the file using python3:

sudo python3 aws-replication-installer-init.py --region ap-southeast-1

Following the guideline from CLI, entering the above IAM credentials and disks which will be replicated:

If the agent is installed successfully, it should be like this:

Step 4: Checking the source server status in AWS MGN console:

It shows the initial sync between source server and replication instance is finished and then the replication server is creating a EBS snapshot. Just wait for migration lifecycle status to be Ready.

Meanwhile, I had to configure EC2 launch template which defines instance specifications of destination server. Click on source server and go to tab "Launch setting", and then move to "Modify" of "EC2 Launch Template":

Note that you must mark the latest version of launch template to be default in order for AWS MGN to recognize it.

Step 5: Checking migration lifecycle of source server, making sure the status ready. It should be "Ready for testing" like this:

Step 6: I run "Launch test instances" to check the replication status:

You will see one m4.large instance in initializing status. It is AWS MGN conversion server, which converts the disks to boot and run on AWS. In particular, it makes bootloader changes, injects hypervisor drivers and installs cloud tools. Refer to the document: https://docs.aws.amazon.com/mgn/latest/ug/AWS-Related-FAQ.html#What-Conversion-Server-Do
The instance will be terminated as soon as the conversion job finishes.

Step 7: Make sure status of Alerts "launched". It means that successfully launched test/ cutover EC2 instance. Next, mark as "Ready for cutover":

Step 8: Launch cutover instance and just wait for the instance running:

You can check the cutover job status here:

Step 9: Make sure cutover progress finishes with successfully launched cutover EC2 instance like this:

Step 10: I finalized cutover by clicking on "Finalize cutover":

Finally, I connected to the destination server (cutover instance) to verify the data. It was amazing!!! Every data was replicated to the cutover instance same as source one.

4. Conclusion
In this post, I demonstrated my real case study regarding AWS Application Migration Service (MGN), which successfully replicated the data (applications and middleware) from source server to new one. It helped my customer save much efforts compared to installing everything from the scratch.