Case Study - AWS Application Migration Service (MGN)

haintkit

Hai Nguyen

Posted on August 23, 2022

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).

Image description

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:

AWS MGN

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:
Add Servers
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":

AWS Replication Agent installation

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:
AWS replication agent installation

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

Step 4: Checking the source server status in AWS MGN console:
Data replication status
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":
Source server
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.

Default launch template

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

migration lifecycle

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

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.
Image description

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

Step 8: Launch cutover instance and just wait for the instance running:
Image description
You can check the cutover job status here:
Image description
Image description

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

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

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.

💖 💪 🙅 🚩
haintkit
Hai Nguyen

Posted on August 23, 2022

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related