AWS Application Migration Service (MGN) Hands-On

What is Cloud Migration?

Cloud migration is the process of moving a company’s data, servers, applications, databases, and workloads to a cloud provider's platform. Migration can be from on-prem to the cloud or from one cloud provider to another cloud provider.

Advantages of Cloud Migration?

Although the cloud has many advantages, I have listed the main ones below.

• Scalability,
• Cost-effectiveness,
• Disaster Recovery,
• Flexibility,
• Security,
• Maintenance,
• Speed and Agility,
• Reliability.

Cloud Migration Types?

The most common cloud migration types are;

• Rehost (Lift and Shift — Most preferred),
• Repurchase,
• Replatform (Similar to Rehost),
• Refactor,
• Retain,
• Retire.

In this hands-on, we will try to migrate an on-prem server (EC2 instance where we run WordPress and MySQL database containers in us-east-1) to another EC2 instance (us-east-1)using Application Migration Service with the rehost strategy.

We will create a simulated on-prem server (EC2 instance) with a Cloudformation template in GitHub repository.

Create a stack from the AWS CloudFormation Console with cloudformation.yml file that you copied/cloned from GitHub. In the UserData part of the on-prem server; we will install docker, docker-compose, git then will clone the docker-compose.yml from the GitHub repository and will run the “docker-compose up -d” command. Eventually, there will be 2 containers running on the EC2 instance (on-prem server). We will have WordPress container as frontend and MySQL container as backend.

After creating the stack, check the “Status check” of the EC2 instance is okay with “2/2 checks passed” and then copy the Public IPv4 address or Public IPv4 DNS of the EC2 instance and paste it on your browser.

Choose language and click the “Continue” button and fill in the blanks with the information below and log in to WordPress with “Username or Email Address” and “Password” (Username=admin, Password=12345678).

Click “Posts” on the navigation pane, edit “Hello world!” post, modify the content of the post (“I modified Hello world!”), update it and log out from WordPress. Copy the Public IPv4 address or Public IPv4 DNS of the EC2 instance again, paste it on your browser and check your modified page.

We need AWS credentials to install the Replication Agent on the source server. Create an IAM user with the name “mgn”, select AWS credential as Access key — Programmatic access, attach the AWS managed policy “AWSApplicationMigrationAgentPolicy” and download the .csv file which contains Access key ID/Secret access key. This managed policy will allow the installation of the Replication Agent on the source servers.

Switch to Application Migration Service, click “Settings” on the navigation pane then press “Edit template” button. Fill the replication settings template according to the image below and save the template.

Select “Source server” on the navigation pane then click “Add servers” button. Enter operating system of the source server (Linux), disks (Replicate all disks), IAM user (mgn) access key, and secret access key respectively.

Then connect your source server with ssh, download the installer with the first command and run it with the second command. When we run the second command, the installation of the AWS Replication Agent will be started, all volumes for replication will be identified, Replication Agent will be downloaded/installed, and synched with the Application Migration Service Console.

In the Application Migration Service console and check the source server (on-prem server) in the list. Application Migration Service will spin up a replication server that we defined in the replication settings template. The replication server will start to replicate the source server’s disk to an EBS that is attached to the replication server. It also creates a snapshot from the EBS volume. The replication process varies according to features such as disk size, features of the replication server, connection type, etc. After the replication is finished (initial sync) we need to see the source server’s migration lifecycle is “Ready for testing”, Data replication status “Healthy” and Next step “Launch test instance”.

Before launching the test instance we will configure the “Launch settings”. Select the Source server and click the “Launch settings”. For the “General launch settings” part, change the “Instance type right sizing” from Basic to None and save it. For the EC2 Launch Template click the “Modify” button.

Change the instance type to t3a.medium, select a public subnet (us-east-1a), under the Advanced network configuration enable Auto-assign public IP and select the security group that your source server has. After creating your template, set it as the default version.

To launch the test instance, select source server, click “Test and cutover” button, and hit the “Launch test instance”. This instance will be launched according to the launch settings template. Before that, a conversion server will be launched (it will convert the disk to boot) and then Application Migration Service will terminate the conversion server and will launch the test instance according to the Converted Snapshot.

You can test your WordPress with Public IPv4 address or Public IPv4 DNS of the test instance on your browser. You need to see the modified version of your WordPress page.

As long as the replication server is up, the replication process will continue. Any changes on the source server will continue to be detected and replicated.

If everything is fine with your test server, you can mark your source server as “Ready for cutover”. Application Migration Service will terminate the test instance. You can “Launch the cutover instance”. A conversion server will be launched and then Application Migration Service will terminate the conversion server and will launch the cutover instance according to the Converted Snapshot. You can test your WordPress with Public IPv4 address or Public IPv4 DNS of the cutover instance on your browser. You need to see the modified version of your WordPress page.

Lastly, we will “Finalize the cutover”. After finalizing the cutover, the replication server will stop replicating the source server.

Clean Up

Delete your stack from the CloudFormation console, it will also terminate the replication server. Terminate the cutover instance and delete all snapshots/volumes that AWS Application Migration Service created from the EC2 console. You can use your last Converted Snapshot as an AMI to launch your cutover instance again. To remove the source server from the list in the Application Migration Console, select the source server and mark it as “Mark as archived”.

Conclusion

In this hands-on, we migrated the on-prem server (EC2 instance) to AWS (another EC2 instance) using the Application Migration Service. As an on-prem server, we launched an EC2 instance and ran WordPress and MySQL containers with cloudformation.yml template. Next, we created a user (mgn) to install the replication agent on a source server. We configured the replication template from the Application Migration Service console. Then we installed the agent on the source server and enabled it to communicate with the Application Migration Console. The replication server that we configured in the replication template started to replicate the source server. After that, we launched a test instance from the converted snapshot. After testing the test instance, we launched the cutover instance and finalize the cutover.