Control Tower is not a single service running your account — it is a composition layer that provisions and wires together several existing AWS services into a governed structure called a Landing Zone.

The Landing Zone as a composed artifact

When you set up Control Tower, it does not invent new infrastructure primitives. It provisions an AWS Organization (if one doesn’t exist), creates two mandatory member accounts — a Log Archive account and an Audit account — enables AWS Config and CloudTrail organization-wide, deploys a set of CloudFormation StackSets across every account in scope, and wires IAM Identity Center (formerly AWS SSO) for centralized human access. The “Landing Zone” is the name for this entire composed structure, not a single resource you can point to. This matters architecturally because troubleshooting Control Tower issues almost always means troubleshooting one of its underlying services — a StackSet drift, an SCP conflict, a Config recorder that stopped — rather than a Control Tower-specific failure mode.

flowchart TD
    CT[Control Tower Orchestration Layer] --> ORG[AWS Organizations]
    CT --> LOG[Log Archive Account]
    CT --> AUD[Audit Account]
    CT --> CFG[AWS Config - Org Aggregator]
    CT --> SS[CloudFormation StackSets]
    CT --> IDC[IAM Identity Center]
    ORG --> OU1[Sandbox OU]
    ORG --> OU2[Workloads OU]
    ORG --> OU3[Suspended OU]
    SS --> NEW[New Member Account]
    CFG --> DRIFT[Drift Detection Engine]
        

Every new account entering the Landing Zone — whether through Account Factory, Account Factory for Terraform, or enrollment of a pre-existing account — moves through the same underlying lifecycle.

Why this lifecycle matters for automation design

Because provisioning is a multi-step StackSet deployment rather than a single atomic API call, account creation can partially succeed — the Organizations account might exist while a baseline StackSet is still mid-rollout or has failed on a specific target. Automation that treats “account created” and “account fully baselined” as the same event will race ahead and attempt operations against an account that isn’t yet guardrail-compliant.

Guardrails are Control Tower’s core governance primitive, and they are implemented through three architecturally distinct enforcement mechanisms, not one.

Mandatory, strongly recommended, and elective

Guardrails also carry a governance tier. Mandatory guardrails — such as disallowing changes to the CloudTrail configuration Control Tower itself deployed — cannot be disabled and are enforced across every Landing Zone by design. Strongly recommended guardrails encode AWS’s best-practice guidance (e.g., disallowing public read access to S3 buckets) but can be turned off if a workload has a legitimate exception. Elective guardrails are optional, narrower controls — such as region restriction — that teams enable based on their own compliance requirements.

flowchart LR
    A[Developer submits IaC change] --> B{Proactive Guardrail Check}
    B -- Fails --> C[Deployment blocked pre-provision]
    B -- Passes --> D[Resource provisioned]
    D --> E{Preventive Guardrail - SCP}
    E -- Denied --> F[API call rejected]
    E -- Allowed --> G[Resource created]
    G --> H{Detective Guardrail - Config Rule}
    H -- Non-compliant --> I[Flagged as drift / NON_COMPLIANT]
    H -- Compliant --> J[Resource marked compliant]
        

Account Factory is the provisioning front-end; Account Factory for Terraform (AFT) is an architecturally different automation path built for teams who manage infrastructure as code rather than console clicks.

Native Account Factory publishes account creation as an AWS Service Catalog product, letting authorized users self-service a new, pre-baselined account through a console form or the Service Catalog API. This is well suited to organizations comfortable with a semi-manual, console-or-API-driven workflow and moderate account creation velocity.

AFT instead wraps account provisioning in a Terraform-native pipeline: account requests are defined as Terraform configuration, processed through a CodePipeline-based orchestration in a dedicated AFT management account, and every new account can have custom, team-specific Terraform baselines layered on top of the standard Control Tower baseline — a “global customizations” and “account customizations” pattern that native Account Factory does not offer out of the box.

Control Tower doesn’t dictate your OU structure — but its guardrail-at-OU-level model strongly shapes what a well-designed structure looks like.

Because SCP-based preventive guardrails apply at the OU level, OU design becomes a governance design exercise, not just an organizational chart. A common pattern separates a Security OU (holding Log Archive and Audit), a Sandbox OU (for experimentation, often with tighter spend and networking restrictions), and one or more Workloads OUs segmented by environment (Production, Non-Production) or by business unit — each carrying a different guardrail profile matched to its risk tolerance.

graph TD
    ROOT[Organization Root] --> SEC[Security OU]
    ROOT --> SAND[Sandbox OU]
    ROOT --> WL[Workloads OU]
    SEC --> LOG[Log Archive Account]
    SEC --> AUDIT[Audit Account]
    WL --> PROD[Production OU]
    WL --> NONPROD[Non-Production OU]
    PROD --> APP1[App Team A - Prod]
    PROD --> APP2[App Team B - Prod]
    NONPROD --> DEV1[App Team A - Dev]
    NONPROD --> DEV2[App Team B - Dev]
        

Control Tower’s architecture holds up well into the hundreds of accounts, but specific mechanisms deserve attention as an organization’s account count grows.

Because Landing Zone updates and guardrail changes propagate through StackSet re-deployment across every enrolled account, a large fleet (hundreds of accounts) makes a Landing Zone version upgrade a meaningfully longer-running operation than in a small Organization — StackSet operations are inherently sequential-with-concurrency-limits per target, not instantaneous fan-out. Planning maintenance windows around Landing Zone upgrades, rather than assuming they complete immediately, is a scale-driven operational practice.

Reliability-wise, Control Tower’s own control plane operates independently of the guardrails it has already deployed — if the Control Tower service itself experiences an issue, previously deployed SCPs and Config rules continue enforcing governance in already-baselined accounts, because those are ordinary AWS Organizations and Config resources that don’t depend on Control Tower’s control plane staying available to keep functioning.

The Log Archive and Audit accounts are not arbitrary naming conventions — they encode a specific security separation-of-duties model.

The Log Archive account holds a copy of every enrolled account’s CloudTrail and Config logs, and is deliberately kept separate from the accounts generating those logs so that an actor who compromises a workload account cannot also delete the audit trail of their own actions — the logs live somewhere they don’t have write access to. The Audit account, by contrast, holds read-only cross-account roles into every enrolled account, giving a security team centralized investigative access without needing standing credentials in each individual workload account.

Drift is Control Tower’s central operational concept, and understanding how it’s surfaced determines whether your team catches governance decay quickly or discovers it during an audit.

When an enrolled account’s actual configuration deviates from its expected guardrail baseline — a Config rule someone disabled, an SCP manually detached, a CloudTrail trail modified outside Control Tower — the Landing Zone’s dashboard flags that account as drifted, and the specific resource-level compliance data is available through the organizational Config aggregator. For proactive alerting rather than console-checking, drift and compliance-change events can be routed through EventBridge into the same kind of notification pipeline used for other AWS governance signals, letting a security team receive a near-real-time alert rather than discovering drift on the next manual review.

Yes, but the existing structure must be reconciled against Control Tower’s requirements during setup — conflicting SCPs or an incompatible OU layout can block or complicate enrollment, which is why the pre-enrollment audit discussed in Chapter 10 matters.

The underlying SCPs, Config rules, and account structure remain in place as ordinary AWS resources, per Chapter 1 — disabling Control Tower removes its orchestration and drift-detection layer, not the governance artifacts it already deployed.

It’s an alternative provisioning path, not a strict replacement — both ultimately create accounts governed by the same Landing Zone; the choice depends on whether your organization prefers a Terraform-native, pipeline-driven workflow or the built-in Service Catalog-based self-service flow, as covered in Chapter 4.

The end resources are similar, but Control Tower adds continuous drift detection, a managed guardrail catalog with mandatory/recommended/elective tiers, and standardized Account Factory provisioning — the orchestration and ongoing governance layer is the differentiator, not the raw AWS primitives underneath.

Yes — guardrail assignment is per-OU, which is the mechanism behind the Production/Non-Production and Sandbox segmentation pattern described in Chapter 5.

Control Tower’s real value shows up once you stop seeing it as a single service and start seeing it as what it is: an orchestration layer composing AWS Organizations, Config, CloudTrail, StackSets, and IAM Identity Center into a governed, continuously monitored multi-account structure. Its guardrails operate through three distinct enforcement points — proactive, preventive, and detective — each with different trade-offs, and its Log Archive and Audit account separation encodes a deliberate security model, not an arbitrary naming convention. Teams that design their OU structure around guardrail strictness, treat drift notifications as an operational signal rather than an audit-time surprise, and choose between native Account Factory and AFT deliberately get a governance backbone that scales cleanly into hundreds of accounts.