How to Design a Multi-Account AWS Landing Zone With Security Guardrails

Retrospective: this article looks back at events from November 2018, written in 2026 with the benefit of hindsight.

A multi-account AWS landing zone separates workloads, centralizes security tools and protects logs. Here is how to design one using AWS's own reference patterns.

Why multiple accounts

An AWS account is a hard security and billing boundary. Separating production from development, and security tooling from workloads, limits the blast radius of any compromise and makes permissions simpler.

Step 1: Design the organizational structure

A common starting structure, following the AWS Security Reference Architecture:

Management account: AWS Organizations, billing and little else.
Security OU: a Log Archive account (centralized CloudTrail, Config and other logs) and a Security Tooling account (delegated admin for GuardDuty, Security Hub, Macie, IAM Access Analyzer).
Infrastructure OU: shared networking (Transit Gateway, inspection VPCs, DNS).
Workloads OU: separate production and non-production accounts per application or team.
Sandbox OU: experimentation with strict cost and permission limits.

Step 2: Choose your tooling

AWS Control Tower is the fastest way to deploy this structure with built-in controls. Larger teams sometimes use Landing Zone Accelerator on AWS or custom infrastructure as code.

Step 3: Centralize identity

Use IAM Identity Center connected to Entra ID or your identity provider. Users sign in once and assume permission sets in each account. Avoid IAM users.

Step 4: Apply guard rails

SCPs: deny leaving the organization, deny disabling CloudTrail or GuardDuty, restrict regions, deny root user actions.
Control Tower detective and proactive controls.

Step 5: Centralize logging and detection

Organization CloudTrail to the Log Archive account with restricted access; GuardDuty and Security Hub delegated to Security Tooling.

Common mistake

Running production workloads in the management account. Keep it empty.