Enterprise Landing Zone

TL;DR

• A landing zone is the multi-account governance pattern that lets many teams operate independently without collapsing blast radius, billing, and IAM boundaries into a single shared account.
• Core building blocks: AWS Organizations (grouping/billing) → Organizational Units (blast-radius grouping) → Service Control Policies (permission ceilings) → Control Tower or Landing Zone Accelerator (managed baseline) → IAM Identity Center + Account Factory (federated identity and automated account provisioning).
• SCPs never grant permissions — they only restrict the maximum permission ceiling for every principal in scope, including full-admin IAM roles.
• Control Tower is AWS’s managed, opinionated landing zone; Landing Zone Accelerator (LZA) is the open-source, deeper-customization option layered on top of or standalone from Control Tower.
• Manual account creation guarantees configuration drift; automated account vending (Account Factory or equivalent) is what keeps every account on a consistent governed baseline.
• The single biggest gotcha: SCPs attached at a parent OU cascade to every account beneath it — a policy scoped one level too high can silently break production.

Core Concepts

Why multi-account, not single-account

A single shared AWS account collapses blast radius, billing attribution, and IAM boundaries into one unit. A misconfigured resource, a runaway cost, or an over-permissioned role affects every team simultaneously, and there is no account-level boundary to contain the impact. Untangling a shared account after the fact — splitting workloads, re-attributing cost, re-scoping IAM — is substantially more expensive than provisioning separate, governed accounts from the start. A landing zone is the standard answer to letting multiple teams move independently without stepping on each other or on the security team’s guardrails.

AWS Organizations, Control Tower, and Landing Zone Accelerator

AWS Organizations is the account-grouping and consolidated-billing foundation everything else in a landing zone sits on top of.

Control Tower is AWS’s managed, opinionated landing zone built on Organizations. It provisions a Log Archive account and an Audit account, attaches baseline SCPs and Config rules, and provides a dashboard for drift detection.

Landing Zone Accelerator (LZA) is an open-source accelerator, deployed either layered on Control Tower or standalone, intended for organizations whose compliance requirements (banking, healthcare, government) exceed what Control Tower’s opinionated baseline covers out of the box. LZA and Control Tower are distinct products with different deployment and maintenance models — LZA did not replace Control Tower, and Control Tower is not deprecated.

Organizational Units (OUs)

OUs group accounts so guardrails apply at the correct blast radius: a Security OU, a Workloads OU split into Prod/Non-Prod, a Sandbox OU with looser controls for experimentation. Re-parenting accounts between OUs after the structure is established is a real, sometimes disruptive operation — getting the initial OU boundaries wrong is costly to correct later.

Service Control Policies (SCPs)

SCPs set the maximum permission ceiling for every principal within an account or OU. They never grant permissions — they only restrict. An IAM role with full administrator access still cannot exceed what the SCP attached to its OU allows. This is what makes an SCP a true preventive guardrail: a written policy telling people not to perform an action is advisory, while an SCP denying the underlying API call is enforced regardless of the calling principal’s IAM permissions.

IAM Identity Center and Account Factory

IAM Identity Center (formerly AWS SSO) federates workforce identity into the landing zone: a single login, permission sets mapped to roles, and no per-account IAM users for humans.

Account Factory (Control Tower’s account-vending mechanism) provisions every new account with the same governed baseline automatically — logging enabled, SCPs attached, IAM Identity Center wired in. This replaces a manual process that introduces incremental configuration drift with each hand-created account.

Designing the OU structure

1. Start from compliance and blast-radius boundaries, not the org chart. Security, Log Archive, and Audit accounts are non-negotiable and should never host application workloads.
2. Split Workloads into, at minimum, Prod and Non-Prod OUs with distinct SCPs — the guardrails appropriate to a sandbox account are meaningfully looser than what production requires.
3. Choose an SCP strategy explicitly: deny-list (block specific dangerous actions, permissive by default) or allow-list (only permitted services, everything else denied). Allow-list is more secure but breaks more workflows unexpectedly; most enterprises start deny-list and tighten over time.
4. Automate account vending from the outset, even with only a handful of accounts — retrofitting automation onto a set of already-drifted, manually created accounts is substantially more expensive than establishing it early.
5. Treat the landing zone configuration itself as a versioned, reviewed artifact (LZA’s config repository, or Control Tower’s baseline) rather than undocumented console changes.

Control Tower vs. Landing Zone Accelerator

Command / Configuration Reference

aws organizations create-organizational-unit --parent-id <root-or-ou-id> --name Workloads-Prod
# creates a new OU under a parent (root or another OU)

aws organizations create-policy \
  --content file://scp-deny-iam-login-profile.json \
  --name deny-console-users --type SERVICE_CONTROL_POLICY
# creates an SCP from a JSON policy document

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMLoginProfileCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateLoginProfile",
        "iam:UpdateLoginProfile"
      ],
      "Resource": "*"
    }
  ]
}

SCP denying console-password creation for IAM users — enforces SSO-only access at the OU level, regardless of any IAM role’s permissions.

aws organizations attach-policy --policy-id <scp-id> --target-id <ou-id>
# attaches an SCP to an OU (or account), cascading to every account beneath it

Common Pitfalls

• Pitfall: Starting with a flat, single-OU structure “to keep it simple.” Why: Prod and Non-Prod inevitably need different guardrails once real workloads land. Fix: Establish separate Prod/Non-Prod OUs (at minimum) from the start.
• Pitfall: An overly aggressive SCP breaks a legitimate workflow, and the fix is to loosen it broadly. Why: Broad loosening is faster than scoping a narrow exception, but it accumulates as slow security regression. Fix: Scope exceptions narrowly to the specific action and principal that needs it.
• Pitfall: Manually creating accounts under time pressure “just this once.” Why: The exception becomes the pattern, and accounts drift from the governed baseline over time. Fix: Use Account Factory or equivalent automation for every account, with no manual exception path.
• Pitfall: Forgetting that SCPs cascade from parent OU to every account beneath it. Why: A policy intended for Sandbox, attached one level too high, applies to Production as well. Fix: Verify the exact OU scope before attaching any SCP, and test in a non-production OU first.
• Pitfall: Treating a shared AWS account as adequate “for now.” Why: Blast radius, billing, and IAM boundaries collapse into one unit, and untangling this later costs far more than provisioning separate accounts up front. Fix: Provision per-team or per-environment accounts from the start, governed by a landing zone.

Interview Questions

• Design the OU structure for a company with a regulated production environment, a fast-moving development team, and a data science team needing broad service access for experimentation — tests whether real organizational tension can be mapped onto concrete OU boundaries.
• An engineer with AdministratorAccess still cannot launch a specific GPU instance type — explain why, and how to remediate it if that access is legitimately needed — tests understanding of the SCP-as-ceiling model.
• Walk through what breaks, and what does not, if the management account is compromised — tests whether the blast radius of the management account specifically (versus a member account) is understood.
• Explain what an SCP does that an IAM policy attached to a role cannot — tests whether the grant-vs-restrict distinction between identity policies and SCPs is understood.
• A junior engineer claims Control Tower and Landing Zone Accelerator are the same thing — correct the claim — tests whether the distinct roles and deployment models of each are understood.