Landing Zone Architecture

A cloud landing zone is the foundation that every workload is built on. It provides the account structure, networking, identity, security, and governance guardrails that enable teams to deploy safely without reinventing infrastructure. Getting it right at the start prevents years of remediation.

---

Landing Zone Components

Account/Project Structure:
  - Management/Organization account
  - Security account (audit, compliance)
  - Shared Services account (CI/CD, DNS, monitoring)
  - Workload accounts (per team or per environment)

Network Topology:
  - Hub-and-spoke or mesh VPC/VNet design
  - Transit Gateway or Virtual WAN
  - DNS resolution strategy
  - Private connectivity (VPN, Direct Connect)

Identity & Access:
  - SSO federation (Okta, Azure AD)
  - Service accounts and machine identities
  - Break-glass emergency access
  - Role hierarchy and least privilege

Security & Compliance:
  - Centralized logging (CloudTrail, VPC Flow Logs)
  - GuardDuty/Security Hub/Defender
  - SCPs/Policies (preventive guardrails)
  - Config Rules (detective guardrails)

Cost Management:
  - Budget alerts per account
  - Tagging policy enforcement
  - Reserved capacity planning

---

Account Structure

Organization Root
├── Management Account
│   └── Organization-level services, billing
│
├── Security OU
│   ├── Log Archive Account
│   │   └── Centralized CloudTrail, VPC Flow Logs
│   └── Security Tooling Account
│       └── GuardDuty, Security Hub, Config
│
├── Infrastructure OU
│   ├── Networking Account
│   │   └── Transit Gateway, DNS, Direct Connect
│   └── Shared Services Account
│       └── CI/CD, Container Registry, Monitoring
│
├── Workloads OU
│   ├── Production OU
│   │   ├── Team-A Production
│   │   ├── Team-B Production
│   │   └── Team-C Production
│   ├── Staging OU
│   │   └── Shared staging accounts
│   └── Development OU
│       └── Per-developer sandbox accounts
│
└── Sandbox OU
    └── Experimental accounts (limited budget)

---

Guardrails

# Preventive guardrails (SCPs) — prevent actions
preventive:
  - name: "Deny root user access"
    effect: Deny
    action: "*"
    condition: "aws:PrincipalIsAWSService = false AND root user"
    
  - name: "Restrict to approved regions"
    effect: Deny
    action: "*"
    condition: "region NOT IN [us-east-1, us-west-2, eu-west-1]"
    
  - name: "Deny unencrypted S3"
    effect: Deny
    action: "s3:PutObject"
    condition: "s3:x-amz-server-side-encryption = false"
    
  - name: "Deny public S3 buckets"
    effect: Deny
    action: "s3:PutBucketPolicy"
    condition: "bucket policy allows public access"

# Detective guardrails (Config Rules) — detect non-compliance
detective:
  - rule: "ec2-instances-in-vpc"
    description: "All EC2 instances must be in VPC"
    
  - rule: "rds-storage-encrypted"
    description: "All RDS databases must be encrypted"
    
  - rule: "iam-no-inline-policy"
    description: "No inline IAM policies (use managed only)"

---

Network Topology

Hub-and-Spoke:
  
  Workload VPC A ─────┐
  Workload VPC B ──────┤ Transit Gateway ─── Shared Services VPC
  Workload VPC C ──────┤                  └── On-premises (VPN)
  Workload VPC D ─────┘
  
  Benefits:
  - Centralized network control
  - Single point for VPN/Direct Connect
  - Firewall inspection at hub
  
  Considerations:
  - Transit Gateway cost per attachment
  - Single point of failure (mitigate with multi-AZ)
  - Routing complexity at scale

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Single account for everything	No blast radius isolation	Multi-account with OUs
No preventive guardrails	Compliance violations at scale	SCPs from day 1
Manual account provisioning	Weeks to get new environment	Account vending machine (automated)
No centralized logging	Cannot investigate incidents	Log archive account with retention
Flat network (no segmentation)	Lateral movement on breach	VPC per workload, transit gateway

A landing zone is not a project — it is the foundation. Getting it right enables speed. Getting it wrong creates years of remediation work.