AWS Control Tower, end to end: the managed landing zone, its controls, and where it bites

The forty accounts you can't govern by hand

Control Tower does not invent much. It orchestrates services you already have — AWS Organizations, IAM Identity Center, Service Catalog, Config, CloudTrail, CloudFormation StackSets — and configures them into a multi-account environment AWS calls a landing zone: the enterprise-wide container for your OUs, accounts, users, and the rules over them.

The point worth seeing before anything else is that the underlying services are identical with or without Control Tower. The difference is who wires them. Do it by hand and you write your own Organizations structure, your own centralized logging, your own SCP library, your own account-vending pipeline — and then keep all of it consistent as it scales. Control Tower is the conductor that configures the same instruments into a best-practice arrangement, and keeps them in tune.

The landing zone at a glance — every account and OU on one board

Here is the whole structure Control Tower builds. Learn this map and most of the service falls into place; every later section is a zoom into one region of it.

When you set up the landing zone, Control Tower creates the Security and (optional) Sandbox OUs, creates or adopts the Log Archive and Audit accounts inside Security, stands up an IAM Identity Center directory with preconfigured groups, and applies its baseline. It deploys into accounts using CloudFormation StackSets — one stack instance per account per Region. (Seeing some instances marked Outdated after an update is normal, not a fault.)

Who owns each box:

The two shared accounts you did not choose to run. Alongside the management account, Control Tower creates two core accounts in the Security OU. You can custom-name them, or bring existing accounts to fill the roles — but only once, at initial setup. There is no do-over later.

• Log Archive is your write-once evidence locker: a central S3 bucket holding a copy of every account's CloudTrail and Config logs, immutable by design. From landing zone v3.3 on, the bucket policy enforces an aws:SourceOrgID condition so only accounts inside your organization can write to it. (Version-sensitive: pre-3.3 landing zones lack that guard.)
• Audit is your security team's cockpit: it carries an auditor (read-only) and an administrator (full-access) role into every account, and is the fan-in for notifications via three SNS topics — all configuration events, aggregate security notifications (Config-rule compliance, GuardDuty findings), and drift notifications.

How it enforces the rules — the three kinds of control

A control (formerly "guardrail" — AWS still uses both words) is a high-level rule in plain language. The single most important fact about controls: a control applies to an entire OU, and every account in that OU inherits it. You govern by moving accounts into the right OU, not by configuring accounts one at a time.

The behavior axis — how a control enforces:

Proactive controls are the newest of the three — AWS launched them (as CloudFormation hooks) in preview in November 2022 with 130+ controls, and has expanded them since. (Version-sensitive: availability and Region coverage keep growing; check the current catalog.)

The guidance axis — how strongly AWS recommends a control, independent of its behavior:

• Mandatory — protect Control Tower's own deployed resources. Version-sensitive surprise: starting with landing zone version 4.0, mandatory controls are no longer applied by default. Older landing zones had them on automatically.
• Strongly recommended — common best practices for a well-architected estate; you opt in at the OU level.
• Elective — lock down actions many enterprises restrict; opt in per OU.

A concrete preventive control is just an SCP fragment. The landing-zone Region-deny control (AWS-GR_REGION_DENY) is a single deny shaped like this:

{
  "Effect": "Deny",
  "NotAction": [ "iam:*", "organizations:*", "sts:*", "cloudfront:*" ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "eu-west-1"] },
    "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTower*" }
  }
}

Paraphrased from the control reference — the live template is longer. Note the NotAction carve-out for global services and the principal exception for Control Tower's own roles.

How a new account is born — Account Factory and its two paths

Account Factory is a vending machine built on AWS Service Catalog. It is a configurable account template; provisioning an account is really provisioning a Service Catalog product, which Control Tower then baselines with the standard stack sets and drops into an OU, under that OU's controls.

The vend hops, in order:

New accounts get the full treatment above. You can turn the VPC off in Account Factory's network settings if the workload does not need one. Enrolling an existing account is the harder path, and where teams get stuck. Two customization routes sit on top of the basic factory:

• Account Factory Customization (AFC) — console-driven. You register a blueprint (itself a Service Catalog product) so vended accounts come pre-baked with your resources. Blueprints can be CloudFormation (deploys to multiple Regions) or Terraform (single Region only). Partner-built blueprints exist too.
• Account Factory for Terraform (AFT) — a GitOps pipeline for Terraform shops. You write an account-request Terraform file, git push, and AFT provisions and customizes the account through a Step Functions pipeline. AFT runs from its own dedicated AFT management account (not the Control Tower management account), needs an existing landing zone, and is explicitly not for deploying workload resources — only for making and customizing accounts.

How it stays honest — drift, updates, and the reset button

Drift is divergence from the state Control Tower expects, and managing it is a routine operations task — not an exception. Detection is automatic: Control Tower makes read-only Organizations calls via the AWSControlTowerAdmin role and runs a daily scan of its managed SCPs, RCPs, and declarative policies (their identifiers start with aws-guardrails), checking each OU's policies still match the controls that should be there. Drift surfaces on the dashboard and through the Audit account's Drift Notifications topic (de-duplicated, so you get one alert per issue).

The remediation ladder, mild to severe:

The operational sting, echoed by practitioners: while your landing zone is drifted, "Enroll account" stops working — you fall back to provisioning through Service Catalog directly. The Scale Factory team's field advice is blunt and worth adopting: treat drift as an incident and minimize the time you spend in it.

Where it runs — home Region, governed Regions, and Region deny

When you create the landing zone, the Region you are signed into becomes your home Region — and you can never change it. Control Tower supports roughly 33 Regions today; you choose which additional ones to govern. (Version-sensitive: the supported-Region count grows over time.)

Region deny comes in two forms. AWS-GR_REGION_DENY is an elective, preventive SCP that applies to the whole landing zone; CT.MULTISERVICE.PV.1 applies per OU. You can't deny your home Region, and global services (IAM, Organizations, and friends) are exempt. Enable it only when you are sure you have no resources you still need in the target Regions, because it locks you out of them immediately.

A quieter gotcha: adding a governed Region updates the landing zone but does not update your existing accounts. Detective controls will not extend into the new Region until you re-register each OU to re-baseline its accounts. Miss that step and you have governed Regions on paper with ungoverned accounts underneath.

What you actually pay for, and the ceilings

Control Tower itself is free. There is no per-account or per-landing-zone charge. What you pay for is everything it switches on: Service Catalog, CloudTrail, AWS Config, CloudWatch, SNS, S3, and VPC.

The limits worth committing to memory:

Also check Region availability before you plan: several newer Regions don't yet support Service Catalog, AFC, AFT, or Customizations for Control Tower (CfCT), which quietly rules out those features there.

Where it bites, and when to reach past it

Collected in one place so they don't interrupt the map. Most of these are the abstraction leaking, or someone fighting the fixed model.

• Workloads in the management account. It is exempt from controls by design — anything there runs ungoverned at organization scope. Keep it empty; run workloads in member accounts.
• The management account is the drift super-spreader. Almost every drift path runs through it, because it hosts both Control Tower and Organizations. Lock it down with least-privilege IAM and keep humans out of it.
• Enrolling an account that already has Config. Enrollment fails if the account has a Config recorder/delivery channel. Delete them first.
• Assuming an un-governed Region is a blocked Region. It is not. Use the Region-deny control if you actually mean to block.
• Forgetting to re-register OUs after adding a Region. Existing accounts don't get the new Region's detective controls until you re-register their OU.
• Editing Control Tower's managed resources by hand. Modifying its VPC, roles, SCPs, or stack sets outside the supported paths creates drift and can push controls into an "unknown state."
• One-time choices you can't undo. The home Region, and using existing accounts for Log Archive/Audit, are locked at setup. Some account attributes can't change after provisioning either. Decide deliberately.
• Config cost creep. The default records everything, everywhere governed. Review what Config records before your estate is large, not after the bill arrives.

Three ways to build a governed multi-account estate — and they are layers more than rivals:

AWS's own guidance matches what the tooling implies: deploy Control Tower as your foundational landing zone, then add LZA as needed. They are not an either/or. Start with Control Tower; graduate to LZA-on-Control-Tower when the requirements demand it, not before — LZA is a heavier operational commitment. And if you already built your own account structure, the newer controls-only experience lets you adopt Control Tower's managed control library without deploying a full landing zone.

References

1. AWS — What Is AWS Control Tower? (User Guide). https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
2. AWS — How AWS Control Tower works (landing-zone structure, StackSets). https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html
3. AWS — About the shared accounts (management, Log Archive, Audit). https://docs.aws.amazon.com/controltower/latest/userguide/special-accounts.html
4. AWS — About controls in AWS Control Tower (Controls Reference). https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html
5. AWS — Control behavior and guidance (behaviors × guidance; LZ 4.0 note). https://docs.aws.amazon.com/controltower/latest/controlreference/control-behavior.html
6. AWS — Provision and manage accounts with Account Factory. https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html
7. AWS — Account Factory Customization (AFC) and Partner blueprints. https://docs.aws.amazon.com/controltower/latest/userguide/af-customization-page.html
8. AWS — Overview of Account Factory for Terraform (AFT). https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html
9. AWS — About enrolling existing accounts (baseline stack sets, Config prerequisite). https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html
10. AWS — Configure AWS Control Tower without a VPC. https://docs.aws.amazon.com/controltower/latest/userguide/configure-without-vpc.html
11. AWS — Working with IAM Identity Center and AWS Control Tower. https://docs.aws.amazon.com/controltower/latest/userguide/sso.html
12. AWS — How AWS Regions work with AWS Control Tower. https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html
13. AWS — Configure the Region deny control. https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html
14. AWS — Detect and resolve drift in AWS Control Tower. https://docs.aws.amazon.com/controltower/latest/userguide/drift.html
15. AWS — Manage AWS Config costs in AWS Control Tower. https://docs.aws.amazon.com/controltower/latest/userguide/config-costs.html
16. AWS — AWS Control Tower Pricing. https://aws.amazon.com/controltower/pricing/
17. AWS — Limitations and quotas in AWS Control Tower. https://docs.aws.amazon.com/controltower/latest/userguide/limits.html
18. AWS — AWS Control Tower and Landing Zone Accelerator. https://docs.aws.amazon.com/controltower/latest/userguide/about-lza.html
19. AWS — Comprehensive controls management (proactive controls preview, Nov 2022). https://aws.amazon.com/about-aws/whats-new/2022/11/aws-control-tower-preview-comprehensive-controls-management/
20. AWS — Control Tower introduces a Controls-dedicated experience. https://aws.amazon.com/blogs/aws/aws-control-tower-introduces-a-controls-dedicated-experience/
21. Scale Factory (Rob), Apr 2025 — When Control Tower Drifts (practitioner reality-check). https://scalefactory.com/blog/2025/04/30/when-control-tower-drifts/