TL;DR:
This is the second part of a two-part blog series.
In this blog, we take a deeper look at AWS Control Tower migration options, control management approaches, and a real-world enterprise migration journey involving more than 200 AWS accounts and business-critical workloads. The customer already had a mature AWS environment with custom-built security, governance, logging, account provisioning, and compliance controls.
We’ll walk how the organisation migrated its existing AWS Organization to AWS Control Tower without disrupting application workloads, the challenges and considerations involved in bringing existing accounts under Control Tower governance, and how the migration helped strengthen its overall cloud security, compliance, and governance posture.
Introduction
The previous blog covered AWS Control Tower capabilities, control types, and governance options. In this blog, we’ll focus on migration to AWS Control Tower, control management, and account vending, and how these options can be tailored to different customer requirements. We’ll also look at a real-world journey of how an organisation migrated its existing AWS Organizations + Terraform/CloudFormation + custom account vending and baselining — to AWS Control Tower + AFT without disrupting business-critical application workloads.
Table of Contents
Migration to AWS Control Tower
Both greenfield and brownfield customers can adopt AWS Control Tower. There is no additional charge for AWS Control Tower itself; customers only pay for the underlying AWS services that Control Tower enables and uses within the landing zone. Migration to Control Tower can be explained using the below 4 topics.
- Multi Account Governance Options
- Control Tower Enablement Options
- Control Tower Mandatory Controls
- Existing OU / Accounts Enrolment Pre-Checks
Multi Account Governance Options
Before adopting Control Tower, customers have several options for managing a multi-account AWS environment. The right approach depends on their existing architecture, skills, compliance requirements, and the level of customisation required.
- Custom Landing Zone – AWS Organizations + Terraform/CloudFormation + custom account vending and baselining
- AWS Control Tower
a. Control Tower + Account Factory Customization (AFC)
b. Control Tower + Customizations for AWS Control Tower (CfCT)
c. Control Tower + Account Factory for Terraform (AFT)
d. Control Tower + Landing Zone Accelerator (LZA) - AWS Organizations + LZA
AWS supports both Control Tower and Organizations as foundations for LZA, although AWS recommends Control Tower as the foundational landing zone where supported. Control Tower also supports AFC, CfCT, and AFT for different account provisioning and customisation requirements which we will cover in the later part the blog.
Control Tower Enablement Options
- For greenfield customers, the choice is relatively straightforward: establish the required landing zone and start vending governed accounts into it.
- For brownfield customer, this becomes interesting. Most enterprises already have AWS accounts and workloads in production. Some started with basic AWS Organizations structures and gradually built custom account vending, security baselines, logging, and governance automation. As the number of accounts grows, maintaining consistent standards across both existing and newly created accounts can become a significant operational burden. These customers may want to move towards a more AWS-managed multi-account platform to reduce operational effort, improve security and governance consistency, and accelerate the delivery of new AWS accounts and services.
With AWS Control Tower Landing Zone 4.0, the enablement on an existing AWS Organization in two paths. When you select Enable AWS Control Tower, AWS currently gives you two approaches:
- Option 1 – Set up a full environment. This deploys the traditional AWS Control Tower Landing Zone, including the foundational OU structure, centralized AWS Config integration, centralized logging, shared/security accounts, baselines, and Account Factory capabilities.
- Option 2 – “I have an existing environment and want to enable AWS-managed controls” This is the newer Controls Dedicated Environment. It was introduced for organisations that already have an established multi-account environment and primarily want access to the AWS Control Tower Control Catalog without adopting the entire traditional landing-zone architecture.
Option 1 – Set up a Full AWS Control Tower Environment
- Select Full Environment.
- Choose the Home Region.
- Cannot be changed after Control Tower is enabled.
- Choose the Governed Regions.
- Optionally enable Region Deny.
- Restricts use of non-approved/non-governed AWS Regions.
- Configure the Foundational / Security OU.
- Configure Audit / Security account.
- Configure AWS Config integration.
- Required for Control Tower detective controls.
- Select the AWS Config Aggregator / delegated administrator account.
- Configure KMS encryption for centralized AWS Config data.
- Configure AWS Config S3 retention.
- Choose an existing or create a new Log Archive account.
- Configure AWS Control Tower managed Organization CloudTrail.
- Configure CloudTrail S3 retention and encryption.
- Review the configuration and enable AWS Control Tower.
Option 2 – Existing Environment + Enable AWS-Managed Controls
- Select Existing Environment / AWS-managed controls.
- Choose the Home Region.
- Choose the Allow Regions where Control Tower controls will be managed & Deny Regions.
- Configure AWS Config integration if you want to use detective controls.
- Select/configure the AWS Config aggregation account where required.
- Use the AWS Control Tower Control Catalog to apply AWS-managed controls to existing OUs/accounts.
Option 2 allows customers to use existing AWS Organization, OU structure, Logging architecture, Account provisioning process and best suited when the organisation wants:
- AWS-managed governance controls.
- Minimal disruption to the existing landing zone.
- No major redesign of the existing multi-account environment.
- Gradual adoption of Control Tower capabilities.
After Control Tower enablement, customer can register existing OUs / create New OU’s, enrol existing accounts / create new Accounts, apply Control Tower baselines.
Control Tower Mandatory Controls
Enabling AWS Control Tower on an existing AWS Organization does not automatically register existing workload OUs or accounts. Customers can choose which OUs to bring under Control Tower governance and migrate them in phases, helping reduce risk for environments running critical workloads.
AWS Control Tower automatically applies mandatory controls on all registered OUs to protect resources it deploys and manages. These controls are primarily preventive SCP-based controls. Starting with Landing Zone 4.0, mandatory controls are no longer applied universally by default; they are enforced based on the Control Tower integrations and capabilities enabled in the environment. Mandatory SCP that protects CT resources including:
- Protect AWS Control Tower IAM roles
- Protect AWS Config configuration and Config rules
- Protect CloudWatch Logs created by Control Tower
- Protect SNS topics and subscriptions created by Control Tower
- Protect Log Archive S3 buckets
- Protect Control Tower-managed CloudTrail/logging resources when centralized logging is enabled.
Note: SCPs do not apply to users or roles in the AWS Organizations management account. Access to the management account should therefore be tightly restricted, and wherever possible, operational and administrative responsibilities should be delegated to dedicated delegated administrator accounts.
Accounts Enrolment Pre-Checks
Customers should carefully assess existing OUs and accounts with workloads before bringing them under AWS Control Tower governance. Consider an environment with a top-level OU, a child OU, and two workload accounts under the child OU.
- Registering the Top-Level OU: Control Tower registers the top-level OU and applies its mandatory preventive controls & region deny SCP. These SCP-based controls are inherited by child OUs and accounts beneath it, even if the child OUs are not yet registered. Nested OUs must still be registered separately.
- Registering the Child OU: When the child OU is registered, Control Tower enrols the accounts directly within that OU. Control Tower also deploys the required AWSControlTowerExecution role and applies the configured baselines and controls.
- Pre-Checks: Before registration, Control Tower performs pre-checks to identify conditions that could prevent successful enrolment. Common conflicts include:
a. Existing or conflicting SCPs / SCP quota
b. Existing AWS Config recorder or delivery channel
c. Conflicting CloudWatch, Event Bridge rule, SNS topic names
d. Conflicting IAM roles or permissions
If a pre-check fails, Control Tower identifies the affected account and the issue that must be remediated before registration can continue.
Important: Registering a parent OU does not automatically register its nested child OUs. They must be registered individually, typically from the top of the hierarchy downward.
Customer Journey : The brownfield customer chose Option 2 to enable AWS Managed Controls on Existing Organisation. All Workload OU’s are enrolled in phased manner. A separate pre-check automation script has been built to identify conflicting resource even before proceeding with Account enrolment process.
Note : The existing AWS Config Recorder and Delivery Channel are deleted before enrolling each account into Control Tower for Control Tower to create its own Config Recorder and Delivery Channel.
Controls Management in AWS Control Tower
Once OUs and accounts are enrolled into AWS Control Tower, customers need a mechanism to apply additional governance controls to the required OUs. This is handled through Control Management in AWS Control Tower.
Control Management can be understood through the following subtopics, which explain what controls are available, how they are categorized, how individual or groups of controls are applied to target OUs, and what customization options are available.
- Control Catalog
- Control Categories
- Control Identifier
- Control Management Framework
- Parameterized Controls
Control Catalog
As of August 2026, AWS Control Tower provides approximately 69 preventive, 1,315 detective, and 235 proactive controls. The catalog continues to grow as AWS adds support for new services and governance requirements.
Control Grouping
AWS Control Catalog provides several ways to group, classify, and discover controls. Individual control implementations can then be enabled or disabled across Organizational Units (OUs).
- Common Controls: A common control expresses a single security or governance objective that one or more controls can help achieve. Example: Encrypt data at rest. A common control itself cannot be enabled; its individual implementations are enabled.
- Services: Groups controls based on the AWS service they govern. Example: controls related to Amazon API Gateway.
- Frameworks: Groups controls mapped to industry-specific compliance frameworks. Example: PCI-DSS v4.0.
- Groups: Organises controls into logical collections based on their purpose. Example: Digital Sovereignty.
Control Identifier
Each Control Tower control has a globally unique API identifier (global ARN) in the AWS Control Catalog. These identifiers are Region-independent and can be used with the Control Tower console or APIs to enable a specific control against a target OU.
Control Management Framework
To manage these controls at scale, we built a Control Tower Control Management (CTCM) Framework using Terraform. The framework takes the Control API identifier and target OU(s) as inputs and invokes the Control Tower APIs to enable the required controls. The same approach can also be implemented using other Infrastructure-as-Code tools.
Parameterised Controls
RCP-based and certain SCP-based controls support parameters such as ExemptedPrincipalArns. So, CTCM framework therefore accepts an excluded_roles list, allowing approved roles such as a BreakGlassRole to be exempted from specific controls where administrative access is required.
Customer Journey: A separate Control Tower Control Management (CTCM) framework was created for the customer to manage and apply controls to top-level and child OUs through a GitOps-based workflow.
For maintainability and readability, the framework groups controls by control behaviour and AWS service. Separate folders are maintained for control types such as preventive, RCP, declarative, proactive, and detective controls. Within each folder, service-specific YAML files such as EC2.yaml, S3.yaml, or IAM.yaml contain the controls related to that AWS service. This structure makes it easier to review, maintain, and scale control configurations as new AWS services and Control Tower controls are introduced.
Account Vending
As the organisation and its requirements grow, new AWS accounts will be required to host new workloads. Account vending is the process of provisioning new AWS accounts into the multi-account environment while ensuring that they conform to the organisation’s agreed security and governance baseline.
AWS Control Tower provides several options:
- Account Factory / Service Catalog ProvisionProduct API
- Invoke the ProvisionProduct API with account parameters.
- Can be automated using the AWS CLI, SDK, or Service Catalog APIs.
- Suitable for relatively simple programmatic account provisioning.
- Account Factory for Terraform (AFT)
- GitOps-based account vending using Terraform account-request files.
- A git push triggers the account provisioning workflow.
- Deploys a dedicated AFT management account and automation pipelines.
- Supports both account provisioning and post-provisioning customizations.
- Supports Terraform Community Edition, HCP Terraform, and Terraform Enterprise.
- Best suited where customers needing to use Terraform
- Customizations for AWS Control Tower (CfCT)
- Used alongside Account Factory to apply post-provisioning baselines and customisations.
- Uses CloudFormation templates, SCPs, and RCPs.
- Can target specific accounts or OUs.
- Integrates with Control Tower lifecycle events, so customisations can automatically be applied when new accounts are created.
- Best suited where customers have significant CloudFormation-based landing-zone customisations.
- Account Factory Customization (AFC) with Blueprints
- Uses AWS Service Catalog blueprints based on CloudFormation or Terraform.
- Automatically applies the selected blueprint during account provisioning.
- Requires no custom provisioning pipeline after initial setup.
- Supports one blueprint per account (huge disadvantage).
- Step Functions / Lambda-Based Provisioning — Existing Pattern / Least Change
- Uses custom Lambda/Step Functions automation around Account Factory and AWS Organizations.
- Can provision accounts and execute customer-specific baseline activities.
- Provides maximum flexibility but requires the customer to own and maintain the custom automation.
Important distinction: AFT and Account Factory are account-vending mechanisms, whereas CfCT is primarily a customization framework that complements the account-vending process.
Customer Journey: The customer already had a robust Step Functions + Lambda-based account baselining workflow, triggered by account creation events. The workflow invoked 20+ Lambda functions, each performing a specific baseline activity. While functional, maintaining, updating, and enhancing this custom solution created significant operational overhead and slowed the rollout of new capabilities.
Another challenge was baseline inconsistency. As the workflow evolved, newer accounts received additional controls and configurations, while older accounts created with earlier versions of the pipeline did not automatically inherit those improvements. This resulted in an uneven security and governance baseline across the environment.
The custom account creation and baselining pipeline was therefore replaced with Account Factory for Terraform (AFT). The customer was already a mature Terraform user and wanted account provisioning and customization to be managed through Terraform and GitOps. AFT also removed the need to maintain bespoke provisioning pipelines, making it the natural fit for their operating model.
Conclusion & Key Takeaways
In both the blogs, we explored AWS Organizations, AWS Control Tower, Landing Zone 4.0, greenfield and brownfield deployment options, OU/account enrolment, control management, and account vending.
We also looked at a real-world enterprise migration from a custom AWS Organizations + SCP + Step Functions/Lambda model to AWS Control Tower + AFT, helping standardise governance and account baselines while reducing operational overhead.
We also explored other account vending, the different provisioning options available, and how organisations can choose an approach based on their existing skills, tooling, and operational requirements. Once existing accounts are enrolled and new accounts are provisioned through AFT, customers can centrally apply preventive, detective, and proactive controls across their environment.
For brownfield customers, Control Tower can initially appear complex. But with careful assessment, pre-checks, and phased migration, existing AWS environments can be brought under Control Tower governance with minimal disruption and a more consistent security posture.
Reach out to Cevo if you’d like to learn more about migrating to AWS Control Tower.
Gokul is a passionate technologist with approximately 14 years of IT experience. He has held diverse roles, including DevOps Engineer, Technical Architect, Solution Architect, and Team/Project Manager. With a strong background in both on-premises and cloud environments (Azure/AWS), he has successfully led and delivered robust, cost-effective end-to-end solutions.
