Since AWS Application Migration Service (AWS MGN) has been positioned as the recommended service for (rehost) migrations to AWS, we have seen an astounding speed of new feature releases, multiple enhancements, and continuous innovation aimed to address customer needs.

AWS Application Migration Service (AWS MGN) is a highly automated move and improve (rehost) solution that simplifies, expedites, and reduces the cost of migrating applications to AWS. It allows companies to migrate a large number of physical, virtual, or cloud servers without compatibility issues, performance disruption, or long cutover windows. AWS MGN replicates source servers into your AWS account. When you’re ready to migrate, it 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 replatform or refactor those applications – which makes rehost a fast route to modernization. AWS MGN is available to all AWS customers and partners.

As you migrate the workloads successfully on to AWS Cloud, it also important to ensure these workloads meet the security and compliance best practices/frameworks.

Therefore, it is critical for organizations to ensure that applications are maintained and patched on time before the vulnerability manifests itself.

It is estimated that 48% of organizations have experienced some kind of data breach in the past two years. 60% of breach victims said they were breached due to an unpatched known vulnerability.

Enterprises face major challenges when it comes to patch management. IT and security professionals find patches complex and time-consuming, and Business Unit leaders often fear that applying patches too soon after release could break application functionality. Additionally, remediation of these vulnerabilities needs to occur in workloads that are in the process of migrating or transforming.

In this post, we will see how these challenges can be addressed by using AWS MGN waves and post-launch actions to automate patching your instances during your migration to AWS.

Prerequisites

For this walkthrough, you should meet the following prerequisites:

An AWS account.
An AWS console user with enough permissions for the services mentioned below.
Hands-on experience* with services mentioned in the “Walkthrough – Services used” section.

* Get hands-on experience by completing the Migration Immersion Day labs in your AWS account. They offer step-by-step instructions, available in English, Portuguese, Spanish, Korean, and Japanese.

Walkthrough

Let’s begin your journey to the cloud using AWS Application Migration Service and AWS Systems Manager as your guides.

Solution overview

AWS MGN Waves is an AWS Application Migration Service feature that helps users manage their migrations by grouping source servers and applications into waves. You can monitor the wave’s migration status, progress, and associated applications, as well as perform bulk operations on the applications associated with the wave.

AWS MGN post-launch actions is an AWS Application Migration Service capability that allows you execute any AWS Systems Manager Document to optimize your applications by applying custom modernization actions. You can also select built-in actions such as cross-Region disaster recovery, CentOS conversion, and SUSE Linux subscription conversion.

AWS Systems Manager Patch Manager is a capability of AWS Systems Manager that automates the process of patching managed nodes with both security-related updates and other types of updates. You can use Patch Manager to apply patches for both operating systems and applications.

Figure 1 – Architecture diagram for the solution

1. AWS MGN post-launch action invokes AWS SSM Automation to patch instances

2.Validation of applications and patch compliance of instances

3.Complete the cutover and finalize the migration wave

1) Create Post-Launch Action with AWS MGN

Post-launch settings allow you to control and automate actions performed after the server has been launched in AWS. These actions are executed automatically based on the post-launch template. In this section, we will define a custom action and configure AWS MGN to execute it. In your own migration project, you can choose to execute different actions based on your own needs.

You have two options for configuring post-launch actions. You can define a new action in the post-launch template, or configure post-launch settings at the server level. If you configure the post-launch template, changes (including the new action) are only applied to servers added after the change. The template is not applied to existing servers. If you configure the settings at the server level, you will need to manually configure the action for each source server.

We recommend defining the new action at the account level post-launch template, before installing agents on your servers. After you have set up the template, install the agents on the source servers and begin replication. That will facilitate that all of the source servers inherit the default settings from the account level template.

1.Choose Post-launch template from the left-hand navigation menu.

2.Click Edit.

3.Turn on the Activate the Install the System Manager Agent toggle. This will allow AWS MGN to install the AWS SSM Agent automatically on the servers that will belong to your migration wave.

Figure 2 – Configuring Post-Launch template.

4. Add an action to be executed on the launched instances.

For this purpose, we will be creating a new action using an AWS public SSM document/automation. This automation will apply applicable patch baseline and, upon failure, it will automatically roll back its root volume to the source servers belonging to your migration wave.

Give a name to the action and select the Automation runbook “AWS-PatchInstanceWithRollback”. Activate this action by checking the checkbox. Set the order in which this action will be run alongside other custom and predefined actions by entering a numerical value in the Order field.

Figure 3 – Adding an action to be executed on the launched instances.

2) Define a group of servers and associate them with an application

Now that you’ve defined an action that will be executed on the launched instances, it’s time to define the group of instances that will be launched together on which this action will be executed.

AWS Application Migration Service supports the option to group source servers into applications and to group applications into waves.

Applications are groups of servers that function together to provide a business need. There are dependencies between the servers because they work together, have shared networking, and are needed for the functionality to work correctly. For example, a large application that has a database, a few web servers, and some backend servers that perform calculations. All of these servers need to be migrated together, so that there is a fully functional application in production.

Waves are groups of applications that are designed to be migrated together in a specified time period. This is determined as part of the migration project planning. There is not necessarily a dependency between different applications that are in the wave. The grouping is based on your migration needs. You may group together all low-priority applications for the first wave, to learn from the migration process and improve, and leave high-priority applications for a different wave. Alternatively, you can group all applications from a specific business unit, say marketing, into a single wave, before moving to a second wave for sales applications. You can choose how to plan your migration waves and assign applications to a wave based on your business needs.

For both applications and waves, AWS MGN provides aggregated monitoring of the migration process, as well as bulk actions that can be performed on all the resources that are part of the application, or of the wave.

1.Choose Applications from the left-hand avigation menu.

2.Add the servers to your application

Figure 4 – Attaching your servers to an application.

3) Add the Application to your Wave Migration

Figure 5 – Adding your application to a wave migration

After creating your wave and adding all of your applications, you are ready to launch a test instance. It is crucial to test the migration of your source servers to AWS prior to initiating a cutover.

4) Launch your Migrated Instances and Monitor your migration job

Click on “Launch Test Instances”, once you launch your Test Instances, monitor your Migration dashboard. The most important aspect is to validate that the post-launch action configured by you in step 1 has been triggered successfully.

Figure 6 – Validating execution of post-launch actions

As we can see, the post-launch action has been initiated and the AWS SSM automation that is responsible for applying patching on all the instances that composed your Wave1 has been successfully concluded. Now, you are ready to validate application functionalities and make sure that everything is working as expected.

5) Validate compliance state of your instances

1. Go to the AWS Systems Manager > Patch Manager.
2. Under the Compliance Report tab, you should be able to see that the servers you added to your migration wave are in Compliant state.

Figure 7 – Validating compliance state of your servers

Compliance is a capability of AWS Systems Manager in which it collects and reports data about the status of patching in Patch Manager. To learn more about patch compliance, see Working with Compliance.

Patch baselines allows you greater control over which patches are approved or rejected for your environment when using Patch Manager. You can use these predefined baselines as they are currently configured or configure your own patch baseline. To learn more, see predefined and custom patch baselines.

6) Launch Cutover Instances and Finalize your Migration

Once you have finalized the testing of all of your source servers and applications, you are ready to cutover (1) and finalize (2) your migration. You should perform the cutover at a set date and time. The cutover will migrate your source servers to the cutover instances on AWS with patches already installed and instances in a compliant state.

Figure 8 – Launching and finalizing cutover instances

Conclusion

Organizations are looking for ways to enhance security and compliance of their applications, patch management is complex, time-consuming and demands pre/post validations of multiple stakeholders, these challenges are enhanced because of restricted maintenance windows to finalize your migrations and ensure compliance in the same time.

Using this integration, AWS Application Migration Service post-launch action framework with AWS SSM Patch Manager/automation, organizations can leverage the same migration window to automate patching and keep the workload in compliance.

About the authors: