An AWS Landing Zone is the multi-account foundation that separates production from development, security tooling from workloads, and billing visibility from operational noise. For companies that started on a single AWS account and are scaling, setting up a Landing Zone is the infrastructure investment that pays dividends for years.
This post covers what an AWS Landing Zone setup actually includes, the architecture decisions that matter at setup time (and are expensive to change later), and what the implementation looks like.
Why a Landing Zone Matters
Single-account AWS environments create compounding problems as teams scale:
- No environment isolation: A misconfigured dev resource can affect production.
- No cost visibility: Who spent what on which product or team?
- Blast radius: A compromised IAM key has access to everything.
- Compliance scope: Security tools, audit logs, and compliance controls are mixed with application workloads.
- Permission sprawl: IAM policies accumulate across services without clear ownership.
Landing Zone solves these by establishing a deliberate account structure with guardrails from day one.
AWS Landing Zone Setup: Two Approaches
Option 1: AWS Control Tower
AWS Control Tower is AWS's managed Landing Zone service. It provisions a baseline multi-account setup with:
- Management account + core accounts (Log Archive, Audit)
- AWS Organizations with baseline Service Control Policies
- AWS Config and CloudTrail enabled across all accounts
- IAM Identity Center (SSO) configured
- Account Factory for provisioning new accounts via a self-service portal
Control Tower is the right choice when: - You want AWS to manage the baseline and receive automatic updates - You have limited infrastructure engineering capacity - You're starting fresh without existing AWS Organizations configuration
Limitations: Control Tower has opinionated defaults that can conflict with existing configurations. Enrolling existing accounts is possible but requires careful sequencing.
Option 2: Custom Landing Zone with Terraform
Custom Terraform-based Landing Zone gives full control over account structure, SCP design, and automation. The right choice when: - You have existing AWS Organizations configuration to work within - You need non-standard account structures or SCP logic - Your team wants to own the full IaC stack - You need to integrate with existing identity providers beyond what IAM Identity Center supports
We build custom Landing Zones for clients who need this level of control.
Core Account Structure
The standard account structure for a scaling SaaS company:
Management Account (billing, Organizations root, no workloads)
├── Security OU
│ ├── Security Tooling Account (GuardDuty master, Security Hub master, SIEM)
│ └── Log Archive Account (immutable CloudTrail, Config, VPC Flow Logs)
├── Infrastructure OU
│ └── Shared Services Account (Transit Gateway, internal DNS, shared tooling)
├── Workloads OU
│ ├── Production Account (prod application workloads)
│ ├── Staging Account (staging/QA workloads)
│ └── Development Account (dev workloads)
└── Sandbox OU
└── Sandbox Account (individual developer experimentation)
This structure provides: - Blast radius isolation: Prod compromise doesn't touch dev or security tooling - Cost attribution: AWS Cost Explorer aggregates per account - Security scope: Security tools in dedicated account with read-only access to all others - Log immutability: Log Archive account has policies preventing deletion
Key Architecture Decisions (Hard to Change Later)
CIDR Allocation
VPC CIDR ranges must be planned at Landing Zone setup time. Overlapping CIDRs between accounts prevent VPC Peering or Transit Gateway routing.
Recommended approach: define a master CIDR plan before any VPCs are created.
Master CIDR: 10.0.0.0/8
Production: 10.0.0.0/16
Staging: 10.1.0.0/16
Development: 10.2.0.0/16
Shared Services: 10.10.0.0/16
Security: 10.20.0.0/16
Retrofitting CIDR plans after VPCs exist requires recreating VPCs — expensive and risky.
Transit Gateway vs. VPC Peering
For accounts that need to communicate (e.g., workload accounts to shared services):
VPC Peering: Point-to-point connections. Simple for 2–3 accounts. Doesn't scale (N×(N-1)/2 connections for N accounts).
Transit Gateway: Hub-and-spoke routing. All accounts attach to the TGW. Scales to hundreds of accounts. Higher base cost (~$0.05/hr per attachment) but correct for multi-account organizations.
Decision: if you have 5+ accounts or expect growth, start with Transit Gateway.
IAM Identity Center (SSO)
Human access to AWS accounts should flow through IAM Identity Center — not individual IAM users in each account. IAM Identity Center: - Single login portal for all accounts - Permission sets assigned to groups (not individuals) - Session-based credentials (no long-lived keys) - SAML federation with Google Workspace, Okta, Azure AD, etc.
Setting up IAM Identity Center at Landing Zone time is straightforward. Migrating from per-account IAM users to IAM Identity Center after the fact is a significant change management exercise.
Service Control Policies
SCPs are the guardrail layer — deny policies that apply regardless of IAM permissions. Core SCPs to establish at Landing Zone time:
{
"Statement": [
{
"Sid": "DenyLeavingOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
},
{
"Sid": "DenyDisablingSecurityServices",
"Effect": "Deny",
"Action": [
"guardduty:DeleteDetector",
"cloudtrail:DeleteTrail",
"config:DeleteConfigurationRecorder"
],
"Resource": "*"
},
{
"Sid": "DenyRootUserAccess",
"Effect": "Deny",
"NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice"],
"Resource": "*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::*:root"
}
}
}
]
}
SCPs are easier to establish at Landing Zone time than to add retroactively (retroactive SCPs can break existing workflows if permissions were previously broader).
Implementation Timeline
Week 1: Account structure design and CIDR planning. IAM Identity Center configuration and federation with your identity provider.
Week 2: Management account setup, Organizations structure, core accounts (Security, Log Archive). Baseline SCPs applied.
Week 3: Security tooling deployment — GuardDuty (delegated admin to Security Tooling account), Security Hub aggregation, Config organization-level rules, centralized CloudTrail to Log Archive.
Week 4: Transit Gateway, shared VPCs, workload account VPC builds with planned CIDRs. Network connectivity testing.
Week 5: Workload migration — existing resources in legacy single-account environment moved to appropriate workload accounts.
Week 6: Validation, runbook documentation, team training on new access patterns.
For deeper context on the infrastructure patterns we use, see AWS Cloud Infrastructure and our guide on Terraform infrastructure as code.
Also see AWS Control Tower documentation for the managed approach.
Frequently Asked Questions
When is the right time to set up a Landing Zone?
Earlier is better. The ideal time is before you have significant workloads — when account migration cost is low. The second-best time is when you have a specific forcing function: SOC 2 audit, enterprise customer procurement, or team scaling that makes single-account management painful. Retroactive Landing Zone setup is possible but requires workload migration.
Can we use Control Tower if we already have AWS Organizations?
Yes, with care. Control Tower can enroll existing organizational units and accounts, but the enrollment process has prerequisites (existing accounts must meet baseline requirements). Plan the enrollment sequencing carefully — enroll accounts with the fewest resources first to validate the process.
How does Landing Zone affect our CI/CD pipelines?
Pipelines that deploy across accounts need cross-account IAM roles. The pattern: CI/CD runs in a shared services account, assumes deployment roles in each workload account via STS AssumeRole. OIDC federation eliminates the need for long-lived keys in the CI system.
What happens to our existing resources in the single account?
Resources stay functional during migration. We typically migrate by account type: non-production resources first (dev, staging), then production. Migration involves recreating resources (ECS tasks, RDS instances, Lambda functions) in the target account rather than account-level moves.
How does billing work in a multi-account organization?
Consolidated billing is automatic with AWS Organizations. The management account receives one bill aggregating all member accounts. Cost Explorer in the management account shows breakdowns by account, service, region, and tag. Member accounts see their own costs in their own Cost Explorer views.
Talk to us about your AWS architecture → rutagon.com/contact