AWS Cloud Operations Blog

Use AWS RAM and AWS MGN to Govern your Migration at scale in AWS

Introduction

AWS customers consider Lift & Shift as the first increment of value delivery in their cloud adoption journey. Following this strategy customers will have benefits of speed, cost reduction, business agility, operational resiliency, and staff productivity. As part of the migration plan they will adopt a multi-account strategy to establish their AWS foundation at scale. One of the key challenges is the complexity to govern multiple networks in different Virtual Private Clouds (Amazon VPC) while the migration happens organically.

In this blog, we will show you how to migrate at scale with AWS Application Migration Service (AWS MGN), using a multi-account strategy. It will show you, how to govern your network from a central place using AWS Resource Access Manager (AWS RAM). Combining these 2 services you will have a successful migration path with enforced network guardrails.

Solution Overview

Customers need a central place to manage the network infrastructure during the migration execution. The diagram below (figure – 1) depicts how a typical multi-account strategy looks like. Customers will have 4 different accounts in an AWS Organization. Account A will be the main account or VPC Owner. Accounts B, C and D, or VPC participants, are migration landing accounts. In a multi-account strategy environment, Account A will manage the rest of the accounts centrally. Account A owns and manages the AWS Transit Gateway to establishing connectivity across the VPC participants. Network team will share the governed subnets from Account A to the rest of the accounts. Customers will use AWS MGN in Accounts B, C and D to perform Lift & Shift migrations, with each account owning its own staging area. When the migration teams perform the cut-over, they will use the governed shared subnets shared by Account A. Accounts B, C and D receives the benefits of building within properly configured, secured and monitored subnets, managed by the network team from Account A. Network team can centrally manage network assets within an AWS Organization and govern networking aspects of the migration from Account A.

Figure 1. Diagram of subnets shared across multi-accounts for MGN resources

Figure 1. Diagram of subnets shared across multi-accounts for MGN resources

Prerequisites

These are the requirements for the success use of AWS RAM and AWS MGN to govern your migration at scale.

Deploying the solution

Steps to Configure

1.    Sharing subnets across accounts using AWS RAM
For this scenario, We have 3 subnets to share with our VPC Participants (Accounts B, C and D) through AWS RAM:

  1. Navigate to AWS RAM on the VPC Owner (Account A) , create a “resource share” and select destination account numbers (Accounts B, C and D):

  1. These default permissions will be associated with the resources shared

  1. Select “Allow sharing only within your organization” and add the Account IDs for our VPC Participants (Accounts B, C and D).

Note: After we create the resource sharing, it can take a few minutes for the resources and principal associations to complete. Allow this process to complete before you try to use the resource share.

2.    Setting up AWS MGN default template to use the shared Subnets

To start using these subnets with AWS MGN in the VPC Participants (Accounts B,C and D), we will need to change the default replication settings of the launch template.

We will start with changing the default replication setting on the Account B. Go to you AWS console and open the Application Migration Service. Click on the panel on the left in “Settings”.

  1. Edit the Replication settings template Inside the console.

  1. Select one of the Shared Subnets from the VPC Owner (Account A) as staging area.

  1. Install the MGN Agents to start with the Lift & Shift journey.

3. EC2 launch template for source servers in VPC Participants (Accounts B, C and D)

After the MGN Agents are installed, the replicated on-prem servers are visible in the MGN console.

In the following example we have 2 on-premise servers replicated. Server-1 and Server-2.

To launch a new Elastic Compute Cloud (EC2) instance from the staging area you must “cut-over” the server. Cut-over will use an EC2 launch template of the instance for the instance creation in your VPC Participants.

    A. Modify the launch template for each server to change the default subnet for the subnets shared and controlled by your VPC Owner.

Note: For this example, we will work on a source test server called Server-2 by clicking on the server’s name.

  1. Click the launch settings tab and select Modify

This will redirect us to EC2 Launch Templates where we will change the default subnet to the shared subnet from VPC Owner (Account A).

  1. Click the Modify button to continue.

  1. Under Network Settings, adjust the subnet settings to the desired shared subnets from Account A.

  1. Create a new template with the Create template version button.

Note: After the new launch template is created, we have to configure MGN to use it as default cut-over option.

  1. Go back to the list of Launch Templates by clicking on View Launch templates button.

  1. Choose your launch template by selecting the toggle to the left of the Launch template ID. Click on Actions button and choose Set default version.

  1. Select the latest Template version (In this case its version 2 here) from the drop-down menu to include your recent modifications and then click on Set as default version.

  1. Modify the EC2 Launch settings for each migrated server in each VPC participants to use the newly shared subnets from Account A (VPC Owner).

Now, when you execute an MGN cutover, the EC2 instances will now be placed in the desired shared subnets.

Cleaning up

  1. Navigate to AWS MGN console on VPC Participants (Accounts B, C and D) to delete the source servers by: Selecting Source Servers, clicking on Actions and Disconnect from Service

  1. Mark the source Servers are archived

Note: Now your Source servers list should be empty

  1. Log to the VPC Owner (Account A) and open AWS RAM console. Click on the resource sharing group that was created earlier and click on Delete

  1. After few minutes, Shared subnets will be removed from VPC Participants (Accounts B,C and D)

Conclusion

In this post, we have demonstrated how you can govern your migration journey from a central place with network guardrails. Large Lift-and-shift migrations can be challenging for network teams, and having a controlled network landscape is the first step for a successful cloud journey. Furthermore, teams using the VPC Participants will receive the benefits from deploying within controlled landing subnets for their migrated workloads. Thanks to AWS RAM and AWS MGN governed migrations at scale is possible, through segregation of responsibilities while working towards a common goal.

About the authors:

Tarek Mahmoud

Tarek Mahmoud is a Solutions Architect at AWS. In his role, he provides guidance to customers in Benelux to be successful in their journey using AWS Cloud and improve their architecture. Prior to becoming a solutions architect at AWS, Tarek has been helping customers improve their Operations on-prem and on AWS.

Jorge Alvarez

Jorge Alvarez is a Solutions Architect Specialist in Migration and Modernization at AWS. In his role, he provides guidance to customers in their Migration and Modernization journey in Ireland. Prior to becoming a solutions architect at AWS, Jorge was leading teams in the cloud space, helping customers in their journey and modernization efforts.

Melody Huang

Melody Huang is a Solutions Architect at AWS, where she guides customers in the financial services industry to build scalable, secure, and well governed cloud environments. She is passionate about digital transformations and its implications on an organization’s people and culture.