Seamless Transition from an AWS Landing Zone to AWS Control Tower

By Pavan Kumar Alladi, Sr. Cloud Architect – Tech Mahindra
By Thooyavan Arumugam, Sr. Cloud Architect – Tech Mahindra
By Santhana Krishna K, Principal Cloud Architect – Tech Mahindra
By Amit Kumar and Shonil Kulkarni, Partner Solutions Architects – AWS

Tech Mahindra

Amazon Web Services (AWS) provides a secure cloud environment for customers to run their workloads and enable them to experiment, innovate, and scale more quickly.

At Tech Mahindra, setting up a secure, scalable, and resilient multi-account environment is one of the most common requests from customers.

AWS Landing Zone initially launched as a solution to help customers more quickly set up a secure, multi-account AWS environment based on AWS best practices.

This was a self-managed AWS solution which automates the setup of an environment for running secure and scalable workloads. It creates a baseline environment to get started with a multi-account architecture, identity and access management, governance, security, network design, and logging.

Success of the AWS Landing Zone solution and continuous requests from customers led to the launch of AWS Control Tower, a managed service to help customers easily set up and govern a secure, multi-account AWS environment.

Many customers currently using the self-managed AWS Landing Zone solution are looking to transition to AWS Control Tower to gain additional benefits.

This post describes a strategic collaboration between Tech Mahindra, AWS, and a customer to transition from AWS Landing Zone to the AWS Control Tower environment.

Tech Mahindra is an AWS Advanced Consulting Partner with the Migration Competency that specializes in digital transformation, consulting, and re-engineering solutions. Tech Mahindra is also a member of the AWS Managed Service Provider (MSP) and AWS Well-Architected Partner Programs.

Project Scope and Background

The customer we’ll reference in this post is a large African telecommunication and network services provider that offers voice, messaging, data, and converged services to millions of users in that geography.

The customer had their landing zone built based on the AWS Landing Zone solution and was primarily focused on the AWS Ireland Region. They engaged Tech Mahindra to review their existing solution and to design and implement a new landing zone which could manage and govern environments in the AWS Ireland and AWS Cape Town Regions.

A strategic collaboration between the customer, AWS, and Tech Mahindra was established to assess their current implementation, set up a new Control Tower environment, and transition from AWS Landing Zone to AWS Control Tower.

Key outcomes expected from this engagement were:

Secure, multi-account AWS environment across the AWS Ireland and Cape Town Regions with automated security, governance, and compliance.
Reduced risk and faster AWS adoption of accounts that are scalable, secure, and governed according to customer requirements.
Transition to AWS Control Tower by migrating all accounts governed under the AWS Landing Zone solution without any business impact.

Challenges

Below are some of the key challenges encountered during this engagement:

Unavailability of AWS Control Tower and some of the core dependent services in the AWS Cape Town Region at the time of project initiation.
AWS Organizational Unit (OU) restructuring from a nested OU structure to a flat OU structure supported by AWS Control Tower.
Service control policies (SCP) realignment and consolidation to meet and align according to the customer requirements, new OU structure, and AWS Control Tower.
Transition of 140+ accounts from current AWS Landing Zone setup to new management account (payer account) setup under AWS Control Tower with minimal or zero disruption to business.
Transition of key service accounts like network accounts on which other workload accounts depends with minimal or zero disruption to business.
Configuration change for services that are using the previous AWS Landing Zone organization ID to AWS Control Tower organization ID with minimal or zero disruption to business.

High-Level Solution Overview

Tech Mahindra, in collaboration with AWS, took a customer-first approach for this engagement to suggest a solution with the flexibility to adopt any future changes with the least amount of work and with minimal or zero disruption.

The solution included setting up a new landing zone using AWS Control Tower under a new management account (payer account) to help the customer manage and govern at scale.

The following architecture diagram depicts the multi-account landing zone solution using AWS Control Tower.

Figure 1 – Multi-account landing zone architecture using AWS Control Tower.

The multi-account environment established during setup includes:

AWS management account under root, log archive, and audit account under security OU.
Custom accounts for network, shared services, management, and workload accounts.

The solution was designed and deployed under a new management account (payer account) that helped the customer meet current requirements with the flexibility to evolve it over time with changes.

This architecture provides the following benefits:

Multi-account structure that mitigates deployment risk by creating an isolation boundary for each business and supports multiple operating models.
Centralized identity management and permissive guardrails for efficient access management.
Centralized logging and audit account for implementing SecOps best practices.
Data isolation to meet compliance requirements.
Centralized catalog management using AWS Service Catalog to deploy resources, achieve consistent governance, and meet the compliance requirements.
Multi-account strategy to help distinguish costs across accounts and isolate different workloads for fiscal and billing purposes.

Designing the Solution

Detailed requirement-gathering workshops were conducted with the customer’s stakeholders to discover and analyze the current implementation. Together, we reviewed the current AWS Landing Zone implementation and worked to understand the business and technical drivers needed to transition to AWS Control Tower.

Key tasks for this engagement included:

Assessment of the customer’s current state AWS Landing Zone solution; as-is resource discovery.
New landing zone setup using AWS Control Tower.
New AWS Organizations setup using OU structure and Account Factory according to the new design based on the customer requirements.
Implement secure and operational account access mechanism.
Implementation of detective and preventative guardrails for all accounts under AWS Control Tower.
Automate the setup of predefined baseline and resources in every new account using Account Factory and lifecycle events triggers.
Migrate the accounts under AWS Landing Zone setup to new setup based on Control Tower.

Tech Mahindra designed a solution to help the customer securely manage the multi-account AWS environment and provide seamless governance with less manual intervention.

As shown in Figure 2, the solution’s workflow automates baseline setup for the AWS accounts covering the Cape Town Region. Due to a specific hard limitation (Region opt-in), Tech Mahindra built a semi-automated solution enabled through AWS Step Functions. An opt-in process was a prerequisite to setup resources in the Cape Town Region, which has been semi-automated using this approach.

Figure 2 – Baseline setup using an AWS Control Tower lifecycle event.

The solution uses multiple AWS Service Catalog products that deploy AWS resources in the Cape Town Region as part of the account creation workflow, and ensures compliance management.

Target Organizational Unit Design

The customer’s existing Organizational Unit structure was aligned based on their business structure and group functions. This was one of the pain points of creating and applying standard policies in the current setup. The current OU design in AWS Landing Zone follows a nested OU structure.

AWS Control Tower currently support a flat OU structure, which led to the creation and restructuring of OUs based on Control Tower guidelines. A policy driven structure was also designed and eliminated some of the legacy built around the guardrails.

The new OU structure helped customer with:

Centralized governance with strong security, operations, and compliance policies management.
Ease of management and account search with reduced risk due to segregation.
Simplified approach to guardrails implementation and tag-based classification.

The OU structure was created and registered using the AWS Control Tower service pane. The following diagram represents the customer’s OU structure.

Figure 3 – Organizational Unit structure.

Service Control Policy Restructuring and Consolidation

Service control policies (SCPs) help an organization to centrally manage and define access control permissions for accounts in an organization. SCPs establish a broader restriction across AWS accounts.

In this case, SCPs were defined when the AWS Control Tower environment was created to meet the following requirements:

Ensure resources are only deployed in approved AWS Regions.
Protect sensitive data from being shared externally.
Actions denied at organization level.
Protect centrally provisioned resources from modification.
Allow deny services and actions.

Tech Mahindra restructured the SCP based on the customer’s requirements to define the permissions. They also ensured services are allowed under the current AWS Landing Zone setup don’t have any impact with the new SCP structure under AWS Control Tower.

Figure 4 – Service control policy structure.

Transitioning AWS Accounts

Tech Mahindra developed a plan to transition accounts from AWS Landing Zone to AWS Control Tower without any business impact. A detailed as-is assessment was conducted to gather information about all of the existing AWS accounts, environment, and workload mapping. This included dependency, criticality, and cost of running the workloads.

A phased approach was taken to transition accounts to mitigate any risks considering the transition of more than 140 accounts involved multiple business groups in the customer’s organization.

AWS accounts which needed to be transitioned are broadly divided into two categories:

Business accounts: AWS accounts which serve the business users.
Service accounts: AWS accounts which host services and are shared across all other business accounts. This includes network, security, and shared services.

Business accounts were further divided into three groups: sandbox accounts, accounts which are less critical, and customer-critical service accounts.

The transition wave group depicted in Figure 5 was defined based on the environment and criticality of services running in the accounts. Detailed steps were developed for migrating business accounts followed by service accounts to ensure a seamless transition.

Figure 5 – Transition wave group.

Prerequisites

The prerequisites for implementing the AWS account transition are as follows:

Creation of a role named ‘AWSControlTowerExecution’ in each account, which has to be transitioned with a trust to the management account where Control Tower is deployed.
Termination of the AWS Service Catalog products provisioned in the existing AWS linked accounts.
Deletion of delivery channels and AWS CloudTrail deployed by AWS Landing Zone to remove any conflict that may arise during the account enrolment process under AWS Control Tower.

Transition of Business Accounts (AWS Linked Accounts)

An automated solution workflow was developed to streamline and reduce risks of manual error during the transition process for each AWS linked account:

Deletion of AWS Config Recorder.
Deletion of delivery channels across Regions.
Deletion of AWS CloudTrail.
Leave the existing organization under AWS Landing Zone.
Enroll the account to a new AWS Organization under Control Tower.
Add account IDs to AWS Resource Access Manager (RAM) as external principal to ensure resources like AWS Transit Gateway and Route 53 Resolver are shared continuously during and after the transition.

Wave Group 1: Transition process for business accounts (sandbox):

Delete the AWS Service Catalog product created by the Account Vending Machine to remove resources created by AWS Landing Zone.
Implement the automation to ensure Config Recorder, delivery channels, and CloudTrails deployed by Landing Zone are deleted and the accounts join the new organization.
Move the account to the corresponding OU by enrolling it using Account Factory.

Wave Group 2-3: Transition process for business accounts (non-prod and prod account):

Delete the AWS Service Catalog product created by the Account Vending Machine to remove resources created by AWS Landing Zone.
Implement the automation to ensure Config Recorder, delivery channels, and CloudTrails deployed by Landing Zone are deleted and the accounts join the new organization.
Ensure the account ID is added as external principal by the script.
Move the account to its corresponding OU by enrolling it using Account Factory.

Transition of Service Accounts (AWS Linked Accounts)

Wave Group 4: Prerequisites

Service accounts act as key accounts since they host services on which all of the other accounts are dependent to work. The transition of service accounts required additional prerequisites to be added to the above list, which had to be met before moving the accounts under Control Tower:

Ensure the account was not a delegated administrator for any of the AWS services which allow accounts to be delegated administrator. Refer to the list of services that support a delegated administrator.
Ensure there aren’t any polices which use Organization ID to deny actions.
Ensure services which can work with AWS Organizations have a workaround when moved under new Control Tower management account.

Transition Process Adhered for Service Accounts:

Delete the AWS Service Catalog product created by the Account Vending Machine to remove resources created by AWS Landing Zone.
Run the AWS Lambda script to ensure Config Recorder, delivery channels, and CloudTrails deployed by Landing Zone are deleted and the accounts join the new organization.
Ensure the account ID is added as an external principal by the script.
Move the account to its corresponding OU by enrolling it using Account Factory.
After enrollment, restore the RAM share back to the Organization ID and remove the account ID added as external principal.

Customer Benefits

This transition from a self-managed AWS Landing Zone solution to an AWS Control Tower service resulted in reduction of technical debt for the customer.

Key customer benefits achieved are:

Rapid account provisioning capability based on defined policies.
Ease of governance and compliance at scale.
Integrated automations for security, operations, and compliance management.
Reduction in effort and time to publish AWS resources as product-as-a-service by using centrally managed AWS Service Catalog resources.

Summary

A well-architected multi-account AWS environment helps businesses use AWS to migrate, modernize, and innovate faster. A managed AWS Control Tower service helps customers achieve desired business outcomes by setting up a scalable, secure, and governed multi-account environment.

In this post, we showed how Tech Mahindra helped a customer to seamlessly transition from AWS Landing Zone to a new Control Tower-based solution and how it spearheaded the transition of more than 140 AWS accounts from AWS Landing Zone to a Control Tower environment.

.

.

Tech Mahindra – AWS Partner Spotlight

Tech Mahindra is an AWS Advanced Consulting Partner and MSP that specializes in digital transformation, consulting, and business re-engineering solutions.

Contact Tech Mahindra | Partner Overview

*Already worked with Tech Mahindra? Rate the Partner

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

AWS Partner Network (APN) Blog