How to migrate on-premises workloads with AWS Application Migration Service
Often public sector customers like state and local government agencies can lack cloud skilled IT staff and are seeking guidance on how to move their workload from an on-premises data center to Amazon Web Services (AWS). In April 2021, AWS launched AWS Application Migration Service (AWS MGN), a highly automated lift-and-shift (rehost) solution that simplifies, expedites, and reduces the cost of migrating applications to AWS. It enables companies to lift-and-shift a large number of physical, virtual, or cloud servers without compatibility issues, performance disruption, or long cutover windows. AWS MGN is based on CloudEndure Migration and improves on it by integrating with the AWS management console. For public sector customers, this provides an integrated solution with security and flexibility. MGN provides the flexibility to operate from within the AWS Management Console, control permissions and access using AWS identity and access management (IAM), and monitor AWS MGN using Amazon CloudWatch and AWS CloudTrail.
Lift-and-shift (also known as “rehost”) is a common approach for migrating to AWS, whereby you move a workload from on premise with little or no modification. In a large legacy migration scenario where the organization is looking to scale its migration quickly to meet a business case, we find that the majority of applications are rehosted when moving to the cloud, to minimize risk and speed up time to production. GE Oil & Gas, for instance, found that even without implementing any cloud optimizations, it could save roughly 30 percent of its costs by rehosting.
AWS MGN is a highly automated lift-and-shift solution, which works by replicating your on-premises (physical or virtual) and/or cloud servers (referred to as “source servers”) into your AWS account. When you’re ready, AWS MGN automatically converts and launches your servers on AWS so you can quickly benefit from the cost savings, productivity, resilience, and agility of the cloud. Once your applications are running on AWS, you can leverage AWS services and capabilities to quickly and easily replatform or refactor those applications.
This guide teaches you how to migrate a content management system platform (CMS), based on an example with WordPress, running on a simulated on-premises environment to AWS Cloud, using AWS Application Migration Service (MGN).
Migrate your on-premises workload walkthrough
In this walkthrough, the example WordPress blog is currently running as a two-tier stack in a simulated on-premises data center. The frontend uses Apache Server running on Ubuntu 16.04 LTS and the backend is supported by a mySQL server running on Ubuntu 16.04 LTS. All systems are hosted on a virtualized platform in a simulated data center.
The key steps of this migration process are:
- Create IAM user for AWS Replication Agent
- Create the Replication Settings template in the AWS MGN Console
- Install the AWS Replication Agents on source servers
- Configure the Launch Settings in the AWS MGN console
- Launch the test instances
- Launch the cutover instances
- Finalize cutover
For this walkthrough, complete the following prerequisites:
- Have an AWS account
- Have a clear understanding of Amazon Virtual Private Cloud (Amazon VPC)
- Create the virtual networking environment for the purpose of this walkthrough as shown in Figure 1:
- Create Amazon VPC, MGN-Demo VPC.
- Create three subnets in the MGN-Demo VPC, Staging Area Subnet, Migrated Resources Public Subnet and Migrated Resource Private Subnet
- Create Internet gateway and attach it to the MGN-Demo VPC
- Create two Route tables, Public-MGN-Demo-RouteTable and Private-MGN-Demo-RouteTable
- Add internet route to the Public-MGN-Demo-RouteTable (Destination 0.0.0.0/0 with Internet gateway as target)
- Associate the Staging Area Subnet and Migrated Resources Public Subnet with the Public-MGN-Demo-RouteTable
- And associate the Migrated resource private subnet with the Private-MGN-Demo-RouteTable
- Launch an Amazon Elastic Compute Cloud (Amazon EC2) instance as a Bastion host in the Migrated Resources Public Subnet
- Create two security group, Public-MGN-Demo-SG and Private-MGN-Demo-SG
- Add inbound rules for HTTP and HTTPS ports from anywhere (0.0.0.0/0), and SSH port from the Bastion host public IP address to the Public-MGN-Demo-SG.
- Add inbound rules for MYSQL ports from Public-MGN-Demo-SG security group to the Private-MGN-Demo-SG and SSH port from the Bastion host private IP address.
- AWS MGN requires network connectivity to and from your on-premises environment and within your Amazon VPC. For more information on the detailed network connectivity requirement, check the Network Requirement Guide.
Figure 1 – AWS MGN migration architectural diagram.
Create IAM user for AWS Replication Agent
You need AWS credentials to use AWS MGN. Create an AWS Identity and Access Management (IAM) user and assign the proper permission policy to the user. Obtain an Access Key ID and Secret Access Key, which you would need to enter during the AWS replication agent installation on the source servers. Follow the steps found in generating the required AWS credentials.
Create the replication settings template
To migrate your servers from on-premises or another cloud service provider, create your replication settings to initialize the service for the first time in the AWS MGN console. You can access AWS MGN through the AWS console.
Install the AWS replication agents
After AWS MGN has been initialized with the creation of the replication settings template, and you have generated the required AWS credentials with the necessary permission, now install the AWS replication agent on the source servers on-premises. There are separate installation instructions for Linux and Windows operating systems:
For the illustration, both source servers are running on Ubuntu 16.04 LTS. The Linux installation steps are as follows:
1. Download the agent installer.
wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-us-east-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Remember to replace the region with the AWS Region into which you are replicating; in this walkthrough the replication is set to us-east-2.
2. Once you download the agent installer, run the installation script.
sudo python3 aws-replication-installer-init.py
3. The installer prompts you to enter your AWS Region Name, the AWS Access Key ID, and AWS Secret Access Key. Use the Access Key and Secret Access Key that you saved earlier.
4. Once you have entered the credentials, the installer identifies the volumes for replication, and prompts you to choose the disks to replicate, press enter.
Repeat the same AWS replication agent installation process on all source servers.
After installing the AWS replication agent on the source servers, return to the AWS MGN console to validate the source servers in the console. Please note that the source servers are added to the AWS MGN console by installing the AWS replication agent on the source servers.
Figure 5 – Validating agent installation in MGN console.
After the initial sync is complete, the migration lifecycle displays Ready for testing and the data replication status displays as Healthy.
Configure the launch settings
Prior to testing or cutting over an instance, configure the launch settings. The launch settings are a set of instructions that determine how a test or cutover instance is launched for each source server in AWS.
Launch settings are comprised of two sections: general launch settings and Amazon EC2 launch templates.
Select each server, and select the tab for Launch Settings to edit the launch settings.
Figure 7 – Configuring launch settings for each source server in MGN console.
For this walkthrough, we will keep the default settings for the general launch settings. And, we will be making changes to the Amazon EC2 launch template, to place the App Server and DB Server in the right subnets, which you have created with the necessary security groups.
Amazon EC2 launch template modification for the App Server (source server):
Starting with the App Server, select modify in the Amazon EC2 Launch template window.
This would launch a new window for the Amazon EC2 Launch templates. Add a description for the Template version description.
Navigate down to Network Interfaces. Under Subnet, choose the respective subnet, Migrated Resources Public Subnet for the app server, the Public-MGN-Demo-SG for Security groups, and select Enable under Auto-assign public IP for the public facing app server. Once done, select Create template version.
This launches a new window that shows you have successfully modified the EC2 Launch Template. Now, you would go ahead to change the default version that the EC2 launch template would use, select View Launch Template.
In the Launch template window that shows up, select the launch template ID, and select Actions in the top right corner, and then select the Set default version.
Hint: If you have more than one launch template ID, and you do not know the right one, return to the MGN console, select the right Source Server, under its Launch Settings, you would find the right Launch template ID.
The Set default version dialog box appears; select the Template version you just created and set as default version.
Return to the AWS MGN console and select the source server for the app server. Under launch settings, find the updated Amazon EC2 Launch Settings.
Amazon EC2 launch template modification for the DB Server (source server):
Repeat steps 1-9 to configure the launch settings for the DB Server.
1. Return to the MGN console and select the source server for the DB Server
2. Select the Launch Settings tab
3. Select Modify under the EC2 Launch Template
4. Add a description for the Template Version description
5. Navigate to Network Interfaces:
a. Under Subnet, choose the respective subnet, Migrated resource private subnet for the DB Server,
b. The Private-MGN-Demo-SG for Security groups
c. And leave the auto-assign public IP as disabled for the DB Server in a private subnet.
d. Once done, select Create template version.
6. On the successfully modified Amazon EC2 Launch Template page, select View Launch Template.
7. In the Launch template window, select the launch template ID for the DB Server, and select Actions in the top right corner, and then click on the Set default version.
8. The Set default version window dialog box appears. Select the Template version you just created and set as default version.
9. Return to the AWS MGN console. Select the source server for the DB Server; under launch settings find the updated EC2 Launch Settings.
Launch the test instances
Now, that you configured the launch settings for each source server, you are ready to launch the servers as test instances. Best practice is to test instances before cutover.
On the MGN console page, make sure that your source servers are ready for testing by looking at the following indicators as shown in Figure 14. The source servers are Healthy and Ready for testing.
Check the boxes to the left of each server that you want to launch a Test Instance.
Select Test and Cutover in the top right corner, then select Launch test instances.
Select Launch in the Launch test instances dialog box.
This takes you back to the MGN console page with the source servers. Make sure that the Migration lifecycle indicates that Test in progress, then select View job details in the top right corner to view the MGN job log details.
Check the job status as it changes from Started to Completed. You can also view the job logs for more details.
Once completed, return to the MGN console Source Server page. Now the Alerts show up as Launched.
Making configuration updates to the WordPress App Server with the new DB Server host:
- On the MGN console, select the test DB source server to access the Migration Dashboard.
- Under Lifecycle, select View in Amazon EC2 console to see the Amazon EC2 page.
- Obtain the private IP address for the DB Server; you will be updating the WordPress app server configuration file with this information.
- Return to the MGN console, select the test app source server to access the Migration Dashboard.
- Under Lifecycle, select View in Amazon EC2 console to see the Amazon EC2 page.
- Obtain the public IP address.
- Login to the test app server for WordPress, and update the database connection string:
sudo vi /var/www/html/wp-config.php
- In the wp-config.php file, update the test DB Server IP address.
Figure 20 – Changing the database host in wp-config.php.
Updating grant privileges in mySQL database:
Update your grant privileges in mySQL database for the test app server to assess the test database.
- Login to the database using the root password:
sudo mysql -u root -p
- Grant all privilege on the mySQL database for WordPress user. Replace DB_NAME with database name, DB_HOST with database IP address, and DB_PASSWORD with the password for the database.
GRANT ALL PRIVILEGES ON '<DB_NAME>'@'<DB_HOST>' IDENTIFIED BY 'DB_PASSWORD';
- Flush privileges to reload the grant tables.
Figure 21 – Updating grant privileges in database.
Launch the app in a web browser using the public IP address of the test app server.
Figure 22 – Launched test server webpage in browser.
With a successfully launched application in the web browser, you can select Mark as “Ready for Cutover”. Cutover.
Figure 23 – How to select servers and mark them as “Ready for cutover:” check the boxes next to the server hostname; select the “Test and Cutover” dropdown menu, and then from the dropdown, select “Mark as ‘Ready for Cutover.’”
When the “Mark servers as ready for cutover” dialog box appears, choose continue. The source servers show up as ready for cutover in the MGN console.
Launch the cutover instances
After completing the testing of all the source servers, you are ready for cutover. Prior to launching cutover instances, ensure that the source servers are listed as Ready for cutover under Migration lifecycle and Healthy under Data replication status.
Once confirmed, check all source servers to be cutover, and then select Launch Cutover instances from the Test and Cutover dropdown menu.
The Launch cutover instances dialog box appears. Choose Launch to start the cutover.
On the MGN console, the source servers show up as Cutover in progress. Select view job details in the top right corner of the page to view the job details.
Once the job is completed, return to the MGN console page. The Alerts show up as Launched.
Follow the same steps for ‘Making configuration updates to the WordPress App Server with the new DB Server host’ and “Updating grant privileges in mySQL database’.
Once you’re finished with the updates to the app and DB Servers, and connectivity is confirmed using a web browser to launch the application, and all other performance test has been performed, you can now make changes to the DNS records to point to the new app server.
Now that you have successfully performed a cutover, you can finalize the cutover. This changes the source servers Migration Lifecycle status to Cutover complete. In addition, this terminates the Replication Server and all data replication is stopped and discarded.
In the MGN console, select the boxes next to the source servers that you want to finalize cutover. Select Finalize cutover from the pull down menu under Test and Cutover.
When the Finalize cutover dialog box appears, choose Finalize. This changes the source servers Migration Lifecycle status to Cutover complete.
Figure 32 – Finalize the cutover for selected servers.
For cleanup, mark the source servers as archived. Archiving prevents the servers from being shown in the servers list page.
In the MGN console, check the boxes next to the source servers that you want to mark as archive, archiving servers prevents them from being shown in the servers list page. Select Mark as archived from the dropdown menu for Actions.
When the Archive Dialog box appears, choose Archive.
The source servers are now archived and removed from the MGN console page.
To avoid incurring future charges, delete the resources that we have created during the walkthrough and remove credentials created:
- Terminate the launched instances in MGN console
- Delete Amazon VPC and all associated resources
- Delete IAM User created for the AWS replication agent
You have now successfully migrated a content management system platform from on-premises (Simulated Cloud environment) to AWS using AWS Application Migration Service (MGN). Further modernization efforts can be performed in the AWS Cloud environment, by introducing auto-scaling and load balancing to the application layer to provide high availability; offload your media content to Amazon Simple Storage Service (Amazon S3); improve end-user experience with a content delivery network, Amazon CloudFront; secure your website using AWS Certificate Manager; and replatforming the Amazon EC2 based mySQL Database to Amazon Relational Database Service (Amazon RDS).
Get started on your migration journey with AWS Application Migration Service (MGN). Do you have questions about if MGN is a good fit for your organization’s needs? Reach out to us.
Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.