New engagements · 24h →
Skip to main content
Home / Architectures / AWS Landing Zone
Production Tested AWS Organizations

AWS Landing Zone

Multi-account AWS strategy for enterprise workloads. Security isolation, centralized logging and guardrails across all accounts.

Overview

A Landing Zone establishes a secure, well-architected multi-account AWS environment based on AWS best practices. This pattern eliminates the single-account anti-pattern that creates security and billing risks as organizations grow.

Each workload environment (dev, staging, prod) lives in its own AWS account. Security tooling runs in a dedicated Security account. Shared networking and DNS live in a Shared Services account. AWS Organizations Service Control Policies enforce guardrails across the entire structure.

Architecture Diagram

Architecture Diagram

AWS Landing Zone — Account Structure

Root Account Billing · Organizations · SCPs Security Account CloudTrail · Config GuardDuty · Security Hub Shared Services Route 53 · ACM Transit Gateway · Bastion Dev OU Development workloads Dev Account VPC · EKS · RDS Single-AZ (cost optimised) Prod OU Production workloads Prod Account VPC · EKS · RDS Multi-AZ Deletion protection ON SCPs applied at OU level — inherited by all accounts Service Control Policies — deny root usage, enforce MFA, restrict regions All API calls
Multi-account hierarchy with Security, Shared Services and workload accounts managed through AWS Organizations.

Components

Root Account

Billing consolidation, AWS Organizations management, SCP enforcement. No workloads run here. Root credentials locked away with MFA.

Security Account

Centralized CloudTrail for all accounts, AWS Config rules, GuardDuty findings aggregation, Security Hub. Read-only access to all other accounts for security auditing.

Shared Services Account

Route 53 hosted zones, AWS Certificate Manager, Transit Gateway hub. Shared NAT Gateway to reduce per-account NAT costs. Optional bastion host.

Workload Accounts

One account per environment (dev, staging, prod). Isolated blast radius. VPC, EKS/ECS, RDS, S3 per account. SCPs restrict dangerous operations.

Trade-offs

Complexity

✅ Better security isolation and blast radius reduction

⚠️ Higher operational overhead, more IAM to manage

Cost

✅ Free Tier applies per account, consolidated billing visibility

⚠️ Transit Gateway data transfer charges, multiple NAT costs

Management

✅ SCPs centrally enforced, audit trail in one place

⚠️ Requires AWS Organizations, Control Tower recommended

Best Practices

Never use root account for daily operations — lock the credentials and forget them

Enable MFA on all IAM users, enforce via SCP

Use AWS IAM Identity Center (SSO) for human access — no IAM users in workload accounts

Automate account vending with AWS Control Tower Account Factory

GuardDuty must be enabled in every account and every region you use

Log everything to the Security account — S3 bucket with object lock for immutability

Stack

AWS Organizations SCPs CloudTrail Config GuardDuty Security Hub Transit Gateway Route 53 Terraform Control Tower

Need this implemented?

We implement Landing Zones with Terraform from scratch. Includes SCP design, Control Tower setup and account vending automation.

Start a conversation →

Related

EKS Production Platform → Terraform Standards →