Migrate a WordPress Blog from Azure to AWS using AWS Application Migration Service

Introduction

In today’s fast-paced digital landscape, businesses are constantly seeking new ways to enhance their operations, optimize costs, and leverage the benefits of cloud computing. As organizations evolve, they often find themselves needing to migrate their virtual machines (VMs) from one cloud provider to another, such as moving from Azure or Google Cloud Platform (GCP) to Amazon Web Services (AWS).

However, embarking on a cloud migration journey can be a daunting task, filled with challenges and complexities. That’s where AWS Application Migration Service (AWS MGN) comes in as a powerful tool to simplify and streamline the migration process. AWS MGN simplifies, expedites, and reduces the cost of cloud migration by offering a highly automated, lift-and-shift solution. You can migrate an unlimited number of servers at no charge for up to 90 days per server.  Most customers complete server migration within this 90 day period, benefitting from free use of AWS Application Migration Service.

In this blog post, we will explore how to migrate virtual machines from Azure to AWS using AWS MGN. We will walk you through the steps, best practices, and key considerations to ensure a smooth and successful migration, empowering you to take full advantage of the rich capabilities offered by AWS.

Architecture Overview

AWS MGN simplifies the migration of servers from physical, virtual, and cloud-based infrastructure. The source infrastructure can be an on-premises data center, an AWS Region, or in this case, another cloud provider. Below is an architecture diagram showing how AWS MGN migrates a server to AWS.

Figure 1 – An architecture diagram that demonstrates how AWS MGN interacts with an on-prem or 3rd party cloud source server

The replication is performed by a lightweight agent installed on each source instance that is to be replicated. This AWS Replication agent communicates securely over port 443 using TLS, scans the source instance for all attached disks, and performs a block-level replication of disks in the target Region. After the initial replication is completed, the Replication agent monitors any changes to the source instance and replicates those changes. This ensures the data stored in the target Region is up to date.

Once the source and target are fully synced and in continuous data replication mode, you can initiate the cutover or a cutover test. Once the cutover or test is initiated, AWS MGN uses Amazon Elastic Compute Cloud (Amazon EC2) API operations to launch target instances and attach new Amazon Elastic Block Store (Amazon EBS) volumes.

Use Application Migration service to migrate virtual machines (VMs) from on-premises data centres or other cloud providers to AWS no matter the application or workload.

Solution overview

AWS MGN migrates this virtual machine to Amazon EC2. It also validates that the application data is synced and the comments copied to the target server.

The high-level steps you will follow are:

1. Setting up the AWS MGN replication environment.
2. Creating temporary credentials.
3. Installing the AWS MGN agent on your Azure virtual machine
4. Configuring Source Server Launch Settings
5. Launch test and cutover instances

Prerequisites

Creating a WordPress Site on Azure

To do a migration, first we must have a virtual machine in Azure hosting a sample WordPress website. To do this:

1. In an Azure account, type WordPress into the search bar.
2. Under Marketplace, select the “WordPress” option. Note, do not choose WordPress on App Service, as then we will not be able to access the VM.
3. Choose Create.
4. Enter a resource group name and a virtual machine name.
5. Under Administrator account, enter a username and a key pair name. This will be used later to connect to our instance.
6. Choose Review and Create.
7. You will be prompted to generate a new key pair. Choose the option to download the private key so that you can access your virtual machine later on.

Source Server Networking

To install the AWS MGN replication agent on your WordPress server, you will have provide access by configuring the networking settings. To do this:

1. In your Azure account, search for virtual machines.
2. Select the virtual machine with the name you gave when creating the WordPress document.
3. On the side bar, choose the Networking tab under Settings.

Figure 2 – Networking page for the source server running WordPress

4. Choose Add inbound port rule. On this page, set destination port range as 443, and choose TCP as the protocol.

• Ensure that the priority number for this rule is smaller than the DenyAllInBound priority.
• Next, choose the tab Outbound port rules and choose Add outbound port rule.
• Within this menu, set the destination port range as 1500, and the protocol as TCP. Leave the rest as default.

Section 1: Setting up the AWS MGN environment

Choose Get started on the AWS Application Migration Service landing page. You will automatically be prompted to initialize the service the first time you log into Application Migration Service.

Figure 3 – AWS MGN service initialization prompt.

Note that if this is not the first time in the AWS MGN area of the console, you can do this by going to the Replication template tab in the side bar, and selecting Reinitialize service permissions.

Initializing the service will create a replication template along with AWS Idenity and Access Management (IAM) roles. The template will determine how data replication will work for each newly added source server, and the IAM roles will give the required permissions to install the replication agent..

The configured replication settings can be changed at any time for any individual source server or group of source servers. Learn more about replication settings.

Section 2: Creating Temporary Credentials

To install the AWS MGN agent on our source server, first we need to create the required credentials. We’ll do this by creating an AWS IAM role with the installation permissions, which we can use to generate temporary credentials later.

1. Go to the AWS IAM section of the console.
2. In the side bar, choose the Roles tab under Access Management.
3. Choose the Create role button in the top right.

Figure 4 – AWS IAM Roles page where we can create a new role.

4. For the trusted entity type, select AWS account and then choose Next.
5. In the Permissions policies search bar, search for AWSApplicationMigrationAgentInstallationPolicy, and check the box next to it to select it. Then choose Next.
6. For role name type mgn_install. Then scroll down and choose Create role.
7. In the Roles search bar, search for the mgn_install role we just created, and choose it to access the summary.
8. In the summary page, copy the ARN for the next section.

• Optionally, you can also choose the edit button to increase the maximum session duration for the role if you think you will need more time.

Figure 5 – mgn_install role summary page where we can note the role ARN and also edit session duration.

Section 3: Installing the AWS MGN agent on your Azure virtual machine

Go to the AWS MGN page of the console. On the Source Servers page, choose Add server to obtain the agent installer link.

Figure 6 – AWS MGN Source servers page where we can add a new source server.

You will be presented with the AWS Replication Agent installation page.

Figure 7 – AWS Replication Agent installation page where we can provide the required credentials to generate an installer command for our source server.

Here, we will need to provide the IAM access key ID, IAM secret access key, and Session token from the IAM Role that we created in section 2. To do this we will request temporary security credentials through AWS Security Token Service (AWS STS) through the AssumeRole API. To do this:

1. Choose the CloudShell button in the bottom left of the console page to open up the command line interface (CLI).


Figure 8 – The AWS CloudShell interface that you can view by selecting the CloudShell button in the bottom left of the console page.

2. Insert the following command into the CLI:
   aws sts assume-role –role-arn [PASTE YOUR mgn_install ARN HERE WITHOUT BRACKETS] –role-session-name “mgn-install”
   This will output an AccessKeyID, a SecretAccessKey, and a Session token which you can paste into item 3 of the AWS Replication Agent Installation page (see figure 7).


Figure 9 – The cloudshell output after running the aws sts assume-role command.

3. Now that the access keys are embedded into the commands, we can install the replication agent on our Azure VM by copying and running the commands in items 5 and 6 of figure 7.

• Secure Shell (SSH) or Remote Desktop Protocol (RDP) into your Azure virtual machine. For guidance on how to do this, you can use the following documentation: https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux
• When you run the command in item 5 successfully, you should get the following output:

Figure 10 – Output for when successfully downloading the agent installer.

4. Similarly when running the command in item 6, you should get:

Figure 11 – Output for when successfully installing the replication agent.

5. After getting the prompt that the AWS Replication Agent was successfully installed, you will see the source server on the Source Servers page of AWS MGN. The initial sync will initiate.

Figure 12 – Source server name appearing in the active source servers list of MGN.

Once the agent is installed, it automatically scans all of the disks attached to the source instance. It begins replicating the data for all discovered disks.

Section 4: Configuring Server Launch Settings 

You want to configure these settings before launching your test and cutover instances. To access these settings, first select your source server name. From here you can navigate to Launch settings as seen in figure 13.

The launch settings are comprised of two parts: General launch settings, and EC2 launch template.

Figure 13 – Launch settings section of our source server.

For this use case you will leave the general launch settings as default.

1. For the EC2 launch template, scroll down to Network settings and choose Advanced network configuration.


Figure 14 – Network settings page within the EC2 launch template.

2. Here, you want to enable auto-assign public IP, as your WordPress server should be public facing. Then choose Create template version to save this as the new template version.


Figure 15 – Advanced network settings page.

3. After the template is configured, you have to open it to ensure that it is configured correctly. Do this by selecting the template name in the success notification that appears after you create the template version.


Figure 16 – The notification that is displayed after successfully modifying a launch template.

4. AWS MGN automatically uses the default version of the EC2 launch template. Your newly created template isn’t the default, so you have to go to Actions and choose Set default version. From there, select the latest template version from the dropdown, and choose Set as default version.

Figure 17 – Launch template dropdown menu showing where to set default version.

Section 5. Launching Test and Cutover Instances

First you will launch a test instance, and if that is successful, we move on to cutover. We want to do this so we can detect if there any issues or any required changes on the test instance before we finalize the process in cutover.

1. Verify that the server you are launching says Ready for testing under the migration lifecycle tab and that data replication status is healthy.
2. Next, select your server, and from the Test and cutover dropdown select Launch test instances.


Figure 18 – Selecting launch test instances from the test and cutover dropdown.

3. If the test is successful, you will see Launched in the Alerts You can also verify this by selecting your server and viewing the Migration dashboard tab. You should see Launch status: Succeeded, with the option to view the launched test instance in EC2 and open the public IPv4 address. This will be shown for the cutover instance later.

• (optional) If the test was unsuccessful, you will see an error message in the alerts column. Uou will see you can choose the option Revert to “Ready for testing” so that you can troubleshoot the server before trying again. For a list of errors and how to troubleshoot them, see here.

4. With the successful test, you can now go to the Test and cutover dropdown and select Mark as “Ready for cutover”. Next, select Launch cutover instances.As with the testing process, you will know that the cutover was successful when you see the Launched status under the alerts tab. You can also select our source server name and view the Migration dashboard. Here you should see Launch status: Succeeded.

Figure 19 – Selecting launch cutover instances from the test and cutover dropdown.

5. Now select your source server name from the list of source servers, and choose the view in EC2 hyperlink under the migration dashboard tab.

Figure 20 – The instance migration dashboard. Here is where we can navigate to the launched EC2 cutover instance.

6. From the instance summary page, you can see the public IPv4 address of your new instance, and use it to navigate to your WordPress page.

Figure 21 – EC2 summary page for our cutover instance. Here you can view its public IPv4 address.

7. If you navigate to the IPv4 address and the WordPress page is functional, then the cutover was successful. You can complete the migration by navigating back to the AWS MGN service in the console and going to Source Servers.
8. As previously, you select your source server, and from Test and Cutover dropdown, choose Finalize cutover. Finalizing the launch will clean up and discard any resources used to migrate the source server.

Figure 22 – Selecting finalize cutcover from the test and cutover menu.

Section 6: Cleaning up

1. To cleanup, select the source server, and from the Actions dropdown choose Mark as archived.
2. The server should no longer be visible in the AWS MGN console.
3. OPTIONAL: If you followed this with the intent of using the cutover instance, do not follow this step.
   However if you followed this guide as a learning exercise, then you must delete the target EC2 instance to avoid incurring costs for it and its associated EBS volume.
   You can do this by going to the EC2 dashboard and viewing instances. From there, select your instance and from the Instance State dropdown, choose terminate instance.

Conclusion

In this blog post, we walked through the key steps involved in migrating a virtual machine from Azure to AWS using AWS Migration Hub. We discussed how to set up the AWS MGN environment, install MGN agents on Azure VMs, and configure a Launch Template in AWS to facilitate the migration.

By handling tasks like compatibility assessments, data replication, and cutover automation, AWS MGN aims to simplify the process of migrating VMs between cloud environments. While this post focused specifically on migrating an Azure VM to AWS, MGN supports heterogeneous migrations between different environments including on-premises, Azure, GCP, and AWS. Organizations can evaluate their application portfolios and requirements to determine if and where AWS MGN fits into their cloud migration strategy and roadmap.

About the Authors