Migrating workloads across AWS Regions with CloudEndure Migration

AWS customers are in various stages of their cloud journey. Frequently, enterprises begin that journey by rehosting (lift-and-shift migrating) their on-premises workloads into AWS and running on our Amazon EC2 instances. Many of these customers perform that rehosting using CloudEndure Migration, our cloud-native migration tool. However, this rehosting migration pattern with CloudEndure Migration can also be used to migrate Amazon EC2-hosted workloads from one AWS Region to another. Customers may choose to do this because they want to relocate instances and workloads to a Region that is closer in proximity to one of their offices or data centers. Another use case might be driven by a requirement for the customer to balance their workloads across multiple Regions for resilience.

AWS offers multiple options for migrating Amazon EC2 instances across AWS Regions. Besides CloudEndure Migration, users can take Amazon EBS snapshots of their source instances and copy those snapshots to the target Region, where they can be used to launch new target instances. These target instances are a duplicate of the source instance at the time that the snapshot was taken. CloudEndure Migration, in contrast, continuously replicates data to the target Region, so that the migrated instances are up to date at launch.

Others benefits of rehosting workloads across AWS Regions using CloudEndure Migration include the following:

• Automating the migration of instances without having to learn a new tool (If CloudEndure Migration was used for the initial migration from on-premises to AWS).
• The migration can be performed with minimal downtime since CloudEndure Migration continuously replicates data across Regions, ensuring that cutover can be done in minutes with no data loss.
• If a customer is relocating workloads across Regions, CloudEndure Migration can be configured to migrate the Amazon Virtual Private Cloud (VPC) networking and security settings from the source Region to the target Region.
• Alternatively, the target Region may be required to maintain separate VPC settings with different IP addressing schemes and networking configurations from the source. In this case, CloudEndure Migration can be configured to migrate the source instances into a pre-configured VPC.
• In addition to network configurations, modifications can be made to the target instances that are instantiated at launch. These potential modifications include instance type, tenancy, and volume type.

In this blog post, I walk through how CloudEndure Migration can be used to rehost your Amazon EC2-hosted workloads from one AWS Region to another AWS Region.

Overview of CloudEndure Migration

CloudEndure Migration is a SaaS application that initiates and manages the replication of servers from one infrastructure to another. The servers can be virtual machines (VM), physical servers, or in this case, Amazon EC2 instances. The source infrastructure can be an on-premises data center, another cloud provider, or in this case, an AWS Region.

The replication is performed by a lightweight agent that is installed on each source instance that is to be replicated. This agent, which communicates securely with CloudEndure Migration over port 443 using TLS, scans the source instance for all attached disks and performs a block-level replication of those disks to the target Region. After the initial replication is completed, the CloudEndure Migration agent monitors any changes to the source instance and replicates those changes. This ensures the data stored in the target Region is always up to date.

The replicated data is stored in the target Region in a CloudEndure Migration staging area. The staging area is a VPC subnet, pre-configured by the customer, that hosts resources created by CloudEndure Migration using an AWS Identity and Access Management (IAM) user. This CloudEndure IAM user is created by the customer and grants CloudEndure Migration sufficient permission to create AWS resources in the target Region. These resources include Amazon EC2 instances with CloudEndure Migration replication software installed and a sufficient number of Amazon EBS volumes attached to match the number of disks being replicated. The CloudEndure Migration replication instances and volumes function as the replication targets for the source instances, and they store the continuously replicated data until the customer is ready to cut over.

Once the source and target are fully synced and in continuous data replication mode, the customer can choose to trigger the cutover or a cutover test. Once the cutover or test is initiated, CloudEndure Migration uses Amazon EC2 APIs to launch target instances and attach new Amazon EBS volumes. The volumes are created using the replication volumes in the staging area that are storing the replicated data. The new target instances and volumes are launched, into a new VPC or into an existing VPC created by the customer, depending on how CloudEndure Migration is configured. The new VPC replicates the networking and security settings from the source VPC.

CloudEndure Migration tutorial

For this tutorial, I assume that the reader already has a CloudEndure Migration account. If not, you can register for an account and you are granted a free license for 90 days. You also need a source AWS Region with Amazon EC2-hosted workloads running and a target AWS Region defined.

Migrating Amazon EC2 workload across AWS Regions include the following steps:

• Create a new migration project and configure the replication settings.
• Install the CloudEndure Migration agent on your source instances to begin replication.
• Configure the CloudEndure Migration Blueprints that is used to launch your target environment.
• Initiate cutover to the target Region.

Prerequisites

For this tutorial, you should have the following prerequisites met:

• A CloudEndure Migration IAM user with required credentials, as defined in the CloudEndure documentation.
• A staging area subnet created in the target Region, as defined in the CloudEndure documentation.
• A VPC and subnet in the target Region where our target instances will be launched.
• Connectivity between the source and target Regions using inter-Region VPC Peering or inter-Region AWS Transit Gateway where available.
• The security groups that will be attached to our migrated instances.
• Prepare your network in both Regions as defined in the CloudEndure documentation.

Setting up CloudEndure Migration

Once you have a CloudEndure Migration account and the prerequisites have been met, you can configure CloudEndure Migration.

1. Log in to the CloudEndure user console and create a new migration project.
2. You are prompted to set up the new project in the Setup & Info tab, beginning with entering the credentials for the CloudEndure Migration IAM user.
3. Go to Replication Settings to finish setting up your migration project.
   • Select your source and target AWS Regions.
   • Select a specific instance type for your replication server. For this tutorial, you can use the Default instance type.
   • For default disk type, choose Use fast SSD data disks. This speeds up the replication process by prompting CloudEndure Migration to use GP2 volumes for disks that are larger than 500 GB.
   • For the subnet, choose the subnet created for your staging area. This can be in a dedicated staging VPC or a VPC shared with other resources.
   • For this tutorial, choose Default CloudEndure Security Group.
   • You can select whether to use a public or private network for sending the replicated data from the source instances to the staging area. Choose Use VPN or Direct Connect and Disable public IP to direct replication traffic over your inter-Region VPC Peering Connection or AWS Transit Gateway.
   • You have the option of enabling encryption of the Amazon EBS volumes used by the replication instances to store replicated data. Encryption is performed using the AWS Key Management Service (AWS KMS) with the default Amazon EBS master key.
   • For Staging Area Tags, enter a Key and Value.
   • For Network Bandwidth Throttling, select Disabled. Enable this option only if you must control the amount of bandwidth used for replication traffic.

Installing the CloudEndure Migration agent and initiating replication

Next, install the CloudEndure Migration agent on each of the instances that will be replicated. Doing so initiates replication to the staging area.

1. After saving changes made in the previous steps to Replication Settings, you are presented with a dialog showing the instructions for downloading and installing the CloudEndure Migration agent for Linux and Windows machines.
2. Follow the instructions to download and to install the agent for each of your source instances. Once the agent is installed, it automatically scans all the disks attached to the source instance and begin replicating the data for all discovered disks, using the configuration defined earlier in Replication settings.
3. Once the CloudEndure Migration agent is ready to begin replication, the CloudEndure Migration SaaS application launches and configures the needed replication instances in the staging area. In addition, CloudEndure Migration initiates replication from the source instance to the replication instance.
4. You can track the replication progress in the Machines page of the CloudEndure console.
5. When replication is complete, the replication status changes from a progress bar to Continuous Data Replication. This indicates that initial replication has completed and source instance disks are being continuously synced to the disks in the staging area.

Performing a migration cutover

Once the initial replication is complete, you can conduct a migration cutover test or perform the actual migration cutover. The steps are the same for both. Before initiating cutover, you must configure the Blueprint for each target machine. The CloudEndure Migration Blueprint defines how the target environment is instantiated by CloudEndure Migration during cutover.

1. For each target machine, configure the Blueprint
   • For Machine Type, choose the instance type for the new target machine. The default is to Copy Source, which prompts CloudEndure Migration to use the same instance type as the source instance to launch the target.
   • Typically, you choose the same Launch Type as used by the source instance.
   • Choose the VPC and subnet where the target machine will be launched. For this tutorial, I use the VPC and subnet created as part of the prerequisite.
   • Choose the security groups that will be associated with the target machines. For this tutorial, I use the security groups created as part of the prerequisite.
   • For Private IP, choose Copy source if you are migrating over the CIDR range as well. For this tutorial, I configure this setting as Create new, since I am using a VPC with a different CIDR than the source.
   • For this tutorial, configure the Elastic IP address and Public IP address to be created to According to subnet configuration.
   • For Tags, enter a key and value.
   • For Disks, you can choose the same disk type as the source instance or a different disk type.
2. After the blueprint is saved for each target machine, you can initiate cutover by selecting each instance you want to launch and then choosing Launch Target Machines.
3. CloudEndure Migration initiates snapshots of all the Amazon EBS volumes in the staging area required to launch the selected target machines. The snapshots are used to create new Amazon EBS volumes that will be attached to the new target machines. You can monitor the progress on the Job Progress page in the CloudEndure Migration user console and see when the job is finished.
4. Since the target instance is an exact copy of the source instance, you can access the newly launched instance using the same SSH key used for the source instance.
5. For Microsoft Windows 2016 or later instances, there is a known issue where the target instances will not be able to access the AWS metadata service. This can be resolved by updating the EC2Launch service that is installed, by default, in our Windows instances. This should be done on the source machine before the CloudEndure agent is installed. To validate the migrated instance can access the Amazon EC2 metadata service, try connecting to the service in a web browser or using curl in a command prompt. The URL is 254.169.254/latest/meta-data.

Performing a migration cutover when including source networking and security

As discussed earlier, you can choose to migrate the source VPC networking and security configuration along with the source instances. That is accomplished by choosing Copy origin when defining the subnet and the security groups in the machine blueprint. Some things to be aware of and recommended practices to follow with this option:

1. Choose this option only if you are planning to cut over all instances in a single wave or in the first wave of a multi-wave migration. For each cutover launch where Copy origin is defined, CloudEndure Migration creates a new VPC, subnet, and security group. For example, a migration cutover done in five waves, each with Copy origin defined, creates five different VPCs, subnets, and security groups, all with identical names and CIDR but hosting different target instances.
2. To copy source networking and security in a multi-wave migration, choose Copy origin only in the first wave. In subsequent waves, define all machine blueprints to use the subnet and security groups created in the first wave.
3. For Windows instances, a public IP address is not assigned, even if According to subnet configuration is defined in the blueprint and the source Windows instance has a public IP address. You must explicitly choose Yes for Public IP in the machine blueprint.
4. If the source VPC has a network address translation (NAT) gateway, it will not be replicated in the target VPC. A new NAT gateway will need to be created in the target VPC.
5. CloudEndure Migration will automatically create and attach a Classic Elastic Load Balancer (ELB) in the target VPC if one exists in the source VPC. CloudEndure Migration will not recreate an Application Load Balancer (ALB) or a Network Load Balancer (NLB).

Cleaning Up CloudEndure Migration

After cutover is validated, uninstall the CloudEndure Migration agent by removing machines from the CloudEndure user console.

1. Choose Machine Actions.
2. Choose Remove Machines from This Console. It takes up to 60 minutes for CloudEndure Migration to clean up the replication instances and volumes in the staging area.
3. When all of the agents are uninstalled, delete the staging area VPC. This deletes all AWS resources that you created for replication.

Conclusion

In this post, I walked through how CloudEndure Migration can be used to rehost your Amazon EC2-hosted workloads from one AWS Region to another. Businesses and government agencies have to be able to respond quickly to a rapidly changing world. Some of the changes may require customers to make adjustments to their IT infrastructure, including migrating workloads acrosss AWS Regions to reduce latency or to increase resiliency. This can be accomplshed with minmal downtime by leveraging CloudEndure Migration for continous replication and to automate the creation of migrated resources. CloudEndure Migration enables you to focus on the business outcome while simplifying the migration process and allowing AWS to take over the undifferentiated heavy lifting of managing the migration software.

To learn more about CloudEndure Migration, please visit the CloudEndure Migration page and read the official CloudEndure documentation.

Thanks for reading this blog post! If you have any comments or questions, please don’t hesitate to leave them in the comments section.