AWS Cloud Operations & Migrations Blog

How to take advantage of AWS Control Tower and CloudEndure to migrate workloads to AWS

June 22, 2021: This blog post describes CloudEndure Migration. AWS Application Migration Service, the next generation of CloudEndure Migration, is now the recommended service for lift-and-shift migrations to AWS.

Most of the customers we work with want to migrate their existing workloads to an AWS environment. They prefer to follow documented AWS best practices, especially if they are in early stages of their cloud journey.

About AWS Control Tower

AWS Control Tower was created to address this customer request. AWS Control Tower is the easiest way to set up and govern a new, secure, multi-account AWS environment. It is based on best practices established through AWS’ experience working with thousands of enterprises as they move to the cloud. AWS Control Tower applies compliance guardrails to the new environment and provides real-time monitoring of compliance status via a common dashboard.

AWS Control Tower works both for migrations from on-premises applications to AWS and for your AWS environment with multiple AWS accounts. For both scenarios, managing different teams’ access, cloud setup, and governance can become complex and time consuming. That can slow the pace of migrations and add risks to security compliance. AWS Control Tower streamlines the migration process, enabling you to move quickly to the cloud in a secure and compliant manner.

In this post, we will demonstrate the steps to perform an end-to-end migration. We will show you how to execute a lift and shift on a simulated on-premises environment to a new AWS account governed by AWS Control Tower. We do this by using CloudEndure’s live migration tool and Continuous Block Level Replication technology. CloudEndure is an AWS company. The use case is that of a web server working with one database and one virtual machine. However, you can apply this process for any virtual machine that CloudEndure supports. In the end, you will have a configuration that addresses activities needed to scale a cloud adoption fast and securely.

This solution uses the following AWS services:

Overview
The architecture for this solution is mapped in the following diagram.

CloudEndure migration simplifies, expedites, and reduces the cost of cloud migration by offering an automated lift-and-shift solution. AWS Control Tower establishes a well-architected landing zone based on best practice blueprints. It enables governance using guardrails you can choose from a pre-packaged list.

Solution

In this post, we show the process to move your existing workloads to AWS Cloud. The process includes AWS Control Tower, new governed account creation, and CloudEndure on-premises environment migration. This blog post is a walk-through and it is divided into three sections:

  1. Set up a new governed AWS account using AWS Control Tower Account Factory.
  2. Set up the simulated environment.
  3. Work with CloudEndure Live Migration Tool:
    a. Set up CloudEndure configuration.
    b. Configure the source on-premises instances.
    c. Perform the migration and to track using AWS Migration Hub.
    d. Clean up the simulated environment.

Getting started with CloudEndure

If you are looking to quickly rehost a large number of machines to AWS, you can use CloudEndure migration. You don’t need to worry about compatibility, performance disruption, or long cutover windows. Any re-architecture that needs to be done can be performed easily after your machines are running on AWS.

CloudEndure migration licenses are provided at no cost for customers and partners migrating workloads into AWS for 90 days from the time of CloudEndure agent installation. Get started now with free CloudEndure Migration licenses.

Part I: Setting up AWS Control Tower

If you have not configured your AWS Control Tower yet, please follow these steps on Getting Started with AWS Control Tower. It takes about an hour to use that process to configure your Control Tower directly in the console. This is an important step to get a correct start on your AWS journey and to move forward with the next steps.

Creating your new, governed AWS account using Account Factory

AWS Control Tower creates a scalable way to manage account creation so you can have your multi-account environment in place for the migrations. Account Factory creates accounts for you using AWS Service Catalog.

1.  To access the AWS Account Factory feature, sign in to your AWS SSO user portal URL.

2.  To open the AWS Management Console, choose the account ID for your Master account from the list of accounts. Find the AWSServiceCatalogEndUserAccess profile and choose Management console to open the AWS Management Console.

If you don’t have a user, access Managing Users and Access Through AWS Single Sign-on to create one. AWS SSO users must be in the AWSAccountFactory group to provision accounts.

3. In the AWS Service Catalog console, under the Products list option, find the Account Factory product. Select AWS Control Tower Account Factory and select Launch product from the drop-down menu. This starts the wizard to provision a new account.

4. Enter the following Parameters to create your new AWS account.

  • SSOUserEmail: This can be a new email address or the email address associated with an existing AWS SSO user. Whichever you choose, this user will have administrative access to the account you’re provisioning. You will receive an invitation via this email address, so you must have access to it to accept.
  • AccountEmail: This must be an email address that isn’t already associated with an AWS account. If you used a new email address in SSOUserEmail, you can use that email address here.
  • ManagedOrganizationalUnit: This is the AWS Organizations’ Organization Unit that will contain the new account. AWS Control Tower creates by Default two OUs: Core and Custom. Choose Custom.
  • AccountName: Give your account a name.

The following screenshot shows these parameter settings.

5. In the lower right corner, select NEXT to finish the launch process.

6. On completion of new account creation, you see AccountId, AccountEmail, SSOUserPortal, and SSOUserEmail displayed under Provisioned products list under Events, Outputs. Share these with the account owner.

7. To create new users and provide them permissions access go to Managing Users and Access Through AWS Single Sign-on.

Part II: Preparing your on-premises environment

If you already have an environment, you can skip this step and move forward to Part III: the Migration Process. Review the networking requirements for running CloudEndure’s Solutions.

1. To create an on-premises simulated environment, use this AWS CloudFormation Template on the AWS CloudFormation service console. It launches a two-tier application composed of a .NET Core application running on an Amazon EC2 Ubuntu instance and the Microsoft SQL Server Database running on an Amazon EC2 Windows Instance. Launch it on us-east-2 Ohio Region.

2. Enter the following Parameters to create the stack:

  • Stack name: my-simulated-onpremises-environment.
  • KeyName: type a valid Amazon EC2 Key Pair for this Region. If you don’t have one, follow these steps to create an Amazon EC2 Key Pair.
  • MyClientIP: Add your IP or CIDR to allow access via http (port 80) to the web application. Avoid opening generally using 0.0.0.0/0, as this is a demo.

Part III: The Migration Process
Step 1: Prepare the CloudEndure Project
To use this CloudEndure Project, you need to configure some basic settings. In this section, we show you how to provide CloudEndure with two key configuration items: the AWS credentials to access your AWS account and a replication destination location within AWS.

Provide AWS credentials to access your AWS account
1. Access your CloudEndure user console. Select the plus button  to create a new project and name it.

2. At the bottom of the left sidebar, select Setup & Info to configure AWS credentials. These credentials allow CloudEndure to configure the staging environment and perform the migration.

3.  Create a new CloudEndure user under AWS IAM User on your AWS account. This user is the target of your migration process. CloudEndure makes this process easier by informing which permissions you must attach to the new IAM User. To find out which permissions you have to configure, please go to the CloudEndure user console. On the left side, click on “Set Up & Info” to review the steps needed for providing access. To reinforce a secure access method, there is a restricted IAM policy. For further protection, we recommend to remove unrestricted deletion of tagged snapshots – see here.

4. Next,  create an AWS Access Key ID and AWS Secret Access Key for this new user under IAM on the AWS Console and use these credentials with CloudEndure.

Provide a replication destination location within AWS

CloudEndure is a block-level replication tool that uses continuous replication. This means that you can replicate any change from the source environment to Amazon EC2 instances. Using CloudEndure, you can migrate your virtual or physical servers from an on-premises environment and move to the AWS Cloud. You can use a lift-and-shift approach, or you can migrate your Amazon EC2 instances from one AWS Region to another.

The target AWS Region contains your staging area and the target environment. CloudEndure uses the staging area to launch your replication instances.

Each source machine and staging area replication machine must continuously communicate with the CloudEndure Service Manager and CloudEndure Console (console.cloudendure.com) over TCP port 443. The source machines communicate with the staging area over TCP port 1500.

Choose your source

We are simulating an on-premises environment for this demo.

1.  In the left sidebar of the CloudEndure console, select Setup & Info and navigate to the Replication Settings tab.

2.  Choose Other Infrastructure as your migration source. Select Save Replication Settings in the lower right.

3.  If your source machines reside in an AWS Region, you can select either the Other Infrastructure option or the specific AWS Region as the source infrastructure. When you want to replicate only the source machines, we recommend using the Other Infrastructure option. If you select one of the AWS Regions as your source infrastructure, you have additional options for configuring the blueprint of its machines.

CloudEndure does the replication using a staging area. When the cutover is initiated, CloudEndure executes the machine conversion and orchestration process, allowing the applications to run natively on AWS.

Choose your target

1. In the Replication Settings tab, to the right of Migration Source, select your Migration Target.

2. From the drop-down, choose the Region where you want to migrate your environment. For this demo, select us-west-2 Oregon Region as your target environment.

Choose your replication area

As we are working with an AWS Control Tower governed account, the VPC default is not available as a replication area. So, use the  AWS Quick Start Modular and Scalable VPC Architecture for this demo. For a live migration, you could use a custom Staging VPC created following your architectural decisions, for example, with Direct Connect or VPN configuration.

This Quick Start provides a networking foundation based on AWS best practices for your AWS Cloud infrastructure. It builds a virtual private cloud (VPC) environment with public and private subnets where you can launch AWS services and other resources.

1. Access the AWS CloudFormation template. This template creates a new, Quick Start-based VPC and two more security groups to be used on the target environment.

2. Launch the VPC with the following parameters:

  • Stack name: Migration-Target-VPC
  • MyClientIP: Your IP or CIDR to allow access via http (port 80) to the web application. Avoid opening generally using 0.0.0.0/0, as this is a demo.

3.  In the CloudEndure console, in the Replication Settings tab, check the box to Use dedicated Replication Servers. CloudEndure uses a m5.xlarge instance type as the default Dedicated Replication Server. If you don’t want to use m5.xlarge, select a specific instance type under the Choose the Replication Server instance type category. The mx5.xlarge works for this demo, so we let the default remain, as shown in the following screenshot.

Note that without dedicated Replication Servers, CloudEndure launches the t3.small instance type and uses replication servers for multiple source machines. This could take up to 60 minutes.

4. After creating your VPC staging environment, choose the Migration Target VPC’s Public Subnet 1 still under Replication Settings tab. The migration target is where CloudEndure will launch your replication servers. Leave the replication security group as default. This tells CloudEndure to create a new CloudEndure replication security group and attach to replication instances.

For this demo, we use the same target VPC for replication servers and the migrated environment.

Note that you can replicate your source machines through your VPN or DirectConnect by selecting the checkbox Use VPN or DirectConnect at the bottom of the Replication Settings tab.

5. After finishing your configuration, select Save Replication Settings on the bottom right corner. The dialog box Project Setup complete will appear, as show in the following screenshot.

6. Select SHOW ME HOW in the lower right. This opens guidelines to install CloudEndure agent on your source instances.

Step 2: Installing CloudEndure Live Migration Agents

Now that you have your replication environment ready, you must configure CloudEndure live migration agents.

To make it easier, use the AWS Systems Manager Run Command to install your agents or source machines. AWS Systems Manager Run Command lets you remotely and securely manage the configuration of your managed instances. A managed instance is any Amazon EC2 instance or on-premises machine in your hybrid environment that has been configured for Systems Manager.

To learn how to use AWS Systems Manager, review Setting Up AWS Systems Manager for Hybrid Environments and Setting Up AWS Systems Manager.

Providing technical requirements for your Migration Project

1. Once you click on SHOW ME HOW in the previous step, you land on the Machines page. This page shows the How To Add Machines prompt, as shown in the following screenshot. You can also access the Machines page by clicking on it directly on the left sidebar.

Note that CloudEndure creates a token that will be informed later to install CloudEndure live migration agents on your source machines.

2. Go to the AWS Systems Manager Run Command console.

  • Select Run Command in the upper right to start the installation process. Run Command simplifies CloudEndure agent installation by eliminating the need to use bastion hosts, SSH, or remote PowerShell.
  • To install CloudEndure live migration agent on the Linux instance, choose the AWS-RunShellScript Command document.

  • For command parameters, once you selected AWS-RunShellScript paste the following command based on CloudEndure console suggestion into the box and run it. Use your CloudEndure token.

apt-get install -y python
wget -O /home/ubuntu/installer_linux.py

https://console.cloudendure.com/installer_linux.py
python /home/ubuntu/installer_linux.py

-t XXXX-XXXX-XXXX-...-XXXX --no-prompt

Note that we are installing Python because or Ubuntu image has not it installed. Other commands were copied from CloudEndure console, as you saw earlier.

  • For Targets, select Choose instance manually. Then check the checkbox next to Dotnet Application instance to select it, as shown in the following screenshot.

  • Select Run to finish the process. You see the status on the Command Status page. Wait until the status changes to Success, as shown in the following screenshot.

3.     When this process is done successfully, navigate back to the CloudEndure User Console Browser Dashboard. Your instance now appears as an object in the Initial Sync phase, as shown in the following screenshot. It is being replicated to the AWS us-west-2 Oregon region, as previously specified.

The instances will undergo several stages until they are completely synced with the CloudEndure User Console. When all data has been successfully replicated, they will appear as Ready.

Setup your Windows machine

Complete these similar steps for your Windows machine.

First,  go to the AWS Systems Manager console.

  • Select Run Command.
  • Select the command document AWS-RunPowerShellScript, as shown in the following screenshot.

  • Copy and paste the following command to the Command Parameters field. Use your CloudEndure token.

wget https://console.cloudendure.com/installer_win.exe -outfile "c:/windows/temp/installer_win.exe"


c:/windows/temp/installer_win.exe -t XXXX-XXXX-XXXX-...-XXXX --no-prompt

  • For Targets, select Choose instance manually. Under Instances, check the checkbox next to Source Database – SQL Server. See the following screenshot.

  • Select Run to finish the process. You see the status on the Command Status page. Wait until the status changes to Success .
  • Wait until all instances reach Continuous Data Replication in the Data Replication Progress column. See the following screenshot.

Step 3: Configure Machine Blueprints

Machine blueprints inform CloudEndure which configurations will be used to launch the target migrated environment. In this step, you configure the machine blueprints. You can perform this step while your other instances are still being replicated.

  1. In the CloudEndure console, select Machines from the left sidebar. Select the Linux machine by selecting the server named dotnetapplication. This opens the details page to configure the machine blueprint with target instance options.

2.  On the blueprint details page, enter the following values:

  • Machine Type: t2.micro.
  • Launch Type: On demand.
  • Subnet: Public Subnet 1.

We will choose the Target Public Subnet 1 that has the same CIDR that the Source Public Subnet 1. We will choose the option to keep the same IPAddress.

●      Security Groups: Migration-Target-VPC-sgweb-***.

This security group was created by your Cloudformation template.

●      Private IP address: Copy Source.

●      Disks: SSD.

●      Public IP (ephemeral): Yes.

●      Disks: SSD.

3.     Select Save in the lower right to save your configuration.

4.     Repeat the process to configure the SQL Server database. In the Machines tab, select the server name dmsssampledatabase.

5.     On the blueprint details page, enter the following values:

  • Machine Type: t3.xlarge.
  • Launch Type: On demand.
  • Subnet: Private Subnet 1A.

We will choose the Target Private Subnet 1A that has the same CIDR that the Source Private Subnet 2. We will choose the option to keep the same IPAddress.

  • Security Groups: Migration-Target-VPC-sgdatabase-***.
  • Private IP address: Copy Source.
  • Public IP (ephemeral): No.
  • Disks: SSD.

6. Select Save in the lower right to save your configuration.

Step 4: Testing your replicated machines

In this step, you perform a test migration to confirm that the source systems were properly replicated. You can also confirm that they function as designed in their new environment.

Every time you perform the Test/Cutover Mode action, CloudEndure deletes any previously created test instances. It also creates new target instances that are up to date with the source instances.

It is a best practice to perform a test migration at least one week before you plan to migrate your source machines. This time frame is intended to identify and solve potential problems before the migration takes place.

Here’s how to test your machines.

  1. In the CloudEndure console Machines page, in the upper right, select Launch 2 Target Machines. Select Test Mode.
  2. While CloudEndure works on Target instances launch in Test Mode, you can follow the progress on Job Progress menu option on CloudEndure console. You can see a sample Job Progress in the screenshot below.

CloudEndure migration spins up a temporary machine converter responsible for modifying the target machine. The machine converter enables the target machine to boot and run natively in AWS. This includes injecting the appropriate AWS drivers, making appropriate bootloader changes, modifying network adapters, activating operating systems using the AWS KMS, and more.

3. While the launch target machine process is executing, go to the Amazon EC2 console. You can see CloudEndure machine converter instances working, as shown in the following screenshot. The conversion process normally takes few minutes and is executed on all launched machines in parallel.

 

4. Return to the CloudEndure console Machines page. When the test is finished, the Migration Lifcycle column for the relevant machines show as Tested. See the screenshot below.

 

5. Go to your Amazon EC2 Console and find your two Amazon EC2 instances launched. These instances are exact replicas of the source application and database servers which currently reside on-premises.

Step 5: Migration – cutover process

The test or cutover process creates new Virtual Machine instances in the target us-west-2 Oregon region. They have the same name as the source server, as you defined in the target machine blueprints.

At this point, the machines are in Continuous Data Replication state. To cut over, do the following:

  1. In the CloudEndure console Machines page, select the Launch 2 target machines button in the top right corner. Select Cutover Mode from the drop-down menu.
  2. CloudEndure performs a final sync/snapshot on each instance. It begins the process of building new servers into the target infrastructure, located in us-west-2 (Oregon), while maintaining data consistency. See the Job Progress dialog box for details.
  3. When the cutover is complete, the CloudEndure Machines page indicates Cutover in the Migration Lifecycle column..
  4. See if your application is running. Navigate to the Amazon EC2 console and navigate to the us-west-2 Oregon region. Select the dotnetapplication instance and copy the Public IP. Copy the Private IP for use in step 6.
  5. Open the application on your browser by pasting the public IP on the address bar. See the following screenshot.

6. Enter the following parameters for Primary Database. Leave other information as default. See screenshot below.

  • Server Type: SQL Server.
  • Server Name: private IP of your Database instance.
  • Database Name: dms_sample.
  • Database User: dms_user.
  • Database Password: dms_user.

7. Select Apply.

8. Test the connection by going through the different links and tabs on the web application and navigate within the application to check the database.

Congratulations! You have migrated your environment to AWS using CloudEndure and AWS Control Tower.

Step 6: Clean Up

To remove all resources you added in this demo, follow these steps:

  1. On CloudEndure user console, go to Project Actions in the upper right. Choose Delete Current Project, as shown in the following screenshot.

 

2. Go to AWS CloudFormation console on Oregon region and delete the stack Migration-Target-VPC.

3. Go to AWS CloudFormation console on Ohio region and delete the stack my-simulated-onpremises-environment stack.

The application that you’ve just migrated here is ready to use MySQL or SQL Server. As a next step, you can configure both endpoints and switch from one to other to work with data. It is already integrated with AWS Database Migration Service (AWS DMS) to help you keep track of the status of your migration process.

To continue developing your improvement journey, you might consider migrating from your single SQL Server instance to Aurora MySQL. This offers reliability and scale capabilities to your database. See Another Database Migration Playbook goes live—migrate from Microsoft SQL Server to Amazon Aurora MySQL for reference.

Conclusion

In this post, we demonstrated how to perform a migration with six steps. This process provides account governance using AWS Control Tower and gives your production environment additional security and governance baselines.

This tutorial shows one way to expedite your cloud journey. You used CloudEndure and AWS Control Tower to build a compliant and secure migration process on AWS. This process provides visibility of on-premises workloads up until the final cut off and lets you analyze sizing for your virtual machines. Because of that, this process can be easily replicated when migrating from another cloud provider or another AWS Region as well.

Further Reading

 

About the Authors

Claudia Charro is a Solutions Architect at AWS since 2015. Her focus is management tools and she works with enterprise customers leveraging their performance when moving forward in their journey to the AWS Cloud.

 

 

 

Natália Girolamo is a Technical Program Manager for the Well-Architected Tool and has been passionate about technology from day one. She has been working for two years at AWS, being specially interested in helping customers advance in their digital transformation using AWS cloud securely.

 

 

 

Diego Dalmolin is a Solutions Architect in AWS for over 3 years. His primary role is to work with Consulting and Technology Partners that enable customers to mass migrate their workloads to AWS at scale.