How Rackspace Uses CloudEndure to Accelerate Workloads Migration to AWS

By Alan Day, AWS Specialist Solution Architect at Rackspace
By Prasad Rao, Partner Solution Architect at AWS

Enterprises have a longer road to travel than their smaller SME counterparts when transforming and migrating multiple workloads to the cloud. For many large organizations, the same question tends to be at the top of the priority list: how do we migrate workloads quickly and efficiently to meet business objectives?

In large legacy migration scenarios, we find that most companies start with migrating or rehosting their applications as-is in the cloud. We also find you can more easily modernize or re-architect applications after they’re already running in the cloud.

This is partly because organizations have developed the skills to do so, and partly because the hard part — migrating the application, data, and traffic — has already been done.

However, the size and complexity of the initial migration can be complicated for many enterprises, which is why we see migrations taking much longer for large organizations that want to make the transition.

This post explains how to migrate (lift and shift) multiple workloads at speed using CloudEndure Migration, and how Rackspace can help guide this migration.

Rackspace has created reusable design artifacts together with automation to describe and deploy a collection of AWS services capable of hosting CloudEndure Migration. This solution provides full IP connectivity between your data center and Amazon Web Services (AWS) whilst authenticating access to staff members via AWS Client VPN services.

Rackspace is an AWS Premier Consulting Partner with seven AWS Competencies, including Migration and DevOps. Rackspace is also a member of the AWS Managed Services Provider (MSP) and AWS Well-Architected Partner Programs.

Designing the Solution

For simplicity, let’s start with a single (Target) AWS account with two Amazon Virtual Private Clouds (VPCs). One VPC hosts the CloudEndure infrastructure, which is used as a lightweight replication staging area. A second VPC deploys migrated workloads.

The source data center connects to AWS via AWS VPN or AWS Direct Connect. We use AWS Transit Gateway to provide full IP connectivity between the source data center and all VPCs in the AWS account.

Figure 1 – Simplified high-level solution architecture.

Building AWS Account Structures

As a best practice, we generally separate workloads per AWS account or VPC, with security, cost separation, and compliance the most common factors driving decisions.

During migration, CloudEndure deploys Amazon Elastic Compute Cloud (Amazon EC2) instances from replicated server images into destination VPCs automatically, so long as they are in the same AWS account as the CloudEndure project.

The diagram in Figure 2 illustrates AWS Transit Gateway connecting multiple VPCs from different accounts within the same region. Using AWS Resource Access Manager (RAM), you can share Transit Gateway and connect VPCs in different accounts.

We recommend you create a separate CloudEndure project for each AWS account because sharing EC2 images between accounts is a manual process, and it can significantly impact timelines depending on the size of the migration.

Figure 2 – Single region, multi-account, multi-VPC solution overview.

Connecting multiple accounts from different regions is outside the scope of this post. However, if you find yourself in that situation, then AWS Direct Connect Gateway, AWS Transit Gateway, and Transit Gateway peering can provide a highly secure, high-bandwidth solution between regions.

This AWS re:Invent reference architecture session runs through this nicely.

High-Level Solution Overview

The architecture in Figure 3 represents the overall blueprint design that we build in a Target AWS account to migrate workloads at speed.

You can connect additional AWS accounts with CloudEndure project deployments to the source data center using the AWS Transit Gateway hosted within this account.

Figure 3 – Blueprint architecture providing connectivity and access to enable migration.

From a high-level architecture perspective, we perform the following tasks:

• Use AWS Transit Gateway to provide full IP connectivity by consolidating connections from VPCs, Direct Connect circuits, and VPN tunnels. By creating a connected network, we enable data transfer between the source data center and all destination VPCs.
• Use AWS Simple AD to provide authentication to AWS Client VPN users, and allow staff the flexibility to work from home or the office.
• Provision CloudEndure replication instances automatically to perform server replication activities from the CloudEndure console.
• Provision test servers from replicated images to perform basic operating system checks before we deploy them to their final resting place in the target VPC.
• Provision NAT Gateways to enable communication between the replication servers and CloudEndure console. If needed, test servers can also access the internet.
• Deploy a small Amazon EC2 instance with the Active Directory tools installed to allow management of AWS simple AD users and groups.

AWS Transit Gateway Configuration

Rackspace automates much of the infrastructure creation, but the following sections describe the main AWS services’ configuration included in this post. Please refer to AWS documentation for detailed instructions.

Within the AWS Transit Gateway console, create a new Transit Gateway. Make sure to allow the “Auto accept shared attachments” option to enable cross-account attachments.

In this example, we are using AWS Direct Connect, so we’ve created a Direct Connect Gateway that is associated with Transit Gateway. This allows IP connectivity between AWS and the on-premises data center.

To allow VPCs from external AWS accounts to attach to Transit Gateway, we created a Transit Gateway Resource share using Resource Access Manager (RAM).

You need to take three steps to allow Transit Gateway Attachments from external accounts to complete successfully:

• Create a resource share for Transit Gateway within RAM. Add external account IDs to allow successful cross-account attachment to the Transit Gateway.

• Accept the Transit Gateway share in all external accounts by navigating to the RAM console and accepting the resource share.

• Create a Transit Gateway attachment for each VPC you need to connect to Transit Gateway. Make sure to select the newly available shared transit gateway.

After Transit Gateway configuration is complete, you’ll see all VPC attachments in the Transit Gateway console along with the attachment to Direct Connect Gateway.

With route propagation enabled for Transit Gateway, you also see routes to each connected network.

Finally, you must add routes to the route tables for each VPC attached to the Transit Gateway. This ensures each VPC knows to send traffic designed for other attached VPCs to the Transit Gateway.

Traffic arriving at a VPC that does not have the relevant return routes configured tries to return via the default route and ultimately gets dropped. In the following example, this is the NAT Gateway.

AWS Client VPN Configuration

AWS VPN users can traverse different networks connected via AWS Transit Gateway if they have been authorized to do so. Users added to groups within AWS Directory Service are authorized to access specific networks through the configuration of AWS Client VPN.

You can configure authentication through Active Directory, mutual (certificate-based), and single sign-on (SSO) through SAML-based federated authentication. The remainder of this post focuses on providing authorization via Active Directory group membership.

We have detailed the main steps required to set up AWS Client VPN in this section. Please refer to AWS documentation for detailed instructions.

The first step is to create a new AWS Simple AD. You can use an existing AWS AD or an on-premises Active Directory by configuring an AD Connector. We like to use AWS Simple AD to keep identities separate and secure. After you do this, create a new Client VPN Endpoint.

AWS Client VPN needs at least one target network association to enable clients to connect to it and establish a VPN connection.

All subnet associations must be from the VPC you selected during setup. If you did not select a VPC during setup, you can select any VPC in your account, but all subsequent subnet associations must then come from that VPC.

Grant VPN users access to remote networks by creating authorizations. It’s a best practice to have an authorization rule for each network to which you want to grant access.

The following example shows access granted to different networks based on Active Directory group membership.

Rackspace migration engineers can access only the VPC housing the CloudEndure project and the source migration data center, whereas Internal IT staff can access only the source data center and the migration target VPC.

Allowing VPN users access to all networks has been denied in favor of more granular AD group membership control.

Group ID is the security identifier (SID) of the Active Directory groups authorized to access a given network. It’s important when using Active Directory groups to add the SID of the Active Directory group to make sure authorization is operational.

The AWS Client VPN route table provides routes to each of the destination networks available in the solution. In this example, we can see the following routes:

• Default route created automatically by AWS when we associate subnets from the VPC that Client VPC is associated with.
• Route to data center added manually to provide access to the source data center. The route goes via AWS Transit Gateway.
• Migration target VPC added manually to provide access to the migration target network. This route goes via AWS Transit Gateway if it’s external to the VPC associated with AWS Client VPC.

When adding a new route, we use the subnets associated with the VPC selected during the creation of the Client VPN endpoint as the next hop. Network packets are then routed via the VPC router to the Transit Gateway.

For redundancy, we have created two routes for each destination by using subnets from both zones of the associated VPC attached to Client VPN endpoint.

The AWS VPN client is free to download. To connect to the AWS Client VPN service, the following steps will get you up and running:

1. Download and install AWS VPN client software from AWS.
2. Download the AWS Client VPN configuration from the Client VPN endpoint console.
3. Import AWS Client VPN configuration into the Client software.
4. Log in to AWS Client VPN with a user who belongs to an authorized AD Group.

Administrative access to compute resources becomes much more flexible, allowing you to work from the office or home.

After you connect, you have IP connectivity from your local workstation to any network connected to Transit Gateway. You can transfer files between connected networks and log on to the console of any compute instances for which you are authorized.

Summary

At Rackspace, our Professional Services teams wrap governance and process around a migration to AWS. Through clear project management, they make sure to migrate workloads into AWS in the right order according to business goals and objectives.

Rackspace migration engineers will set up and configure CloudEndure Migration on your behalf, setting up replication from the source data center into the relevant CloudEndure project within AWS.

Rackspace architects design target VPCs to include complimentary AWS services, such as load balancing, caching, or managed database services. Then, Rackspace engineers deploy the target VPCs that are ready to receive replicated workloads.

To learn more about how Rackspace Professional Services can assist with your business challenges related to digital transformation, migration, and application modernization, visit the Rackspace website.

.

.

Rackspace – AWS Partner Spotlight

Rackspace is an AWS Premier Consulting Partner that combines specialized AWS expertise with advanced operational tooling to help businesses realize the power of the AWS Cloud.

Contact Rackspace | Partner Overview

*Already worked with Rackspace? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.