Validate your Migration cutovers using predefined post-launch actions

Intro

Migration involves a crucial step of validating that your applications perform as expected in the cloud, achieved through multiple checks or scripts run on migrated servers.

Manual performance of these tasks is complex, time-consuming, and prone to errors, particularly when migrating servers or applications at scale. AWS Application Migration Services (AWS MGN) simplifies this by offering predefined post-launch actions. Moreover, you can create your own post-launch actions.

The post-launch action framework, integrated with AWS Systems Manager (SSM), supports a broad spectrum of automation possibilities. AWS MGN installs an AWS Systems Manager Agent (SSM Agent) on every launched instance—test or cutover—enabling the execution of any AWS SSM document on launched instances.

In this blog post, we will demonstrate how to employ AWS MGN predefined post-launch actions to test and validate your migrated applications automatically. This approach eradicates manual overhead, ensuring a successful, scaled migration.

Use Case Scenario

Let’s consider the following use case scenario: you are migrating a 2-tier application that consists of one Linux Server with tomcat and one Database Windows Server with Microsoft SQL Server.

As part of your migration strategy, you defined a series of controls and checks that you want to perform and automate after we have launched the servers in AWS. In particular:

For the database server

Check volume for integrity and percentage of available free disk space
Check if SQL Server process is running

For the application server

Check if the web server is listening and responding correctly on port 8080
Check if the web server is able to reach external API endpoint on port 443

For the purpose of the above scenario, we are going to show you how to use the following predefined post-launch actions:

For the database server

For the application server

Step by step solution

1. Initial setup

Our scenario includes a 2-tier application, that consists of a Linux Server with tomcat and a Database Windows Server with Microsoft SQL Server.

For the purpose of simulating a customer environment, we used Amazon Elastic Compute Cloud (Amazon EC2) instances running in a VPC (Amazon Virtual Private Cloud – Amazon VPC)(source VPC). We have defined our target environment as a different VPC (target VPC), having a different CIDR network from the source (as it happens in most real use cases).

We assume that your source environment is existing and that you are already familiar with the Getting started operations required to use MGN, in particular you need to:

1.1 Define the target subnets (and VPC) for the launch of the cutover instances.

You need that cutover Instances on target subnet have the ability to contact SSM endpoints required by SSM Agent, this can be done with a Public Subnet or Private one with the configuration of VPC Endpoints or NAT gateway.

To create a VPC and its resources, you can refer to this documentation.

1.2 Initialize MGN and Configure Replication Settings Template

You need to initialize MGN service in the AWS region in which you plan to migrate your applications. Additional configuration steps such as creating a replication setting template which also defines your staging area subnet should be carried out. Please refer to this documentation for detailed instructions.

As Staging area subnet for this scenario, we used one the public subnet created at the previous step, leaving the other values to default.

1.3 Configure post-launch template.

To use the post-launch template, you must first activate the post-launch actions. This will allow MGN to install the SSM Agent on your servers and execute post-launch actions.

Post-launch actions settings allow you to control and automate actions performed after your migrated servers has been launched in AWS.

From MGN console, select post-launch template under Settings in the left menu and select the Edit button.

Figure 1 – Post-launch template configuration

In the next Windows enable Install the SSM Agent and allow executing actions on launched servers and select the recommended Deployment: Test and cutover instances (recommended).

Editing Post-launch configuration details, such as installing SSM Agent and selecting which deployment Figure 2 – Editing post-launch template configuration

1.4 Install AWS Replication Agent on the 2 source servers.

Add your source servers to MGN by installing the AWS Replication Agent on them.

Please refer to AWS Replication Agent installation as described into documentation.

1.5 Let the initial sync process complete for the 2 source servers.

You should have the 2 source servers in ready for testing state before proceeding further.

2. Configure the post-launch actions

Post-launch actions can be configured at the template level and at the server level. Changes made to the templates will only be applied to newly added source servers, and don’t affect existing source servers.

In your case you have one Linux server and one Windows server, you want to assign different post-launch actions to each server.

2.1 Application Server post-launch actions

2.1.1 Select the source server you want to configure post-launch actions for in the Source Servers sections of the Application Migration Service. Here you select your Linux application server where you are going to configure EC2 Connectivity check and HTTP/HTTPS response validation to validate that your server has connectivity.

2.1.2 Select the post-launch settings tab and filter by Validation Category on the left.

Figure 3 – Post-launch settings for a single source server

2.1.3 EC2 Connectivity check

The EC2 Connectivity check action validates that the EC2 instance has network connectivity by trying to access specific IPs and Ports. You can use it to verify reachability of an important endpoint for that server (internal or external), e.g., an API gateway exposed by a 3rd party on internet, that your application queries in order to properly work.

2.1.3.1 Select EC2 Connectivity check from the list of Actions then select Edit. You will access the action settings panel.

2.1.3.2 Check the box Activate this action to activate the EC2 connectivity check.

2.1.3.3 Check the box This action must be completed successfully before finalizing cutover as you want to make sure you have connectivity before finalizing the cutover.

2.1.3.4 In Action Parameters > HostsandPorts type the Hosts IP and Ports for which the network connectivity check will be conducted. The format for this action parameter should follow the pattern IP:PORT, for example, add 54.239.28.85:443 to check connectivity again https://www.amazon.com.

2.1.3.5 Select Save action button.

Figure 4 – EC2 connectivity check configuration details

2.1.4 HTTP/HTTPS response validation

The HTTP/HTTPS response validation action helps validating that the EC2 Instance can call the specified HTTP/S URL and get back the correct success code – if specified – as a response.

2.1.4.1 Select HTTP/HTTPS response validation from the list of Actions then select Edit.

2.1.4.2 Check the box Activate this action.

2.1.4.3 Check the box This action must be completed successfully before finalizing cutover.

2.1.4.4 In Action Parameters > Urls fill the URL and PORT verify that HTTP/HTTPS requests (for example, https://localhost) receive the correct response.

2.1.4.5 Select Save action button.

Figure 5 – HTTP/HTTPS response validation configuration details

2.2 Database Server post-launch actions

At this stage you setup the post-launch actions for your Linux application server and are ready to move to the Windows database server.

2.2.1 Select the source server you want to configure post-launch actions for in the Source Servers sections of the Application Migration Service. Here you select your Windows database server where you are going to configure Volume integrity validation, Validate disk space and Process status validation to validate that your server has connectivity.

2.2.2 Select the post-launch settings tab and filter by Validation Category on the left.

2.2.3 Volume integrity validation

The Volume integrity validation feature helps ensure that EBS (Amazon Elastic Block Store) volumes on the launched instance are:

- - The same size as the source (rounded up)
  - Properly mounted on the Amazon EC2 instance
  - Accessible

2.2.3.1 Select Volume integrity validation from the list of Actions then select Edit.

2.2.3.2 Check the box Activate this action.

2.2.3.3 Check the box This action must be completed successfully before finalizing cutover.

2.2.3.4 In Action Parameters > Volumes select Use Values: Volumes to validate integrity for all the volumes of your EC2 Instance.

2.2.3.5 Select Save action button.

Figure 6 – Volume integrity validation configuration details

2.2.4 Validate disk space

The Validate disk space action helps validate the available space for the volumes on the selected EC2 Instance. It returns a block size, FreeSpace percentage and FreeSpaceGB. Note that it is also possible to exclude some volumes from the action.

2.2.4.1 Select Validate disk space from the list of Actions then select Edit.

2.2.4.2 Check the box Activate this action.

2.2.4.3 Check the box This action must be completed successfully before finalizing cutover.

2.2.4.4 In Action Parameters > FreeSpacePercents input 30 to verify if the available free space on the target EC2 instance is at least of 30%.

2.2.4.5 Select Save action button.

Figure 7 – Validate disk space configuration details

2.2.5 Process status validation

The Process status validation feature helps ensure that processes are in running state following instance launch. You will need to provide a list of processes that you want to verify, and define how long the service should wait before testing begins.

2.2.5.1 Select Process status validation from the list of Actions then select Edit.

2.2.5.2 Check the box Activate this action.

2.2.5.3 Check the box This action must be completed successfully before finalizing cutover.

2.2.5.4 In Action Parameters > Processes list all the processes that you want to verify. Here, as your Windows Server is hosting a Database, you want to make sure that the process sqlservr is running.

2.2.5.5 Specify a WaitSeconds parameter that will define a delay by which you will start the validation. Note that some processes can take time to boot up and setting up an adequate waitSecond parameter is key for this post-launch action to work. Here you input 60 seconds.

2.2.5.6 Select Save action button.

Figure 8 – Process status validation configuration details

You have now setup all validation actions for your Windows server.

3. Launch Test Instances

After having added post-launch actions to your source servers and configured their launch settings, you are ready to launch a test instance.

3.1 As the test progress, you will be able to oversee the post-launch action progress by selecting the Source server name and accessing the migration dashboard.

Figure 9 – Execution Status of post-launch actions for the Windows Server

3.2 Once your post-launch actions are executed successfully you will be able to see their status as Succeeded as well as the start time and the end time of the post-launch action script. You can select a specific post-launch action to get additional details.

Figure 10 – Windows Source Server post-launch actions succeeded

3.3 For example, if you want to verify how much space you have left on your database server after launching the instance, you can select the successful post-launch action Validate disk space.

3.4 This opens AWS Systems Manager > Run Command, which is the underlying mechanism used by post launch action to execute specific commands. Selecting the instance ID opens command execution details where you can see Output and Error logs.

Figure 11 – Details of Run Command execution

3.5 You can see in the Output of the ValidateWindowsDiskSpace command that the execution was successful and that the FreeSpace is 70% or 105.48 GB.

Figure 12 – Output from Run Command execution

Conclusion

Incorporating a number of post-launch actions, which are applied to all servers in-scope of your migration, minimizes time-intensive, error-prone manual processes by automating validation of your migrated servers on AWS. It also simplifies application modernization with built-in and custom optimization options.

In this blog post we demonstrated how you can use predefined post-launch actions to verify your migration. Additionally, you can write your own SSM documents, that verify application parameters that are important to you. Configure your own custom post-launch actions based on these SSM documents, to further enrich your testing. You can of course combine predefined actions with custom actions, according to your own needs.

To learn more about AWS Application Migration Service (AWS MGN), post-launch actions and how the solution helps customer move and improve applications into AWS at scale, check out the following resources to get started:

About the authors:

AWS Cloud Operations & Migrations Blog