Migrating custom Landing Zone with RAM to AWS Control Tower

The AWS Landing Zone is a solution that helps customers accelerate the setting up of a secure, multi-account AWS environment based on AWS best practices. In June 2019, AWS launched AWS Control Tower. AWS Control Tower is a managed AWS service that automates the creation of a multi-account AWS environment based upon the AWS Well-Architected Framework. It builds the environment using AWS best practices for security and management services.

AWS Control Tower provides customers with the capability to provision a multi-account AWS environment with centralized governance through built in guardrails, centralized AWS account management, centralized access management, a monitoring dashboard and standardized account provisioning through an automated account factory. With the AWS Control Tower, customers are able to provision a highly scalable Landing Zone, that complies to AWS best practices, in under 30 minutes with a few clicks from the AWS Console.

AWS Control Tower provides the ability to enroll an existing AWS account into a specific OU via the Register OU feature. Enrolling an existing account will not alter the existing Virtual Private Cloud (VPC) setup or configuration within the account. This feature allows customers to migrate from their existing Landing Zone setup to the AWS Control Tower with ease. The AWS Control Tower also has a set of guardrails which are applied via Service Control Policies (SCP) and AWS Config Rules to govern your overall AWS environment using AWS Best Practices. The AWS Control Tower also provides a centralized dashboard to monitor compliance of the applied guardrails. It is important to reapply the current SCPs to ensure your Landing Zone security posture remains consistent. In this blog, we will cover a customer scenario where the customer will migrate from their custom Landing Zone, that leverages AWS Resource Access Manager (RAM), to an AWS Control Tower managed Landing Zone.

Customer Scenario

The customer has an existing AWS Custom Landing Zone they built themselves by deploying AWS Organization for consolidated billing, and centralized control management via Service Control Policy (SCP). The AWS Management Account which hosts the AWS Organization is also used as a shared services account. The customer leverages AWS RAM to share subnets and the AWS Transit Gateway to the other AWS accounts in their current Landing Zone. The customer has more than 5 AWS accounts that are leveraging the AWS RAM shared services. The customer aspires to build their Landing Zone following AWS Best Practices, especially in terms of security and scalability. The first step taken to achieve these requirements is to migrate to the AWS Control Tower managed Landing Zone.

Migration Methodology

The Landing Zone Migration to the AWS Control Tower was executed in 3 phases over a period of 8 weeks.

1. Landing Zone Discovery

A discovery questionnaire was used to gather insights on the customer’s existing Landing Zone setup. The questionnaire covered account information, account strategy, Landing Zone architecture, network topology (within AWS and external connections), account dependencies, current preventive and detective guardrails, user access, centralized access configuration, application inventory, security baselining, and AWS RAM configuration. The questionnaire was completed by running multiple workshops with the customer’s IT Team, and was further validated via read only access to the customer’s AWS Console.

2. Landing Zone Planning & Validation

Prerequisite Tasks – These were the tasks that needed to be performed prior to the migration. The goal was to remove as many dependencies as possible to de-risk and speed up the migration.

• Firstly, we needed to understand the application inventory, business criticality, key contacts, the backup policy, backup schedule and backup status.
• For all member accounts in the current AWS Organization (Landing Zone), the customer needed to have root user account access or AWS Identity and Access Management (IAM) access ready for the migration.
• In order to remove a member account from the current AWS Organization, it must have the account information required for it to operate as a standalone account. This is a necessary step before the account can be migrated to the new organization (AWS Control Tower). So for each account, the customer needed to choose a support plan, provide and verify the required contact information, and provide a current payment method. Be aware that suspended accounts also need to be updated with this information. More information here Removing a member account from your organization – AWS Organizations.
• As AWS Single Sign On (SSO) was being used, we needed to ensure federation information, user and group access was collected and understood.
• We needed to check and document the Organization Service Control Policy (SCP) for potential controls that will be impacted by the AWS Organization migration.
• We needed to verify if any of the accounts were using EC2 Auto Scaling Groups, as scaling events would fail during the migration if AWS RAM was used to share the VPC/Subnets. To avoid this issue, you can temporarily set the scaling properties to Min = Max = Desired, and revert to the original configuration after the migration is complete.
• We needed to understand the current Direct Connect and VPN connections to accounts on AWS. This might need to be realigned for some migrations but it was not necessary in this particular case.
• We needed to review and document the current AWS RAM configuration. Any existing RAM sharing at the AWS Organizational level would need to be changed to account level sharing prior to the migration. This ensures the sharing works in the new AWS Organization, which has a different Organization ID post migration.
• We needed to understand if discounted pricing models (Reserved Instances or Savings Plans) were used and plan for their utilization in the new AWS Organization. It’s important to note that plans will remain under the account where they were purchased, so you need to decide on the sharing strategy in the new Organization. More information here for Turning off reserved instances and Savings Plans discount sharing.
• We downloaded the Cost and Usage Report (CUR) from the management account’s billing dashboard, as this would no longer be accessible post migration. Historical invoices are retained if the original management account becomes a member account in the new AWS Organization.
• We created a new management account (for a new AWS Organization) which acted as the primary account for the Control Tower setup. This account was configured with either the same service quotas or more than the current Landing Zone primary account. We set the following service quotas – VPC limits, Transit GW limits, EIP limits, Customer Changed limits, and Accounts Limits for Control Tower.
• We made sure the new AWS account (primary Control Tower) enforced the same SCP as the current Landing Zone primary account, ensuring the existing policies would be met in the new Control Tower Landing Zone.
• Finally, we socialized the cutover plan with the application owners and infrastructure teams that were going to be involved in the migration, and we executed dry runs to help them understand their role in the migration.

Validation – We performed multiple tests at various stages of the planning process. Firstly, we tested a migration to understand the impact of RAM sharing, as the results would feed into planning the prerequisite tasks. Once we were confident that all tasks were captured and correctly sequenced, we then tested again to validate our steps and understand the estimated time required to perform the migration. The test results were used as inputs for the change management process, and to garner the support of the application teams.

Architecture Diagram – illustrations

Figure 1: Existing AWS Account with Resource Access Manager (RAM) to AWS Control Tower.

Test plan for the first test we performed:

• We created three AWS test accounts. For illustration purposes, we will call them account A, B and C.
• In account C, we setup the AWS Control Tower. Please note it takes approximately 35 minutes to complete the setup.
• In account A, we setup the AWS Organization and joined account B to the Organization.
• We created a test VPC and two public subnets on account A.
• We enabled resource sharing through AWS RAM on account A and shared the two public subnets via organization level sharing to account B.
• In account B, we accepted the shared resources. Then we launched two test EC2 instances into the shared subnets and configured the security groups so they could communicate between themselves and to the internet (via ICMP).
• On the EC2 instances, we ran continuous pings between both instances, and also to resources on the internet and on-premise via VPN/Direct Connect. We were testing to make the migration does not impact north-south and east-west network traffic.
• Then we started the testing by first changing the AWS RAM sharing from organization level to account level sharing.
• We removed account B from the AWS Organization, ensuring it had the necessary account information to become a standalone account before being removed from the organization.
• We joined account B to the AWS Control Tower Organization on account C.
• We joined account A to the AWS Control Tower Organization on account C and deleted the AWS Organization on account A.
• We re-established the AWS RAM sharing by enabling resource sharing from an organization level on account C. Refer Sharing your AWS resources – AWS Resource Access Manager for guidance.
• We enabled RAM sharing on account A and shared the subnets to account B. Once sharing acceptance was completed, the resources in account B became visible and manageable.
• We enrolled account A and B into the AWS Control Tower hosted by account C.
• Throughout the migration, there were two key observations:
  1. There was no ping drop between the EC2 instances and there was also no ping drop between EC2 instances and the internet/on-prem.
  2. During the migration, the resources stayed up but couldn’t be managed (e.g. stop/start). This was an important finding and the reason we prevented auto-scaling during the actual migration.
• The test above can be expanded to multiple accounts with multiple shared resources to simulate a customer’s actual scenario. The result should be similar with no network ping drop throughout the migration, and the resource(s) will be in an unmanaged state until the migration is complete and RAM is re-initiated.

3. Cutover

• We built an end to end cutover plan based on the characteristics of the customer’s custom Landing Zone which we validated with multiple test cycles. So, it’s important to follow a similar approach to create your own cutover plan.
• The cutover plan should include both prerequisite tasks and migration specific tasks. It is also very important to sequence the accounts to be migrated, starting with the accounts hosting the least critical applications and ending with the accounts hosting the most critical applications. This way, if issues are detected early in the migration, you will have time to rectify or rollback without impacting the critical applications.
• If you plan to migrate the original management account to become a member account in the new AWS Organization, then you need to migrate this account last. This is because all the member accounts must leave an Organization before the management account can be moved. Once this account has left the Organization, you can delete the old Organization and this account can join the new Organization.
• It is also very important to build a rollback plan. During the test scenario above, additional steps can be introduced to test rollback procedures.
• In case of a rollback, please note that the AWS Organization ID and AWS SSO domain name (if used) will change. It is also necessary to backup the Cost and Usage Report (CUR) so you can still access historical cost data pre-migration.

Landing Zone Migration Execution

1. It is highly advisable, even though there should be no drop in network traffic during the migration, to invoke a maintenance page for all applications. This is to prevent data inconsistency during the migration.
2. Ensure all prerequisite steps are executed prior to starting the migration.
3. Ensure the infrastructure, application, security, operations and database teams are on standby during the migration.
4. Execute the migration and enable RAM sharing in the new Organization if it’s being used. Any shares that were changed from organization level to account level prior to the migration must be changed back to organizational level shares from the old management account.
5. Enroll the migrated accounts into AWS Control Tower and proceed to apply the AWS best practices as per the AWS Control Tower User Guide.
6. Finally, ensure the application teams perform full functionality tests prior to removing the maintenance pages.

Key Consideration/Learnings

• AWS Support – It is recommended to have AWS Business Support or AWS Enterprise support when executing this migration. This is to ensure the right support level is provided in a timely manner during the migration. If the customer has Enterprise Support, the TAM should be involved in both the planning and execution phases.
• Account Standalone Information – It is recommended to open a support case with the AWS Billing Team / AWS Concierge team prior to the migration, so they can make sure the accounts have the required information to operate as standalone accounts during the migration.
• Backup and Maintenance Page – It is important to perform full backup of all applications prior to the migration and place the applications into maintenance mode during the migration.

Partner Reference

If you are looking for a partner that has successfully executed custom Landing Zone with RAM migration to AWS Control Tower :

Cloud Comrade is the first Singapore Headquartered AWS Partner Network Premier Tier Consulting Partner with offices in Indonesia and Malaysia. The company has more than 100 AWS certifications along with AWS SAP and Migration Competencies, and MSP, and Well-Architected program validations. Cloud Comrade has helped more than 400 organizations across ASEAN to migrate to Cloud and more than 100 of them are Cloud Comrade’s monthly managed services customers. Cloud Comrade specializes in Landing Zone builds, control tower implementations, and complex, agile mass-migrations both for Cloud Comrade and AWS Managed services managed workloads.

Conclusion

The AWS Control Tower can help customers centrally manage their Landing Zone leveraging predefined guardrails to ensure security and compliance of their AWS Cloud environment. The AWS Control Tower supports enrollment of existing AWS accounts for centralized management and standardization. Customers can bring their existing practices and resource configurations such as AWS Resource Access Manager (RAM) to manage their workloads in the cloud. This capability introduces minimum change to their existing operating model and will allow customer to excel in an agile and safe manner in the cloud.

About the authors