Accelerating Blue/Green Deployments with AWS MGN Post-Launch Actions

Customers are becoming more aware of the benefits of migrating to AWS in a world increasingly pivoting towards cloud adoption. A recent whitepaper by IDC found that customers who migrate to AWS can experience a 51% reduction in the cost of operations, a 62% increase in IT staff productivity, and a 94% reduction in downtime. With these gains in mind, AWS has been helping organizations migrate their workloads to the cloud since 2008 – longer than any other cloud provider, and we’ve learned a lot. With challenges ranging from organizational aspects, such as training and certification, to technical hurdles, such as developers learning to work with services that may be new to them, AWS has made significant strides toward alleviating the barriers to migration.

The core business challenge this post addresses is the need for a streamlined and efficient server migration process, focusing on implementing Blue/Green deployments. Migrating servers, especially from on-premises environments to the cloud, can be complex, time-consuming, and error-prone. Traditional migration approaches often lack the flexibility to seamlessly switch between the old and new environments. This post, centered around AWS Application Migration Service (AWS MGN) and related AWS services, aims to simplify and expedite the migration process while incorporating Blue/Green deployment principles. Leveraging automation and tailored post-migration actions reduces the operational burden, minimizes downtime, and enables a seamless transition to AWS. This helps businesses modernize their infrastructure and empowers them to adopt Blue/Green deployments, allowing for safe, efficient, and risk-free updates to their applications and services.

Solution Overview

In part one of this post, you will primarily work in AWS Application Migration Service (AWS MGN), focusing on the server migration lifecycle and MGN’s Post Launch Actions feature. A standard pattern is to tag two server instances as the blue (on-premises) and green (cloud) versions. This solution demonstrates transitioning from blue to green using Amazon Elastic Compute Cloud (Amazon EC2) instances in two regions. You can also use an existing server in your data center or another cloud as the source instance.

Within the MGN console, you will activate the Post Launch Actions feature, installing the AWS Systems Manager (SSM) agent onto subsequent test servers. With the MGN Replication Agent installed on the Blue Version Instance and the initial sync complete, you will launch a green version MGN test instance using Amazon Elastic Compute Cloud (Amazon EC2). In your test phase, you can attach AWS services and features to our green version instance, exploring the benefit of building in AWS. When your testing is complete, MGN’s server actions tab allows us to seamlessly transition into the cutover process or take a step back in the migration should you need it.

In Part 2 of the series, you will build on this post by building custom Post Launch Actions for Systems Manager, as well as leveraging AWS’ Generative AI capabilities with Amazon CodeWhisperer to help us write boto3 Python scripts to be executed via the AWS Command Line Interface (AWS CLI). Together, these two offerings will allow us to customize your migration to suit your needs in a repeatable process.

In this post, you will build an end-to-end workflow to implement this solution.

Target Architecture

The following diagram illustrates your solution architecture:

Figure 1: Proposed MGN Blue/Green Testing Solution Architecture

1. Setting Up Post-Launch Actions in MGN
2. Configuring Post-Launch Actions
3. Completing the Post-Launch Actions Set Up
4. Exploring the Blue Version
5. Installing the MGN Agent on the Blue Version Instance
6. Test the Migration Status
7. Update DNS Routing with Amazon Route 53

Walkthrough

With the introduction covered and the architecture displaying the targeted solution, you can begin the Walkthrough portion.

1. Setting Up Post-Launch Actions in MGN

 This first part will involve the mandatory initial setup process to permit using Post-Launch Actions in MGN.

Figure 2: MGN Post-launch Action Template

Opening the AWS Console and select the region where you want to launch your Green Version Instances. Search for MGN, open the service, and choose Post Launch Actions under Settings in the left-hand taskbar. Select Edit and toggle to confirm you want to Install the Systems Manager Agent, selecting your preferred deployment option.

2. Configuring Post-Launch Actions

The next phase involves the selection and configuration of the Post-launch actions.

Figure 3: Selecting and Configuring Post-launch Actions

There are numerous AWS predefined Post Launch Actions to choose from. To start, select a predefined action from the list and select the Edit option next to Card View. This will allow us to configure and activate the action you have chosen. You will use the Create AMI from Instance option for this demo.

Figure 4: Selecting an IAM Role for the Systems Manager Function

Create a new IAM role for this Systems Manager function to control access and permissions within your AWS account. More information on creating the role of Systems Manager can be found within AWS Systems Manager documentation.

3. Completing the Post-Launch Actions Set Up

You will complete the Post-Launch Actions setup by confirming the feature is configured and activated successfully. Once you have completed the editing process for your predefined action, you will select Save Action. You can confirm this process was successful by locating your new action in the card view and seeing the positive output. You will doubly verify this by looking for your AMI when you migrate your blue version and launch a test instance. Now, you move on to the migration process and start by examining your Blue Version instance.

4. Exploring the Blue Version

This section reviews the status of your Blue Version instance targeted for the migration.

Figure 5: Reviewing the Blue Version Amazon EC2 Instance within the AWS Console

Here, you can see your Blue Version Amazon EC2 instance dashboard. The Amazon EC2 instance has installed the Apache Web Server, PHP, and MariaDB. You will see this verified later.

The database endpoint has been preconfigured, and a sample web page via WordPress has been created, which you will use to reflect the changes between the Blue/Green Version.

Figure 6: Connecting to the Blue Version Instance via SSH – found via the AWS Console, Amazon EC2 Service.

You will connect to your instance via SSH to confirm any required dependencies are installed and leverage a WordPress site running on the Blue Version instance for this purpose.

Opening the Public IPv4 address, your WordPress site Blue Version should appear.

Figure 7: Blue Version of Sample Web Application Targeted for the Migration

You will change this UI on your Amazon EC2 instance to verify the continuous replication of MGN. Changes to the WordPress site hosted on the Blue Version should be reflected in the Green Version test instances launched in the migration pipeline.

5. Installing the MGN Agent on the Blue Version Instance

You will install the MGN agent in this section and begin the migration.

Figure 8: Within the Application Migration Service Console, MGN Agent Installation Steps

Opening the MGN service in the AWS Console, Navigating to Source Servers → Add server → Complete the prompts that appear, and MGN will generate the command for you to copy and paste in the SSH session, installing MGN on your source server (Blue Version).

Figure 9: Success Message for the AWS Replication Agent Installation

With the download complete, you can execute the file using the command generated from the MGN console, similar to how you did in the previous step.

Figure 10: MGN Console, Migration Metrics Page Reflecting the Source Server Status

MGN’s Dashboard will display the metrics associated with your server migration. Additional data is found when clicking on the source server itself.

Figure 11: Application Migration Service Data Replication, Source Server Page in AWS Console

Here, you can glean most of the information you could need. A further step into the inner workings of MGNs replication can be found by selecting your Source Server Name under Source Servers within the MGN console, scrolling down to Events and Metrics → View AWS CloudTrail Event History.

Figure 12: MGN Migration Dashboard, Lifecycle is reporting Ready for Testing

With the help of a  network bandwidth calculator, you can estimate the wait time until you see that the initial replication is finished. You can now launch a test instance. This will serve as the temporary Green Version of your Blue/Green migration. As previously discussed, the changes you make to your Blue Version instance should now be automatically reflected in your Green version, per the MGN continuous replication feature.

Let’s launch a test instance from the MGN console.

Figure 13: Launch a Test Instance from the Active Source Servers Test and Cutover Dropdown

Select Launch Test Instances. Your MGN lifecycle process will move from Ready for Testing to Test in Progress.

Figure 14: MGN automatically provisions the Amazon EC2 instance conversion servers, seen here.

In the Amazon EC2 console, you see the conversion server MGN automatically creates for us. This will produce your Green Version Test Instance.
 
After some time, the launch will be ready. MGN should confirm in the lifecycle process that your Post-launch actions status is In Progress. If not, please verify your actions are set up by selecting the post-launch settings tab within your source server. Navigate back to the Amazon EC2 console and review your new instance.

Figure 15: Green Version Instance, Launched as an MGN Test Instance alongside Post Launch Actions.

6. Test the Migration Status

In this section, you will confirm that the MGN Agent successfully performed the migration and demonstrate MGN Live Data Replication.

Now that your test instance is launched, you perform some tests. These could be routing traffic to the instance, shifting traffic simultaneously, doing a weighted distribution, trying to scale up or down with auto-scaling groups, attaching various services and features, and more. In this case, you will add a simple elastic IP, target group, and load balancer and update the security groups to allow you to securely access the instance. After the above resources are attached, let’s see what opening your Test Instance in a browser looks like.

Figure 16: Opening the Public IP of the Green Version Test Instance.

And it works! All you have left is to change your Blue Version in the on-premises environment to confirm that MGN is live replicating your data. Let’s open up your Blue Version site and make a change to the text to say Blue to Green. This change should appear in your Green Version.

Figure 17: Changing the Blue Version Instance’s Web App UI.

You are logged in to your web app and will change the text here.

Figure 18: Open the Public IP of the Green Version Instance. Changes to the Blue Version are completed via MGN’s live Data Replication feature.

And your replication is complete with the changes reflected in your Green Instance Version! This is the end of part 1 of your series. In part 2, you will build on these steps with new features and added complexities to gain more control of your testing and migration, including custom post-launch actions and scripting with the help of Amazon CodeWhisperer.

Figure 19: Test and Cutover options to Revert to Ready for Testing or complete Cutover process.

7. Update DNS Routing with Amazon Route 53

DNS routing through record updates is a common approach for blue/green deployments. It involves DNS switching traffic between the blue and green environments as needed, especially during rollbacks. Suppose you are managing your DNS-hosted zone with Amazon Route 53. In that case, you can follow the steps outlined above to update the alias record and direct traffic from the blue environment to the green background.

The figure below illustrates how Amazon Route 53 manages the DNS-hosted zone. You can direct traffic from the blue to the green environment by updating the alias record.

Figure 20: Classic Pattern – DNS Management in Amazon Route 53 for Blue/Green Deployments

Alternatively, a weighted distribution can be employed. In Amazon Route 53, this method enables the definition of a percentage of traffic directed to the green environment, with the flexibility to gradually adjust weights until the green environment handles the entire production traffic load. This approach facilitates canary analysis, introducing a small fraction of production traffic to the new environment for testing and error monitoring. Limiting the impact radius in case of issues allows the green environment to scale to accommodate the full production load. In the event of deployment challenges, a rollback can be executed by updating the DNS record to revert traffic to the blue environment until a formal cutover is performed.

Figure 21: Gradual Transition – Utilizing DNS-Weighted Distribution for Controlled Deployment

Clean Up

To avoid accruing any additional charges related to this post, be sure to clean up your resources, including:

• Amazon EC2 Instances
• Disconnect any MGN Source Servers
• Any auxiliary Block, Database, or other Storage associated with your testing

Conclusion

In this post, you explored how to leverage the AWS MGN Application Migration Service to perform Blue/Green migration, including the help of prebuilt Post Launch Actions with Systems Manager. You simulated the migration to AWS through Amazon EC2 Instances residing in different regions and verified the capabilities of MGNs live data replication. To take this a step further, completing a test migration with an actual on-premises server is an excellent way to implement the learnings from this post. In part 2, you will examine how to perform the migration with custom Systems Manager post-launch actions and leverage Amazon Generative AI capability by writing migration scripts in boto3 Python with the help of Amazon CodeWhisperer.

About the authors