TL;DR:
In this 2-part blog, we’ll explore AWS Control Tower: what it is, its history and evolution, the latest version, what has changed in the most recent release, its key features and capabilities, and what these changes mean for customers operating AWS at scale.
We’ll then look at a real-world migration journey involving an enterprise customer with 200+ AWS accounts and business-critical workloads. The customer already had an established AWS environment with custom-built security, governance, logging, account provisioning, and compliance controls in place.
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
AWS Control Tower is an AWS service that helps customers set up and govern secure, multi-account AWS environments at scale. It provides a centralised way to establish governance using controls (formerly known as guardrails), apply security baselines, and manage accounts consistently.
In this blog, we’ll explore how multi-account governance was managed before AWS Control Tower, how Control Tower has evolved since its introduction, the major releases and capabilities, what has changed in the latest version, and what these improvements mean for customers and their businesses.
Table of Contents
What is Multi Account Strategy & Why?
Customers often use multiple AWS accounts to separate workloads based on application, environment, business unit, security boundary, or access requirements. A multi-account strategy provides several key benefits:
Image: Example multi account view
- Improved Security – Allows security policies to be applied based on the purpose and risk profile of each account.
- Environment Isolation – Separates production, non-production, development, and testing workloads to avoid unintended impact across environments.
- Simplified Access Control – Makes it easier to define and manage permissions based on teams, applications, and environments.
- Reduced Blast Radius – Limits the impact of a security incident, configuration error, or compromised workload to an individual account rather than the entire AWS environment.
However, while the benefits of a multi-account strategy are significant, managing multiple AWS accounts without centralised capabilities for identity, billing, logging, and governance can quickly become complex. In 2026, multi-account architectures are common across organisations of all sizes, but the operational model behind them is just as important as the account structure itself.
Without centralised management, responsibilities can fall to individual application or platform teams. Each new account may require identity integration, access configuration, billing setup, logging, security controls, and compliance configuration before any application workload can even be deployed. Repeating these activities for every account creates significant operational overhead, increases the risk of inconsistent security baselines, and introduces friction for organisations that want to scale and move quickly. AWS Organisation was introduced to simplify multi account management.
What is AWS Organization & Why?
AWS introduced AWS Organizations in 2017 to simplify the management and governance of multiple AWS accounts. AWS Organizations follows a hierarchical organisational model like concepts used in the X.500 directory standard. Accounts can be grouped into Organizational Units (OUs) within a tree-like hierarchy, allowing governance policies to be applied at different levels of the organization. It provides a central structure to group, manage, and apply governance across accounts, helping bridge the gap between adopting a multi-account strategy and operating it at scale.
Image: x.500 Standard
Key capabilities include:
- Management Account: Centrally manage the AWS Organization, accounts, OUs, and policies.
- Centralised Identity: Integrate with IAM Identity Centre and enterprise identity providers such as Entra ID/Active Directory for access across accounts.
- Account Management: Create new AWS accounts or invite existing accounts into the organization.
- Organizational Units (OUs): Group accounts into logical hierarchies such as Production, Non-Production, Sandbox, and Security.
- Service Control Policies (SCPs): Apply preventive / declarative guardrails across accounts or OUs to restrict or permit specific AWS service actions and enforce compliance
- Consolidated Billing: Combine usage and billing across member accounts into one invoice, qualifying total usage for volume pricing discounts.
- Centralised Logging and Security: Integrate services such as CloudTrail, Config, Guard Duty, and Security Hub across the organization.
- Resource Sharing: Share resources such as subnets and Transit Gateways using AWS RAM.
- Delegated Administration: Allow dedicated security or platform accounts to manage supported AWS services across the organization.
AWS Organizations provided the foundation for multi-account governance, but customers still had to build and maintain their own account provisioning, security baselines, logging, and compliance automation. AWS Control Tower was introduced to simplify and standardise these capabilities further.
What is AWS Control Tower & Why?
AWS introduced AWS Control Tower in June 2019, around two years after AWS Organizations became generally available. Built on top of AWS Organizations, Control Tower provides an opinionated and automated way to establish and govern a multi-account AWS environment. Existing AWS accounts and Organizational Units (OUs) can be brought under Control Tower governance, allowing customers to apply centrally managed security and governance controls.
Earlier approaches such as the AWS Landing Zone solution helped customers build similar multi-account environments, but AWS Control Tower turned many of these concepts into an AWS-managed service. Traditionally, an AWS Control Tower landing zone included two dedicated shared accounts:
- Audit Account: A restricted account for security and compliance teams. Control Tower deploys roles that provide programmatic access to member accounts, enabling central security teams and automation such as Lambda functions to perform auditing and security operations across the environment.
- Log Archive Account: Provides a central location for collecting and retaining logs from accounts governed by Control Tower, including AWS CloudTrail and AWS Config data.
Customers can allow Control Tower to create these accounts or nominate suitable existing AWS accounts during initial landing zone setup.
With Landing Zone 4.0, released in November 2025, AWS significantly changed this architecture. Previously, Control Tower imposed more opinionated requirements around the Security OU, shared accounts, AWS Config, security roles, and logging integrations. Version 4.0 removes many of these mandatory organisational requirements and makes integrations such as AWS Config, AWS CloudTrail, Security Roles, and AWS Backup optional.
This means customers can now adopt Control Tower primarily for its governance and controls capabilities, while retaining their existing organisational structure, logging architecture, and security tooling where appropriate. This flexibility is particularly important for established enterprises that already have mature AWS environments and want to adopt Control Tower without redesigning their entire landing zone.
AWS Control Tower Controls
Without AWS Control Tower, customers typically need to design and maintain their own Service Control Policies (SCPs) to restrict what identities and workloads can do across AWS accounts. These policies can be attached at the account, child OU, or parent OU level through AWS Organisation API’s, allowing different governance requirements to be applied across the organisation.
AWS Control Tower simplifies this by providing a catalogue of AWS-managed controls (grouped by AWS Service, Domains, Frameworks or Objectives) or that customers can enable on registered OUs. These controls are then inherited by the accounts within those OUs.
AWS Control Tower provides three control behaviours:
1. Preventive Controls – Prevent non-compliant actions from occurring. These are implemented using mechanisms such as SCPs, RCPs, and declarative policies. AWS Organizations currently supports up to 10 SCPs attached to a root, OU, or account, with a maximum size of 10,240 characters per SCP.
- SCP: Restricts the maximum permissions available to identities in member accounts. Service-linked roles are excluded.
- RCP: Restricts actions on AWS resources regardless of which principal is accessing them. Example: prevent access to an S3 bucket from outside the organisation.
- Declarative Policies: Enforce AWS service-level settings. Example: Block public sharing of AMIs across selected accounts.
2. Detective Controls – Detect resources that are not compliant after deployment, primarily using AWS Config rules & AWS Security Hub CSPM. Control Tower now deploys these directly as service-linked Config rules, replacing the earlier CloudFormation StackSet model and improving deployment speed and consistency.
- AWS Config: Detective controls that identify non-compliant resources. Control Tower deploys these as service-linked Config rules.
- AWS Security Hub CSPM: Provides detective controls and aggregates security findings centrally.
3. Proactive Controls – Check resources before deployment and block non-compliant resources provisioned through CloudFormation. These are implemented using AWS CloudFormation Hooks.
- CloudFormation Hooks: Proactive controls that validate resources before deployment and block non-compliant resources created through CloudFormation, CDK, or SAM.
These AWS managed controls allow customers to adopt a consistent governance baseline across hundreds of AWS accounts without having to build and maintain every control themselves.
Deny Region:
- In addition to just controls, Control Tower also allows customers to define governed Regions and optionally enable Region deny controls to restrict AWS service access to AWS Regions outside the approved set, with specific global-service exceptions.
- The combination of Governed Regions, Region Deny, and Control Tower controls allows customers to apply selective service restrictions in approved regions while providing confidence that access to non-approved regions is broadly restricted once OUs are enrolled and governance is applied.
Important note: At this point, Control Tower only lets customers to enable pre-packaged, AWS-managed controls from the AWS Control Tower Control Catalog at OU level. For custom requirements, customer can create customer managed policies and apply it to OU’s / Account’s directly through AWS Organisation.
Conclusion
In this blog, we cover the fundamentals of AWS Control Tower and AWS Organizations, including the core capabilities of Control Tower and the deployment options available in AWS Control Tower Landing Zone version 4.0.
We also explore the different Control Tower control behaviours, how each control type works, and the key limitations and considerations associated with them.
In the next blog, let’s take a deeper look at a real-world Control Tower migration journey — moving from a custom landing zone built with AWS Organizations, Terraform/CloudFormation, custom account vending, and custom baselining to AWS Control Tower with Account Factory for Terraform (AFT). It covers the migration approach, control management strategy, key challenges, lessons learned, and the resulting improvement in governance, consistency, and operational efficiency.
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.
