AWS Control Tower
A service that automates the setup and governance of multi-account AWS environments, centrally managing security and compliance baselines
Overview
AWS Control Tower is a service for securely and efficiently setting up and managing multi-account AWS environments. It automatically builds a Landing Zone based on best practices for multi-account architecture and enforces organization-wide security policies through guardrails (preventive and detective controls). Account Factory creates new accounts from templates in minutes, with guardrails automatically applied upon creation. It integrates Organizations, IAM Identity Center, CloudTrail, Config, and other AWS services in a unified configuration.
Guardrail Types and Application Strategy
Control Tower guardrails (the AWS documentation now calls them controls) are classified into three types by behavior. Preventive guardrails are implemented via AWS Organizations policies such as SCPs (Service Control Policies), RCPs (Resource Control Policies), and declarative policies, and block prohibited operations - for example, preventing CloudTrail from being disabled or restricting resource creation to specific regions. SCPs apply to all users and roles in member accounts, including the root user, but they do not affect service-linked roles or the management account. Detective guardrails are implemented via Config rules and detect policy violations with notifications, allowing you to identify and remediate non-compliant resources. Proactive guardrails are implemented via CloudFormation hooks and validate templates before deployment to prevent non-compliant resources from being created in the first place. In practice, you apply mandatory guardrails along with strongly recommended guardrails, which are based on best practices for multi-account environments, and elective guardrails chosen for your requirements at the OU (Organizational Unit) level. According to the AWS documentation (as of October 2026), starting with landing zone version 4.0, mandatory controls are no longer applied by default. Start with a conservative set and expand gradually as your organization's cloud maturity grows.
OU Structure and Account Factory Design
OU structure design is an important part of deploying Control Tower. The AWS whitepaper on multi-account strategy recommends separating OUs such as Security OU (log archive and audit accounts), Infrastructure OU (shared networking and DNS), and Workloads OU (production and development environments). Using Account Factory Customization (AFC), you can automatically apply VPC settings, IAM roles, and security tool enablement when creating new accounts, automating account bootstrapping. Accounts created with Account Factory receive the guardrails enabled on the OU they are placed in, which keeps baselines consistent. Azure Landing Zone is an approach in which you deploy and configure Bicep or Terraform templates yourself. Control Tower is a managed service that builds a landing zone from the console.
Introducing Control Tower to Existing Organizations Environments
When introducing Control Tower into an existing AWS Organizations environment, careful planning is required to avoid disruptions. The enrollment process brings existing accounts under Control Tower's governance, but you must verify potential conflicts with existing SCPs and Config rules beforehand. If existing SCPs are more restrictive than Control Tower's guardrails, the more restrictive policy takes effect. If existing workflows depend on actions that Control Tower's guardrails block, enrolling accounts may break those workflows. During enrollment, Control Tower deploys stack sets for baselines such as CloudTrail and Config, so review those templates beforehand to make sure they do not conflict with your existing policies. Before enrollment, audit each account's active Config rules to identify overlaps or conflicts with Control Tower's detective guardrails - duplicate rules waste evaluation costs and can produce confusing compliance reports. Roll out in phases: start by enrolling a non-production account, verify that all existing workloads function correctly under the new guardrails, and then proceed to enroll production accounts. Document any exceptions or customizations needed for specific accounts before beginning the migration.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Organizations official page
- AWS IAM official page
- AWS Config official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.