Cloud Landing Zone Design

A landing zone is the foundation of your cloud environment: the account structure, networking, security baselines, and governance guardrails that every workload inherits. Getting the landing zone wrong means rebuilding it later — at scale, under pressure, while production workloads are running.

---

Account Structure

Organization Root
├── Security OU
│   ├── Security Tooling Account (GuardDuty, SecurityHub, SIEM)
│   ├── Log Archive Account (centralized CloudTrail, VPC Flow Logs)
│   └── Audit Account (read-only cross-account access)
│
├── Infrastructure OU
│   ├── Network Hub Account (Transit Gateway, VPN, Direct Connect)
│   ├── Shared Services Account (CI/CD, artifact registry, DNS)
│   └── Identity Account (SSO, directory, federation)
│
├── Sandbox OU
│   ├── Dev-Team-A Account (experimentation, low guardrails)
│   └── Dev-Team-B Account
│
├── Workloads OU
│   ├── Production OU
│   │   ├── App-A Production Account
│   │   └── App-B Production Account
│   └── Non-Production OU
│       ├── App-A Staging Account
│       └── App-B Dev Account
│
└── Suspended OU (decommissioned accounts)

Key principles:
  ☐ One workload per account (blast radius isolation)
  ☐ Separate production from non-production
  ☐ Centralized security and logging
  ☐ Network hub for shared connectivity

---

Service Control Policies

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsOutsideUS",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAdmin"
        }
      }
    },
    {
      "Sid": "DenyLeaveOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "RequireIMDSv2",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    },
    {
      "Sid": "DenyPublicS3",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}

---

Network Topology

Hub-and-Spoke with Transit Gateway:

                    ┌──────────────────────┐
                    │   Network Hub Account │
                    │                      │
                    │  ┌────────────────┐  │
                    │  │ Transit Gateway│  │
    Internet ──────►│  └───────┬────────┘  │
    (IGW)           │          │           │
                    │  ┌───────┴────────┐  │
                    │  │  Shared VPC    │  │
                    │  │  (DNS, proxy)  │  │
                    │  └───────────────┘  │
                    └──────────┬──────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
     ┌────────┴───┐  ┌────────┴───┐  ┌────────┴───┐
     │ App-A VPC  │  │ App-B VPC  │  │ App-C VPC  │
     │ (Prod)     │  │ (Prod)     │  │ (Staging)  │
     │ 10.1.0.0/16│  │ 10.2.0.0/16│  │ 10.3.0.0/16│
     └────────────┘  └────────────┘  └────────────┘
     
Non-overlapping CIDR ranges planned from day one!

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Single account for everything	No blast radius isolation	One account per workload
No SCPs	Developers can create uncontrolled resources	Guardrails from day one
Overlapping CIDR ranges	Cannot peer VPCs later	Plan IP address space upfront
No centralized logging	Cannot investigate incidents	Log archive account with retention
Skip identity federation	IAM users everywhere	SSO/federation from day one

Your landing zone is the foundation. Every architectural decision you make later rests on this foundation. Getting it right from the start is the highest-leverage work a cloud team can do.