Skip to content

AWS Landing Zone -- Architecture Patterns

This note covers the major architecture patterns for complex project setups on AWS: single-VPC, multi-VPC, multi-account, multi-region, DR, DMZ, and Landing Zone. Each pattern includes the key services, recommended configurations, and real-world examples drawn from official AWS documentation and established practice.

1. Single Account with Single VPC

Architecture Summary

A single VPC is the foundational building block on AWS. A VPC provides an isolated virtual network where you define a private CIDR block, create subnets across Availability Zones, and attach route tables and gateways. For a single project, one VPC with multi-AZ subnets provides isolation, high availability, and simplicity.

Internet --> CloudFront/WAF --> ALB (public subnet, AZ-a/b)
                                  |
                         +--------+--------+
                         |                 |
                   EC2 App (private        EC2 App (private
                   subnet, AZ-a)           subnet, AZ-b)
                         |                 |
                   RDS/Aurora (private subnet, AZ-a, standby in AZ-b)

Key Services

Service Role
VPC Isolated virtual network with custom CIDR, subnets, route tables
Subnet Segment within a VPC, bound to a single AZ; public or private
Route Table Main route table (auto-created) + custom routes; controls traffic forwarding
Internet Gateway (IGW) Enables internet access for public subnets
NAT Gateway Provides outbound Internet (SNAT) for private subnet resources
ALB / NLB Application (L7) or Network (L4) Load Balancer distributes traffic across AZs
Security Group Stateful per-instance firewall (allow rules only, implicit deny)
Network ACL Stateless subnet-level packet filter (allow and deny rules)
Elastic IP (EIP) Static public IP that can be bound to NAT Gateway, NLB, or individual EC2
  • CIDR planning: Use RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Reserve headroom; VPC CIDR cannot overlap with any VPC you plan to peer or connect via TGW later. Use /16 for the VPC and /24 for subnets as a starting point.
  • Multi-AZ subnets: Create at least two subnets per tier in different AZs. Place ALB, EC2, and RDS replicas across both.
  • Subnet tiers: Separate into public (DMZ), private (application), and private (database) subnets. Use route tables to enforce tiered traffic flow.
  • No public IPs on app/DB: Application and database instances should have no public IPs. Use NAT Gateway for outbound Internet and ALB for inbound.
  • Security Groups: One SG per tier (web, app, db), least-privilege rules. Reference SGs in rules rather than IP addresses.

Real-World Example

A SaaS startup deploys a three-tier web application in us-east-1. One VPC (10.0.0.0/16) with subnets in AZs a and b. Public subnets host an ALB. Private subnets host EC2 Auto Scaling Groups. A managed RDS PostgreSQL instance runs with Multi-AZ HA. NAT Gateway in the public subnet provides egress. CloudFront with AWS WAF provides edge security.

2. Multi-VPC Architecture

When workloads span multiple VPCs -- whether for environment isolation (dev/staging/prod), business-unit separation, or regulatory compliance -- AWS offers three primary inter-VPC connectivity options.

2a. Transit Gateway (TGW) -- Hub-and-Spoke

Architecture Summary

AWS Transit Gateway is a regional hub that connects VPCs, VPN connections, Direct Connect gateways, and other TGWs (via inter-region peering). It acts as a cloud router; traffic flows through TGW route tables, enabling centralized routing policy, traffic isolation, and inspection.

A single TGW supports up to 5,000 attachments per Region. Inter-region peering connects TGWs across Regions over the AWS backbone (encrypted, no public internet).

graph TD
    TGW[Transit Gateway - us-east-1]

    TGW --> VPCA[VPC-A: Shared Services\n10.0.0.0/16]
    TGW --> VPCB[VPC-B: Production\n10.1.0.0/16]
    TGW --> VPCC[VPC-C: Development\n10.2.0.0/16]
    TGW --> DX[Direct Connect Gateway\nto On-Premises DC]
    TGW --> VPN[Site-to-Site VPN\nto Branch Office]
    TGW ---|Inter-Region Peering| TGW2[Transit Gateway - eu-west-1]

Key Services

Service Role
Transit Gateway Regional hub; connects VPCs, VPNs, Direct Connect, and peered TGWs
TGW Route Table Controls which attachments can communicate; supports multiple route tables for isolation
TGW Attachment Connection between TGW and a VPC, VPN, Direct Connect, or peered TGW
Inter-Region Peering Encrypted, non-transitive link between TGWs in different Regions
Direct Connect Gateway Connects Direct Connect circuits to TGW for hybrid connectivity
  • Use separate TGW route tables for production, non-production, and shared services to enforce isolation.
  • Inspection VPC pattern: Route all traffic through a centralized inspection VPC with AWS Network Firewall. Use TGW appliance mode for symmetric routing.
  • Dedicated TGW subnet: In each VPC, create a small /28 subnet dedicated to the TGW attachment (keeps TGW ENIs separate from workload subnets).
  • Enable multiple AZs: TGW must have attachments in each AZ where workloads exist to ensure availability and avoid cross-AZ routing charges.
  • Use unique ASNs: When deploying multiple TGWs (e.g., for DR), assign a unique ASN to each for BGP route exchange.
  • Automate with IaC: Manually updating TGW attachments introduces misroutes. Use Terraform pipelines and enforce TGW configuration checks via AWS Config.

Real-World Example

A financial services company has separate VPCs for trading, risk analytics, and back-office in us-east-1. A TGW connects them with three route tables: shared (allows all VPCs to reach shared services), prod (trading + risk, isolated from dev), and dev (back-office + sandbox). An inspection VPC with AWS Network Firewall sits between the TGW and the Internet Gateway, inspecting all north-south traffic. A Direct Connect Gateway provides hybrid connectivity to the on-premises data center.

2b. VPC Peering

Architecture Summary

VPC Peering is a direct, one-to-one connection between two VPCs. It supports same-region and cross-region peering. Unlike TGW, it is a point-to-point link without a central hub. Peering is not transitive -- if A peers with B and B peers with C, A cannot reach C through B.

VPC-A (10.0.0.0/16) <--peering--> VPC-B (10.1.0.0/16)
   Route table: 10.1.0.0/16 -> pcx    Route table: 10.0.0.0/16 -> pcx
  • Ensure CIDR blocks do not overlap between peered VPCs.
  • Same-account peering is simplest; cross-account peering requires acceptance by the peer account.
  • For more than 3-4 VPCs, prefer TGW over individual peering links to avoid combinatorial explosion of peering connections and route entries.
  • VPC Peering has no bandwidth limit and no per-GB data processing charge (only standard cross-AZ/cross-region transfer charges), making it cheaper than TGW for high-volume, simple topologies.
  • Security groups, NACLs, and network tags do not cross peering boundaries.

When to Choose VPC Peering over TGW

  • Small number of VPCs (2-4) with simple, static connectivity.
  • High-volume data transfer where TGW per-GB processing charges are significant.
  • No need for centralized inspection or complex routing policies.

Architecture Summary

AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises applications without exposing traffic to the public internet. Unlike peering, PrivateLink is unidirectional and service-oriented -- a consumer accesses a specific service endpoint, not the entire producer VPC. Traffic uses NAT, so no CIDR coordination is needed.

graph TD
    ConsumerVPC[Consumer VPC] -->|VPC Endpoint\nENI with private IP| PrivateLink[AWS PrivateLink]
    PrivateLink -->|Service Endpoint| ProducerNLB[Producer NLB]
    ProducerNLB --> ProducerVPC[Producer VPC: Managed Service]

    ConsumerVPC -->|Gateway Endpoint| S3[S3 / DynamoDB]
    ConsumerVPC -->|Interface Endpoint| AWSServices[AWS Services\nSQS, KMS, SSM, etc.]

Key Services

Service Role
Interface Endpoint ENI in consumer VPC with private IP; connects to AWS services or PrivateLink-powered services
Gateway Endpoint Route table entry for S3 and DynamoDB (free, no ENI)
Endpoint Service Producer-side NLB that exposes a service via PrivateLink
  • Use Gateway Endpoints for S3 and DynamoDB (free, route-table-based).
  • Use Interface Endpoints for other AWS services (SSM, KMS, SQS, ECR, etc.) to avoid NAT Gateway costs and keep traffic private.
  • Producers should use allowed principals to control which accounts can connect.
  • Combine PrivateLink with VPC endpoint policies for fine-grained access control.

Connectivity Comparison Matrix

Criteria Transit Gateway VPC Peering AWS PrivateLink
Topology Hub-and-spoke Point-to-point Service-oriented (unidirectional)
Scalability Up to 5,000 attachments O(n^2) links for full mesh Per-service endpoints
Cross-region Yes (inter-region peering) Yes Yes (inter-region)
Transitive routing Yes (via route tables) No No
Routing Centralized, multiple route tables Manual per-VPC routes N/A (service-level)
Bandwidth Up to 50 Gbps per VPC attachment No limit Limited by NLB/ENI throughput
Data processing cost $0.02/GB $0 (only transfer) $0.01/GB + hourly endpoint fee
Best for Enterprise multi-VPC Small/simple setups Service exposure, no CIDR overlap

3. Multi-Account Strategy

Architecture Summary

AWS Organizations provides a hierarchical account management framework. Combined with AWS Control Tower, IAM Identity Center, and Service Control Policies (SCPs), it delivers centralized governance, billing, and access control across all accounts.

AWS Organizations (Management Account)
  |
  +-- Security OU
  |     +-- Log Archive Account (CloudTrail, Config logs)
  |     +-- Audit / Security Tooling Account (GuardDuty, Security Hub)
  |
  +-- Infrastructure OU
  |     +-- Network Account (Transit Gateway, Direct Connect, DNS)
  |     +-- Shared Services Account (CI/CD, container registry, AMIs)
  |
  +-- Workloads OU
  |     +-- Business Unit A OU
  |     |     +-- A-Dev Account
  |     |     +-- A-Staging Account
  |     |     +-- A-Prod Account
  |     +-- Business Unit B OU
  |           +-- B-Prod Account
  |
  +-- Sandbox OU
        +-- Experiment Account (time-limited, budget-capped)

Key Services

Service Role
AWS Organizations Multi-account hierarchy: root, OUs, member accounts. Consolidated billing.
AWS Control Tower Landing Zone setup, Account Factory, guardrails (controls), drift detection
Service Control Policies (SCPs) Organization-level preventive guardrails restricting available actions
IAM Identity Center (SSO) Centralized identity: users, groups, permission sets. External IdP federation (SAML/OIDC).
CloudTrail API-level audit logging for all accounts, centralized to Log Archive
AWS Config Compliance rules and configuration tracking across accounts
Security Hub Aggregated security findings from GuardDuty, Inspector, Config, etc.
GuardDuty Intelligent threat detection using ML and anomaly detection
CloudFormation StackSets Deploy IaC across multiple accounts and regions simultaneously
  • Separate accounts by lifecycle stage: dev, staging, prod in different accounts, not different VPCs in the same account. This provides hard blast-radius isolation.
  • Centralized networking account: Owns the Transit Gateway, Direct Connect, and shared VPCs. Workload VPCs attach via RAM (Resource Access Manager) resource sharing.
  • Centralized logging: All accounts stream CloudTrail logs and Config snapshots to the Log Archive account's S3 buckets with bucket policies preventing deletion.
  • Centralized security: Security Hub and GuardDuty delegated administration from the Audit account. AWS Firewall Manager manages WAF and Network Firewall policies across accounts.
  • Account Factory: Use Control Tower Account Factory (or Account Factory for Terraform -- AFT) to provision new accounts with baseline configurations: IAM roles, guardrails, logging, networking, tags.
  • SSO: Federate with external IdP (Okta, Entra ID) via SAML/OIDC. Map IdP groups to permission sets in IAM Identity Center.
  • Cost management: Enable consolidated billing. Use Cost Allocation Tags for cross-account attribution.

Control Types (Guardrails)

Type Mechanism Example
Preventive SCP (blocks API calls) Deny disabling CloudTrail, deny root user access
Detective AWS Config rule Detect S3 buckets without encryption, detect untagged resources
Proactive CloudFormation Hook Block non-compliant resources before deployment

Real-World Example

A multinational enterprise organizes 80+ AWS accounts under Organizations. The Security OU holds the Log Archive and Audit accounts. The Infrastructure OU holds the Network account (Transit Gateway, Direct Connect) and Shared Services account (ECR, CI/CD). Each business unit has its own OU with dev/staging/prod accounts. Account Factory provisions new accounts with baseline IAM roles, CloudTrail forwarding, Config rules, and TGW attachment in under 30 minutes. SCPs enforce: no public S3 buckets in prod, no root user API calls, all resources must have owner and environment tags.

4. Multi-Zone and Multi-Region Deployment Patterns

Multi-Zone (Intra-Region)

AWS Regions contain multiple Availability Zones (AZs) -- physically isolated data centers with low-latency links (typically <2ms between AZs). Deploying across at least two AZs within a region protects against single-datacenter failure.

Key Services and Features

Service Multi-AZ Feature
EC2 Deploy instances across AZs; use Auto Scaling Group with multi-AZ
ALB / NLB Distributes traffic across AZs; health checks remove unhealthy targets
RDS Multi-AZ deployment with synchronous standby and automatic failover (~60s)
Aurora Cluster with up to 15 read replicas across AZs; automatic failover (~30s)
S3 Data redundantly stored across at least 3 AZs by default
ElastiCache Multi-AZ with automatic failover for Redis clusters
EKS Multi-AZ node groups; pod topology spread constraints
  • Minimum two AZs for any production workload; three AZs for critical workloads.
  • ALB should have targets in every AZ where you deploy workloads.
  • RDS: enable Multi-AZ; plan for ~60-second failover window.
  • EC2 Auto Scaling Group: distribute instances evenly across AZs.

Multi-Region

Deploy across geographically separated regions for disaster recovery, compliance, or latency optimization.

Key Services and Features

Service Multi-Region Feature
Transit Gateway Inter-Region Peering over AWS backbone; encrypted
Global Accelerator Anycast acceleration with automatic regional failover
Route 53 Latency-based, geolocation, weighted, and failover routing policies
Aurora Global Database Storage-level replication with <1s latency; promote secondary in <1min
DynamoDB Global Tables Multi-active, multi-region replication with RPO ~0
S3 Cross-Region Replication Asynchronous object replication between buckets in different regions
ElastiCache Global Datastore Cross-region Redis replication for sub-second reads
CloudFront Global CDN with edge caching and origin failover
  • Use Transit Gateway inter-region peering for private cross-region connectivity.
  • Use Route 53 or Global Accelerator for DNS-based or anycast failover.
  • Use Aurora Global Database for relational data with <1s RPO and <1min RTO.
  • Use DynamoDB Global Tables for NoSQL data requiring multi-region active-active writes.
  • Deploy stateless application layers to simplify failover; externalize all state to managed services.

Real-World Example

An e-commerce platform deploys in us-east-1 as primary and us-west-2 as secondary. Transit Gateway inter-region peering connects the two regions. Aurora Global Database replicates data with sub-second latency. S3 CRR replicates static assets. Route 53 failover routing with health checks shifts DNS to us-west-2 if primary becomes unhealthy. The application tier is stateless (ECS Fargate + Auto Scaling), so us-west-2 can scale from warm standby to full capacity in minutes.

5. Disaster Recovery (DR)

DR Strategies

Strategy RPO RTO Cost Pattern
Backup & Restore Hours 24h+ $ S3 cross-region backups, AMI copies, RDS snapshots
Pilot Light Minutes Hours $$ Core infra deployed (DB replicas), compute off
Warm Standby Seconds Minutes $$$ Scaled-down but functional stack running
Active-Active Near-zero Near-zero $$$$ Full capacity in both regions; multi-active writes

Pilot Light

Region A (Primary)                     Region B (DR)
+---------------------+               +---------------------+
| ALB --> ASG (10)    |  Aurora GDB   | ALB --> ASG (0)     |
| Aurora Primary      | ----------->  | Aurora Read Replica  |
| ElastiCache Primary |               | (No compute running) |
+---------------------+               +---------------------+
         |                                      |
         +-- Route 53 failover -- health check --+
  • Aurora Global Database replicates data continuously.
  • Compute is not deployed in the DR region -- defined only in IaC (Terraform/CloudFormation).
  • On failure, Route 53 detects unhealthy primary, shifts DNS. IaC deploys compute in DR region. Aurora secondary is promoted.

Warm Standby

Region A (Primary)                     Region B (Warm Standby)
+---------------------+               +---------------------+
| ALB --> ASG (10)    |  Aurora GDB   | ALB --> ASG (2)     |
| Aurora Primary      | ----------->  | Aurora Read Replica  |
| ElastiCache Primary | ----------->  | ElastiCache Replica |
+---------------------+               +---------------------+
         |                                      |
         +-- Route 53 failover -- health check --+
  • Region B runs the full stack at reduced capacity.
  • On failure, ASG scales up to production capacity. Aurora secondary is promoted. Failover is faster than Pilot Light because compute is already running.

Key Difference: Pilot Light vs. Warm Standby

Pilot Light cannot process requests without additional action (deploying compute, promoting DB). Warm Standby can handle traffic immediately at reduced capacity; recovery only requires scaling up.

Active-Active (Multi-Region)

Region A (Active)                      Region B (Active)
+---------------------+               +---------------------+
| ALB --> ASG (10)    |  DynamoDB GT  | ALB --> ASG (10)    |
| DynamoDB Table      | <---------->  | DynamoDB Table      |
| ElastiCache Global  | <---------->  | ElastiCache Global  |
+---------------------+               +---------------------+
         |                                      |
         +-- Global Accelerator / Route 53 -----+
              (latency-based or geo routing)
  • DynamoDB Global Tables provide multi-active, multi-region replication with RPO ~0.
  • Aurora Global Database can also be used with write-forwarding for active-active reads and writes (primary still handles writes).
  • Global Accelerator routes users to the nearest healthy region with automatic failover.
  • Application must handle eventual consistency and conflict resolution for multi-active writes.
  • Define RTO/RPO targets upfront; they determine the strategy and cost.
  • Use Infrastructure as Code (Terraform or CloudFormation) to define the full stack. In pilot light/warm standby, IaC enables rapid provisioning.
  • Test failover regularly (quarterly minimum). Use Route 53 health check simulation or Global Accelerator traffic dials.
  • Stateless app tier: Externalize all state to managed services (ElastiCache, DynamoDB, S3).
  • Separate DR automation from production: Use different Terraform state files / CloudFormation stacks for the DR region.

6. DMZ / Network Perimeter Patterns

Architecture Summary

AWS supports three deployment models for network inspection:

  1. Distributed -- AWS Network Firewall deployed in each individual VPC.
  2. Centralized -- Network Firewall in a dedicated inspection VPC behind the TGW (recommended for enterprise).
  3. Combined -- Centralized for east-west and egress; distributed for internet ingress.

The centralized model is most common for enterprises:

graph TD
    Internet[Internet] --> IGW[Internet Gateway]
    IGW --> NFW[AWS Network Firewall\nInspection VPC]
    NFW --> TGW[Transit Gateway]
    TGW --> VPCA[Workload VPC A\nPrivate subnets only]
    TGW --> VPCB[Workload VPC B\nPrivate subnets only]
    TGW --> DX[Direct Connect\nto On-Premises]

Key Services

Service Role in Perimeter
AWS Network Firewall Managed stateful L3-L7 inspection. Supports Suricata rules, FQDN filtering, IPS/IDS. Deploy in each AZ for HA.
AWS WAF Application-layer (L7) filtering on ALB, CloudFront, API Gateway. OWASP ModSecurity CRS rules.
AWS Shield Standard Free DDoS protection for all AWS resources.
AWS Shield Advanced Enhanced DDoS protection with 24/7 DDoS Response Team, cost protection, and advanced analytics.
AWS Firewall Manager Centralized management of WAF, Network Firewall, Security Groups, and DNS Firewall across all accounts.
Route 53 Resolver DNS Firewall Outbound DNS filtering to prevent DNS exfiltration.
Security Groups Stateful per-instance firewall. Reference SGs in rules for dynamic, IP-free policies.
Network ACLs Stateless subnet-level filter. Broad rules applied uniformly to all instances in a subnet.

Defense-in-Depth Layers

Layer Control
Edge CloudFront + AWS Shield (DDoS), Route 53 (DNS)
Perimeter AWS WAF (OWASP, bot management, rate limiting)
Network AWS Network Firewall (stateful IPS/IDS, FQDN filtering)
Subnet Network ACLs (stateless, broad rules)
Instance Security Groups (stateful, per-instance least privilege)
DNS Route 53 Resolver DNS Firewall (exfiltration prevention)
Host Amazon Inspector (vulnerability scanning), SSM Patch Manager
Application Application-level auth (Cognito, IAM, OAuth)
  1. Centralized inspection: Deploy Network Firewall in a dedicated inspection VPC. All TGW traffic (north-south and east-west) routes through it.
  2. Symmetric routing: Network Firewall does not support asymmetric routing. Ensure TGW and VPC route entries force return traffic through the same firewall endpoint.
  3. Firewall per AZ: Deploy a firewall endpoint in every AZ where workloads exist.
  4. Stream exception policy: Set to "Continue" or "Reject" (not "Drop") to avoid silently blocking mid-stream flows.
  5. WAF on all external ALBs: Use AWS Managed Rules (Core Rule Set, Known Bad Inputs, SQL injection, XSS) as a baseline.
  6. DNS Firewall: Block known malicious domains and restrict DNS resolution to approved domains for sensitive workloads.
  7. Firewall Manager: Use a single Firewall Manager policy per scope. Multiple policies on the same VPC create multiple firewalls, increasing cost and complexity.

Real-World Example

A fintech company centralizes all internet traffic through an inspection VPC in us-east-1. The inspection VPC has Network Firewall endpoints in three AZs. Suricata rules block known threat signatures and restrict outbound traffic to an allowlist of FQDNs. All workload VPCs connect via TGW with route tables forcing traffic through the inspection VPC. AWS WAF on the external ALB provides OWASP protection. Shield Advanced protects against volumetric DDoS. Firewall Manager enforces WAF and Network Firewall policies across all 40 accounts in the organization.

7. Landing Zone Best Practices

Architecture Summary

An AWS Landing Zone is a well-architected, multi-account environment built on AWS Control Tower. It provides guardrails, account provisioning, centralized logging, and security baselines for all workloads.

Core Landing Zone Components

+-------------------------------------------------------------+
|                    AWS Landing Zone                          |
|                                                              |
|  Management Account (Root)                                   |
|    - AWS Organizations (account hierarchy)                   |
|    - AWS Control Tower (guardrails, Account Factory)         |
|    - Consolidated billing                                    |
|    - IAM Identity Center (SSO)                               |
|                                                              |
|  Security OU:                                                |
|    +-- Log Archive Account                                   |
|    |     CloudTrail + Config -> S3 (immutable, versioned)    |
|    +-- Audit / Security Tooling Account                      |
|          GuardDuty, Security Hub, Inspector, Config rules    |
|                                                              |
|  Infrastructure OU:                                          |
|    +-- Network Account                                       |
|    |     Transit Gateway, Direct Connect, DNS, NAT           |
|    +-- Shared Services Account                               |
|          ECR, CI/CD pipelines, shared AMIs, KMS keys         |
|                                                              |
|  Workload OUs:                                               |
|    +-- Business Unit A (dev/staging/prod accounts)           |
|    +-- Business Unit B (dev/staging/prod accounts)           |
|    +-- Sandbox OU (time-limited, budget-capped accounts)     |
+-------------------------------------------------------------+

Key Services

Service Role in Landing Zone
AWS Control Tower Landing Zone setup, Account Factory, guardrail management, drift detection
AWS Organizations Account hierarchy: root, OUs, member accounts. SCP enforcement.
IAM Identity Center Centralized SSO with permission sets. External IdP federation (SAML/OIDC).
CloudTrail Org-wide API audit logging to Log Archive account
AWS Config Continuous compliance evaluation with managed and custom rules
Security Hub Aggregated findings from GuardDuty, Inspector, Config, Macie
GuardDuty ML-based threat detection across accounts
AWS Firewall Manager Centralized WAF, Network Firewall, SG, DNS Firewall policies
Service Catalog Self-service product provisioning with governance
Terraform / CloudFormation IaC for reproducible Landing Zone deployment

  1. Start with Control Tower: Use the built-in Landing Zone to create the Security OU (Log Archive + Audit) with recommended baselines. Faster and less error-prone than manual setup.

  2. Account Factory: Use Control Tower Account Factory or Account Factory for Terraform (AFT) to auto-provision new accounts with:

  3. IAM roles for admin and operator access (via SSO)
  4. CloudTrail forwarding to Log Archive account
  5. Config rules (baseline compliance)
  6. TGW attachment to the centralized network

  7. Resource tags (owner, environment, cost-center)

  8. Essential SCPs (Preventive Guardrails):

  9. Deny disabling CloudTrail in all accounts
  10. Deny root user API calls (except for console sign-in to management account)
  11. Deny creation of resources outside approved regions
  12. Deny public S3 bucket policies in production OUs

  13. Deny leaving the AWS Organization

  14. Centralized networking:

  15. Network Account owns Transit Gateway and Direct Connect
  16. RAM (Resource Access Manager) shares TGW with workload accounts
  17. Inspection VPC with Network Firewall for centralized traffic inspection

  18. Cloud WAN or TGW inter-region peering for multi-region connectivity

  19. Centralized logging and monitoring:

  20. All accounts forward CloudTrail to Log Archive S3 bucket (versioned, MFA-delete)
  21. Config aggregation in the Audit account
  22. Security Hub cross-account findings aggregation

  23. GuardDuty delegated admin from the Audit account

  24. Identity and access:

  25. Federate with external IdP via SAML/OIDC
  26. Map IdP groups to permission sets in IAM Identity Center
  27. Enforce MFA for all human users
  28. Use IAM roles (not long-lived access keys) for cross-account access

  29. Disable service account key creation where possible

  30. IaC for the Landing Zone itself:

  31. Define the Landing Zone in Terraform (or use Landing Zone Accelerator -- LZA)
  32. Version-control all configuration
  33. Use CI/CD pipeline for changes (plan-and-apply)

  34. AWS provides the Landing Zone Accelerator as an open-source reference implementation

  35. Regular drift detection:

  36. Control Tower detects drift in guardrails, OUs, and accounts
  37. Config rules evaluate continuously
  38. Set up alerts for non-compliant resources
  39. Periodic review of SCPs for relevance

Real-World Example

A large retail enterprise builds its Landing Zone using AWS Control Tower with Account Factory for Terraform. The management account holds Organizations with four top-level OUs: Security, Infrastructure, Workloads, and Sandbox. The Security OU contains Log Archive and Audit accounts. The Infrastructure OU contains the Network account (Transit Gateway, Direct Connect, Route 53 private hosted zones) and Shared Services account (ECR, CodePipeline). Each business unit (Online, Stores, Supply Chain) has a sub-OU under Workloads with dev/staging/prod accounts. Account Factory provisions new accounts with baseline IAM roles, CloudTrail forwarding, Config rules, and TGW attachment in under 30 minutes. SCPs enforce: no public S3 buckets in prod, no root user API calls, resources only in approved regions (us-east-1, us-west-2, eu-west-1). Firewall Manager enforces WAF policies on all ALBs across accounts.

8. Service Naming Quick Reference

Concept AWS Service Console Abbreviation
Virtual Network Virtual Private Cloud VPC
Subnet Subnet Subnet
Load Balancer (L7) Application Load Balancer ALB
Load Balancer (L4) Network Load Balancer NLB
Load Balancer (Appliance) Gateway Load Balancer GLB
NAT NAT Gateway NAT GW
Firewall (L3-L7, managed) AWS Network Firewall NFW
WAF AWS WAF WAF
DDoS Protection AWS Shield Shield
Centralized Firewall Mgmt AWS Firewall Manager FMS
DNS Firewall Route 53 Resolver DNS Firewall DNS FW
Transit Hub AWS Transit Gateway TGW
Global WAN AWS Cloud WAN Cloud WAN
Dedicated Line AWS Direct Connect DX
VPN AWS Site-to-Site VPN VPN
DNS Amazon Route 53 R53
Anycast Acceleration AWS Global Accelerator GA
CDN Amazon CloudFront CF
Multi-account management AWS Organizations Orgs
Governance / Landing Zone AWS Control Tower CT
IAM / SSO IAM Identity Center IDC
IaC (native) AWS CloudFormation CFN
Object Storage Amazon S3 S3
Relational DB (managed) Amazon RDS RDS
Cloud-native DB (MySQL/PG) Amazon Aurora Aurora
NoSQL (key-value) Amazon DynamoDB DDB
In-memory Cache Amazon ElastiCache ElastiCache
Data Replication AWS DMS (Database Migration Service) DMS
Audit trail AWS CloudTrail CT
Compliance AWS Config Config
Security Findings AWS Security Hub SH
Threat Detection Amazon GuardDuty GD
Key Management AWS KMS KMS
Container Registry Amazon ECR ECR
Managed Kubernetes Amazon EKS EKS
Managed Containers Amazon ECS + Fargate ECS
Serverless Compute AWS Lambda Lambda
Backup AWS Backup Backup
Elastic DR AWS Elastic Disaster Recovery DRS