A Landing Zone Is The Governed Starting State
When teams create AWS accounts manually, every account can end up with different identity, logging, Regions, security enrollment, and ownership. Repairing those differences later is slow and an untested organization-wide policy can break production.
A landing zone is the governed multi-account foundation prepared before workloads arrive. It answers who can sign in, which Regions and services are allowed, where audit and configuration evidence goes, which security capabilities are enabled, and who owns the account.
Understand The Hierarchy First
AWS Organizations supplies the hierarchy: organization root → organizational units (OUs) → accounts. An OU groups accounts that share control needs. Workload resources do not live inside an OU, and an OU is not a VPC or network boundary.
AWS Control Tower orchestrates a managed landing-zone baseline using services such as Organizations, IAM Identity Center, CloudTrail, and AWS Config. It does not replace those services; they remain the mechanisms underneath. Account Factory gives teams a repeatable account-vending path, so a request for an owner, purpose, and OU produces an account with the expected baseline instead of another snowflake.
IAM Identity Center centrally assigns workforce permission sets that become roles in target accounts and favor short-lived sessions. Separate log archive and security accounts keep evidence and security operations outside ordinary workload administration. Supported services can use a delegated administrator so daily operations do not require routine use of the highly privileged management account.
Read deeper into the Control Tower baseline and account vendingGuardrails Act At Different Times
- A preventive control blocks a prohibited action.
- A detective control, commonly backed by AWS Config, reports a violation that already exists.
- A proactive control checks supported CloudFormation resources before provisioning.
These are not interchangeable. Detection does not undo a resource, and prevention does not explain every existing configuration.
The most important permission distinction is:
SCP: sets the maximum permissions available to affected member accounts. IAM: grants permissions inside that allowed boundary.
An SCP never grants access. An IAM allow cannot exceed an applicable SCP, and SCPs do not restrict the management account. Because inherited controls can affect many accounts at once, stage and test restrictive policies in a small OU before wider attachment.
Read deeper into preventive, detective, and proactive controlsFrom Account Request To Governed Workload
- A team requests an account with a named owner, purpose, environment, and target OU.
- Account Factory creates or enrolls the account against the landing-zone baseline.
- The OU position determines inherited organization policy, while Identity Center grants the workforce roles needed inside that boundary.
- Central CloudTrail and Config evidence, security-service enrollment, and ownership metadata become part of the account's expected state.
- Preventive and proactive controls stop selected unsafe changes; detective controls report drift that still occurs.
- Exceptions receive an owner and expiry. Drift is repaired, and suspended or closed accounts move through a controlled lifecycle.
This lifecycle matters because a landing zone is not a one-time template. New accounts, changed controls, exceptions, and drift must remain governable after initial setup.
SAA Recognition And Traps
- “Governed multi-account foundation” points to a landing zone, commonly orchestrated with AWS Control Tower.
- “Group accounts that need the same inherited policies” points to an OU in Organizations.
- “Provision standardized governed accounts repeatedly” points to Account Factory.
- “Central workforce access across accounts” points to IAM Identity Center and permission sets.
- “Block an action across affected member accounts” points to a preventive control or SCP; “report an existing noncompliant resource” points to a detective control.
- Do not say Control Tower replaces Organizations, Identity Center, CloudTrail, or Config.
- Do not treat an OU as a resource or network container.
- Do not attach a broad, untested SCP at the root, and never say an SCP grants permission.
- Do not assume account creation alone proves security enrollment, evidence delivery, ownership, or drift repair.
One-Minute Review
Organizations hierarchy and OUs
-> Control Tower orchestrates the baseline
-> Account Factory vends standardized accounts
-> Identity Center grants workforce roles
-> SCPs cap permissions; IAM grants within the cap
-> preventive / proactive controls block; detective controls report
-> central evidence, exceptions, drift, and lifecycle stay governed
If you remember only one thing: a landing zone turns account creation into a governed product whose hierarchy, identity, evidence, controls, and lifecycle are known before workloads arrive.