Landing Zone Guardrails For Multi-Account AWS

1. Situation

A company has five AWS accounts today and expects one hundred. Product teams need production, development, and sandbox environments. Security needs audit evidence. Finance needs ownership. Platform engineering wants every new account to begin with the same baseline.

If every account is assembled manually, growth produces one hundred different answers to basic questions:

• Who can sign in?
• Which Regions and services are allowed?
• Where do CloudTrail and Config records go?
• Which security services are enabled?
• Who owns the account and its cost?

A landing zone is the governed multi-account foundation that answers those questions before workloads arrive.

2. Naive Design

flowchart LR
  TeamA["Team A"] --> A["Hand-built account"]
  TeamB["Team B"] --> B["Different hand-built account"]
  TeamC["Team C"] --> C["No logging baseline"]

Teams create root-email conventions, IAM users, VPCs, logs, and security settings independently. New accounts are fast initially but expensive to audit and repair.

A second mistake is attaching a strict SCP to the organization root as the first experiment. Because child OUs and accounts inherit it, one policy error can affect nearly every workload.

A third mistake is running applications and daily security administration from the Organizations management account. That account has special organization authority and should have a deliberately small operational surface.

3. What Breaks

1. A new sandbox account is created outside the standard process.
2. CloudTrail and GuardDuty are not enrolled.
3. A developer creates resources in an unsupported Region.
4. Security discovers the account only after an incident.
5. An emergency SCP blocks the Region but also blocks a service role needed by production.

The missing system is not another checklist. It is a repeatable account lifecycle with ownership, inherited policy, evidence, and exception handling.

4. AWS Architecture

Step 1: make accounts the boundary

Separate workloads, environments, and security functions where differences in blast radius, ownership, quotas, or policy justify it.

flowchart TD
  Org["AWS Organization"] --> Security["Security OU"]
  Org --> Infra["Infrastructure OU"]
  Org --> Prod["Production OU"]
  Org --> NonProd["Non-production OU"]
  Org --> Suspended["Suspended OU"]

An OU groups accounts for administration and inherited policy. It is not a network boundary, and resources do not live directly inside an OU.

Design OUs by shared control requirements rather than reproducing every line of the company org chart.

Step 2: orchestrate the foundation with Control Tower

AWS Control Tower provides a managed landing-zone experience built with services including Organizations, IAM Identity Center, CloudTrail, and Config.

flowchart LR
  Control["AWS Control Tower"] --> OUs["Governed OUs"]
  Control --> Shared["Log archive and audit accounts"]
  Control --> Factory["Account Factory"]
  Control --> Controls["Control catalog and status"]

Control Tower does not replace those underlying services. It orchestrates a supported baseline and exposes governance state. Existing organizations can require deliberate enrollment and compatibility work; do not assume enabling it silently fixes every existing account.

Step 3: vend accounts through Account Factory

request -> owner and purpose -> correct OU -> standardized account -> workload team

Account Factory provides a repeatable account-provisioning template. The process should capture account email, business owner, technical owner, environment, cost center, intended Regions, and network pattern.

The account owner receives a prepared boundary rather than inventing identity and logging. Moving an account into a governed OU can immediately apply inherited controls, so evaluate existing resources first.

Step 4: centralize workforce access

Use IAM Identity Center groups and permission sets for workforce access across accounts.

flowchart LR
  User["Workforce identity"] --> Center["IAM Identity Center"]
  Center --> Set["Permission set"]
  Set --> Dev["Developer role in dev account"]
  Set --> Read["Read-only role in prod account"]

Permission sets define access that IAM Identity Center provisions into selected accounts. SCPs still cap what those roles can do. Prefer short-lived federated sessions over creating long-lived IAM users separately in every account.

Step 5: layer three control behaviors

Control Tower preventive controls can use Organizations policies such as SCPs and other supported policy mechanisms. Detective controls commonly use AWS Config rules. Proactive controls use CloudFormation hooks for supported resources.

No one behavior replaces the others. Prevention is strongest but can block legitimate operations. Detection supports visibility and remediation. Proactive checks apply to their supported provisioning path and resource types.

Step 6: understand SCPs precisely

effective permission = allowed by IAM/resource policy AND not blocked by organization boundaries

SCPs limit the maximum permissions for affected member accounts. They do not grant an action. They also do not affect users and roles in the management account.

Test a new SCP in a small test OU. Check service-linked roles, deployment automation, incident access, and required Regions before expanding scope. Keep a rollback method outside the policy path being tested.

Step 7: separate evidence and security operations

Use dedicated accounts for central logs and security operations.

flowchart LR
  Workloads["Workload accounts"] --> Logs["Log archive account<br/>protected evidence"]
  Workloads --> Security["Security tooling account<br/>delegated administration"]
  Audit["Audit users"] --> Logs
  Responders["Security responders"] --> Security

Workload administrators should not control the only copy of their audit history. Use delegated administrators for supported services so daily operations do not require the management account.

Completed landing zone

flowchart TD
  Management["Organizations management account<br/>limited use"] --> Control["Control Tower landing zone"]
  Control --> Factory["Account Factory"]
  Control --> OUs["Governed OUs<br/>inherited controls"]
  Identity["IAM Identity Center"] --> OUs
  OUs --> Workloads["Owned workload accounts"]
  Workloads --> Log["Log archive account"]
  Workloads --> Sec["Delegated security account"]

5. Request Or Data Flow

1. A team requests an account with owner, environment, and cost metadata.
2. Platform engineering chooses the OU whose controls match the workload.
3. Account Factory provisions or enrolls the account with the landing-zone baseline.
4. IAM Identity Center assigns approved groups and permission sets.
5. Preventive controls restrict prohibited actions; proactive controls inspect supported templates; detective controls report drift or noncompliance.
6. Logs and security signals flow to central accounts.
7. The product team deploys inside the boundary and requests a documented exception when the boundary does not fit.

6. Security Controls

• protect the management account with minimal access and no ordinary workloads;
• use delegated administrators where supported;
• centralize CloudTrail, Config, and security evidence;
• require short-lived workforce access and MFA through the identity system;
• test SCPs and controls before broad inheritance;
• document exceptions with owner and expiry; and
• maintain audited break-glass access that still works during identity-system failure.

Guardrails reduce possible actions. They do not replace secure workload IAM, networking, encryption, patching, or application design.

7. Resilience Controls

Monitor account enrollment, failed provisioning, control violations, Control Tower drift, disabled security services, missing log delivery, unowned accounts, and exception expiry.

Keep account vending reproducible. Preserve a quarantine or suspended OU for accounts leaving normal operation, with carefully designed access and evidence retention.

Test recovery from a bad policy. A governance platform that can lock every operator out without a recovery procedure creates a new organizational failure mode.

8. Performance Controls

Good governance reduces delivery time because identity, evidence, and baseline controls are ready. Poor governance creates ticket queues and policies too broad for managed services to operate.

Measure account-provisioning time, exception lead time, failed deployments caused by controls, control-evaluation delay, and drift-remediation time. Tighten controls using observed access and staged rollout rather than guessing from service names.

9. Cost Controls

Account separation improves ownership, but every baseline can add Config items, logs, security-service coverage, network endpoints, NAT gateways, and support overhead.

Define lighter but still safe sandbox baselines where appropriate. Centralize shared services only when the security, routing, availability, and chargeback model is clear. Attach budgets and cost metadata during account creation rather than after the first surprise bill.

10. Exam Variants

11. Common Traps

• Do not treat an OU as a VPC or resource container.
• Do not say an SCP grants access.
• Do not expect SCPs to restrict the management account.
• Do not attach untested policies at the organization root.
• Do not confuse preventive, detective, and proactive timing.
• Do not assume enrolling an existing account is impact-free.
• Do not let workload accounts own their only audit evidence.
• Do not create workforce IAM users separately in every account without a specific need.
• Do not describe a landing zone as a one-time setup; it has drift, exceptions, and lifecycle operations.

Final Mental Model: One-Minute Review

flowchart LR
  Org["Organizations + OUs"] --> Factory["Account Factory"]
  Factory --> Accounts["Standardized accounts"]
  Controls["Prevent + detect + proactive"] --> Accounts
  Identity["IAM Identity Center"] --> Accounts
  Accounts --> Evidence["Central logs + security"]

Organizations defines the account map; Control Tower operationalizes the baseline; controls constrain behavior; central identity and evidence make the environment governable.

12. Related Topics

Review AWS Account Model, AWS Organizations, Service Control Policies, AWS Control Tower, AWS IAM Identity Center, and Secure Cross-Account CloudTrail Logging.

Official references: What is AWS Control Tower?, Control behaviors, and Service control policies.