Designing a Secure AWS Multi-Account Landing Zone: Architecture Patterns for Enterprise Scale

very enterprise AWS deployment eventually hits the same inflection point: a single account becomes ungovernable. Workloads from different teams share blast radius, IAM policies become unwieldy, cost attribution is impossible, and security boundaries blur.

The answer is a multi-account strategy with a well-architected landing zone. This post covers the architecture patterns, OU structures, network topology, and security guardrails needed to build a production-grade AWS landing zone that scales from 10 accounts to 1,000+.

What Is a Landing Zone?

A landing zone is your foundational multi-account AWS environment — the organizational structure, governance controls, networking, and security baseline that exists before any workload arrives. Think of it as the "operating system" for your AWS estate.

Core components:

• AWS Organizations — Account hierarchy and policy management
• AWS Control Tower — Automated landing zone setup and governance
• Landing Zone Accelerator (LZA) — Opinionated, customizable IaC for enterprise landing zones
• Service Control Policies (SCPs) — Preventive guardrails at the organization level
• Centralized networking — Transit Gateway, shared VPCs, DNS
• Security baseline — GuardDuty, Security Hub, Config, CloudTrail across all accounts

Account Structure: The OU Design

The organizational unit (OU) structure is the most critical design decision. It determines how you group accounts, apply policies, and manage access.

Recommended OU Hierarchy

Root
├── Security OU
│   ├── Log Archive Account (centralized logging)
│   ├── Audit Account (security tooling, read-only cross-account)
│   └── Security Tooling Account (GuardDuty, Security Hub delegated admin)
│
├── Infrastructure OU
│   ├── Network Account (Transit Gateway, DNS, shared connectivity)
│   ├── Shared Services Account (AD, CI/CD, artifact repos)
│   └── Backup Account (centralized backup vault)
│
├── Sandbox OU
│   └── Developer sandbox accounts (experimentation, auto-nuke)
│
├── Workloads OU
│   ├── Production OU
│   │   ├── App-A Prod Account
│   │   └── App-B Prod Account
│   ├── Staging OU
│   │   ├── App-A Staging Account
│   │   └── App-B Staging Account
│   └── Development OU
│       ├── App-A Dev Account
│       └── App-B Dev Account
│
├── Policy Staging OU (test SCPs before applying to workloads)
│
└── Suspended OU (quarantined/decommissioned accounts)

Enter fullscreen mode Exit fullscreen mode

Design Principles

1. One workload, one account — Blast radius isolation. A misconfigured security group affects only one workload.
2. Environment separation via OUs — Prod/Staging/Dev get different SCPs and guardrails.
3. Centralize what's shared — Networking, logging, security tooling live in dedicated accounts.
4. Never put workloads in the management account — It's for Organizations management only.

AWS Control Tower: Automated Governance

Control Tower automates landing zone setup and provides:

• Account Factory — Self-service account provisioning with pre-configured baselines
• Guardrails (Controls) — Preventive (SCPs) and detective (Config rules) controls
• Dashboard — Compliance visibility across all accounts
• Region deny — Restrict which AWS regions can be used

Essential Guardrails to Enable

Guardrail	Type	Purpose
Disallow public S3 buckets	Preventive	Prevent data exposure
Require MFA for root user	Detective	Account security
Disallow internet gateways in specific OUs	Preventive	Network isolation
Require encryption on EBS volumes	Detective	Data protection
Deny access to unused regions	Preventive	Reduce attack surface
Require tags on resources	Detective	Cost attribution
Disallow deletion of CloudTrail	Preventive	Audit integrity
Deny root user access	Preventive	Force IAM usage

Landing Zone Accelerator (LZA): Enterprise-Grade IaC

For organizations needing more customization than Control Tower alone provides, the Landing Zone Accelerator (LZA) is an AWS-maintained open-source solution that deploys a comprehensive landing zone via CloudFormation/CDK.

LZA covers:

• Multi-account structure with Control Tower integration
• Centralized networking (Transit Gateway, route tables, DNS)
• Security services deployment across all accounts
• Logging and monitoring pipelines
• Budget alerts and cost management
• Custom CloudFormation stack deployment per account/OU

LZA Configuration Structure

├── accounts-config.yaml      # Account definitions and OU placement
├── global-config.yaml        # Organization-wide settings, regions, tags
├── iam-config.yaml           # IAM roles, policies, identity center
├── network-config.yaml       # VPCs, TGW, route tables, DNS
├── security-config.yaml      # GuardDuty, Security Hub, Config, CloudTrail
├── customizations-config.yaml # Custom stacks deployed per account/OU

Enter fullscreen mode Exit fullscreen mode

This declarative approach means your entire landing zone is version-controlled, auditable, and reproducible.

Network Architecture: Hub-and-Spoke with Transit Gateway

The Pattern

                    ┌──────────────────────┐
                    │   Network Account    │
                    │   (Transit Gateway)  │
                    └──────────┬───────────┘
                               │
        ┌──────────────────────┼──────────────────────┐
        │                      │                      │
        ▼                      ▼                      ▼
┌───────────────┐    ┌──────────────────┐    ┌──────────────────┐
│  Shared VPC   │    │  Workload VPC A  │    │  Workload VPC B  │
│  (Inspection) │    │  (Prod App A)    │    │  (Prod App B)    │
└───────────────┘    └──────────────────┘    └──────────────────┘
        │
        ▼
┌───────────────┐
│ Network       │
│ Firewall /    │
│ Inspection    │
└───────────────┘

Enter fullscreen mode Exit fullscreen mode

Key Networking Decisions

Decision	Recommendation
VPC per account or shared VPC?	VPC per workload account for isolation. Shared VPC only for tightly coupled services.
Transit Gateway vs VPC Peering?	TGW for 5+ accounts. Peering for simple 2-3 account setups.
Centralized egress?	Yes — route internet traffic through a shared inspection VPC with Network Firewall.
DNS resolution	Route53 Resolver in network account with forwarding rules shared via RAM.
On-premises connectivity	Direct Connect to network account TGW, propagate routes to workload VPCs.
IP address management	Use IPAM (VPC IPAM) to prevent CIDR conflicts across accounts.

Network Firewall for Centralized Inspection

All egress traffic from workload accounts routes through a centralized inspection VPC:

1. Workload VPC → Transit Gateway (default route)
2. Transit Gateway → Inspection VPC
3. Network Firewall inspects traffic (domain filtering, IPS/IDS)
4. Allowed traffic → NAT Gateway → Internet

This gives you a single point of visibility and policy enforcement for all outbound traffic.

Security Baseline: Defense in Depth

Services to Enable Across All Accounts

Service	Purpose	Deployment
CloudTrail	API audit logging	Organization trail → Log Archive account
AWS Config	Resource compliance and change tracking	Aggregator in Audit account
GuardDuty	Threat detection	Delegated admin in Security account
Security Hub	Unified security findings	Aggregator with CIS/AWS Foundational benchmarks
IAM Access Analyzer	Find unintended resource sharing	Per account + organization-level
Macie	S3 sensitive data discovery	Delegated admin
VPC Flow Logs	Network traffic visibility	All VPCs → centralized S3
AWS Backup	Centralized backup policies	Backup account with cross-account vaults

Service Control Policies (SCPs): The Guardrail Layer

SCPs are the most powerful governance tool — they set maximum permissions boundaries that even account administrators cannot exceed.

Essential SCPs:

// Deny leaving the organization
{
  "Effect": "Deny",
  "Action": ["organizations:LeaveOrganization"],
  "Resource": "*"
}

// Deny disabling security services
{
  "Effect": "Deny",
  "Action": [
    "guardduty:DeleteDetector",
    "guardduty:DisableOrganizationAdminAccount",
    "securityhub:DisableSecurityHub",
    "config:StopConfigurationRecorder"
  ],
  "Resource": "*"
}

// Deny root user actions
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {"aws:PrincipalArn": "arn:aws:iam::*:root"}
  }
}

Enter fullscreen mode Exit fullscreen mode

Identity and Access: IAM Identity Center

Centralized identity management via IAM Identity Center (formerly SSO):

• Single sign-on across all accounts from one portal
• Permission sets — predefined access patterns (Admin, ReadOnly, Developer, Auditor)
• Integration with corporate IdP (Okta, Azure AD, Active Directory)
• Temporary credentials — no long-lived access keys
• Attribute-based access control (ABAC) — permissions based on user tags

Permission Set Design

Permission Set	Accounts	Access Level
PlatformAdmin	Infrastructure OU	Full admin
SecurityAuditor	All accounts	Read-only security services
DeveloperAccess	Dev/Staging OUs	Power user (no IAM changes)
ProductionReadOnly	Production OU	Read-only (break-glass escalation for changes)
BillingViewer	Management account	Cost and billing only

Cost Management

• AWS Organizations consolidated billing — single payer, volume discounts
• Cost allocation tags — mandatory tags enforced via SCP + Config rules
• AWS Budgets — per-account and per-OU budgets with alerts
• Account-level cost visibility — each team owns their account's spend
• Savings Plans and Reserved Instances — purchased at organization level, shared

Common Mistakes to Avoid

Mistake	Impact	Fix
Workloads in management account	Can't apply SCPs to management account	Dedicated workload accounts only
Flat OU structure	Can't differentiate policies per environment	Nest OUs (Workloads → Prod/Staging/Dev)
No network inspection	Blind to outbound data exfiltration	Centralized egress with Network Firewall
Shared VPCs everywhere	Noisy neighbor, no blast radius isolation	VPC per workload account
No SCP testing	Breaking production with bad policies	Policy Staging OU to test SCPs first
Skipping IPAM	CIDR conflicts between accounts	VPC IPAM from day one
Long-lived access keys	Credential exposure risk	IAM Identity Center with temp credentials

Summary

A well-designed AWS landing zone is the foundation everything else builds on:

1. OU structure — Separate security, infrastructure, and workloads. Nest environments (prod/staging/dev) under workloads.
2. Control Tower + LZA — Automated governance with guardrails. Version-controlled configuration.
3. Hub-and-spoke networking — Transit Gateway in a dedicated network account. Centralized inspection for egress.
4. Security baseline everywhere — CloudTrail, GuardDuty, Security Hub, Config in every account. SCPs as preventive guardrails.
5. Identity Center — Centralized SSO with permission sets. No long-lived credentials.
6. Cost governance — Mandatory tags, per-account budgets, organization-level purchasing.

Get the landing zone right, and everything you build on top — workloads, automation, compliance — inherits the security and governance posture from day one.

---

Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS infrastructure automation and enterprise cloud architecture. Connect on LinkedIn.