Architecture Stack: Landing Zones

This is a conversation between Alex (Engineering Manager) and Jordan (Senior Architect) exploring AWS Landing Zones.

Part 1: The Multi-Account Problem

Alex: "Jordan, we have Terraform managing AWS. But it's all in one account. Isn't that risky?"

Jordan: "Very risky. Single account is a single blast radius. One mistake and everything is affected. One compromised credential and all of AWS is exposed."

Alex: "So separate accounts?"

Jordan: "Exactly. But how? How many? How are they organized? How do they communicate? That's what Landing Zones answer."

Alex: "What's a Landing Zone?"

Jordan: "A prescriptive multi-account AWS architecture. AWS provides a reference architecture (best practices for account structure, networking, security, compliance). We implement it with Terraform."

Alex: "Why 'landing zone'?"

Jordan: "Metaphor: when an airplane lands, it needs a runway, taxiway, gates, security. Landing Zone is the equivalent for cloud projects. When a new team starts using AWS, they 'land' in a pre-built, compliant structure."

Part 2: The Multi-Account Architecture

Alex: "How many accounts do you need?"

Jordan: "At minimum: 3 accounts for a small company. More for larger companies.

Security Account: Logging, monitoring, security tools. Central security team manages.

Shared Services Account: Common services (DNS, email, monitoring infrastructure). Shared across all projects.

Production Account: Where production workloads run.

Staging Account: Pre-production environment.

Development Account: Development workloads.

Management Account: Billing, organization management."

Alex: "That's a lot of accounts."

Jordan: "Yes. But each has a purpose and isolation. If production is compromised, development is unaffected."

Part 3: Why Multiple Accounts?

Alex: "What's the benefit?"

Jordan: "Several:

Isolation: Blast radius limited to one account. A mistake in dev doesn't affect prod.

Cost Allocation: Each account has its own billing. Easy to see which team/project costs what.

Access Control: IAM policies at account level. Dev team can't access prod account.

Compliance: Production meets strict compliance. Development is looser. Both coexist without conflict.

Scaling: AWS has account-level limits (VPCs per account, security groups per VPC, etc.). Multiple accounts bypass these.

Blast Radius Reduction: Compromise of dev credentials doesn't expose prod secrets.

Operational Simplicity: Separate teams manage separate accounts. No stepping on toes."

Alex: "This is architecture for safety?"

Jordan: "Completely. Landing Zones are about safety at scale."

Part 4: Account Structure

Alex: "Walk me through the account structure."

Jordan: "Standard AWS Landing Zones structure:

Organization (AWS Organizations service)
├── Management Account (billing, organization management)
│   └── AWS Organizations
│   └── Consolidated Billing
├── Security Account (centralized security, logging, monitoring)
│   └── GuardDuty (threat detection)
│   └── CloudTrail (audit logs)
│   └── SecurityHub (security findings)
├── Shared Services Account (common infrastructure)
│   └── VPC with NAT Gateway
│   └── Route 53 (DNS)
│   └── SSM Parameter Store
├── Production Account (prod workloads)
│   └── EKS Cluster
│   └── RDS Database
│   └── Application Services
├── Staging Account (pre-prod testing)
│   └── EKS Cluster (staging)
│   └── RDS Database (staging replica)
└── Development Account (dev workloads)
    └── Developer testing
    └── Loose security (for speed)

Each account is independent but connected through networking."

Alex: "How do they communicate?"

Jordan: "Several options:

VPC Peering: Direct network connection between VPCs
Transit Gateway: Central hub connecting all VPCs
PrivateLink: Private endpoint connections
VPN: Over internet (slower)

Most Landing Zones use Transit Gateway for hub-and-spoke model. All accounts connect to central Transit Gateway."

Part 5: Networking in Landing Zones

Alex: "How does traffic flow?"

Jordan: "Hub-and-spoke with Transit Gateway:

Dev Account VPC ──┐
                  │
Staging VPC ──────┼──── Transit Gateway ──── Shared Services VPC
                  │                           (NAT, DNS, etc)
Prod VPC ─────────┘

Dev needs to reach Staging or Prod? Traffic goes through Transit Gateway. Shared Services need to reach Prod? Same path. Central point for monitoring and security."

Alex: "Does everything route through Shared Services?"

Jordan: "No. You configure routing rules. Dev to Staging is direct (via Transit Gateway). Both reach Shared Services for DNS. But Dev doesn't route through Prod."

Alex: "Flexibility?"

Jordan: "Yes. You define the network topology. Transit Gateway makes it scalable."

Part 6: Security & Compliance Controls

Alex: "How do you enforce security?"

Jordan: "Multiple layers:

IAM Policies: Who can do what. Prod team can't modify dev resources.

Service Control Policies (SCPs): Organization-level restrictions. Can't create unencrypted S3 buckets, can't disable CloudTrail.

VPC Flow Logs: Record all network traffic. Audit for compliance.

CloudTrail: Record all API calls. Who changed what when.

Config Rules: Continuous compliance checking. S3 bucket isn't encrypted? Alert.

GuardDuty: Threat detection. Unusual network traffic? Alert.

Network ACLs & Security Groups: Firewall rules at account/subnet level."

Alex: "Security is built in?"

Jordan: "Not optional. Landing Zones enforce security and compliance from day one."

Part 7: Centralized Logging

Alex: "Where do logs go?"

Jordan: "Central Security Account. All accounts send logs there:

CloudTrail: API call logs from all accounts VPC Flow Logs: Network traffic from all accounts Application Logs: S3 bucket in Security Account GuardDuty Findings: Security alerts

Central location for audit, compliance, and investigation."

Alex: "Who has access?"

Jordan: "Security team only. Application teams can't access other teams' logs. Auditors can read (via special roles). Protects privacy while enabling compliance."

Part 8: Terraform Implementation

Alex: "How do you implement Landing Zones with Terraform?"

Jordan: "AWS provides Control Tower (clickops solution) or you build manually with Terraform.

Terraform approach:

AWS Organizations module: Set up organization structure.
Account module: Create Security, Shared Services, Prod, Dev accounts.
Networking module: Create VPCs, Transit Gateway, subnets.
Security module: Enable CloudTrail, GuardDuty, Config Rules.
IAM module: Define cross-account roles, policies.
Monitoring module: CloudWatch dashboards, alerting.

All defined in Terraform. Version controlled. Reproducible."

Alex: "Who maintains this?"

Jordan: "Platform team. They define the Landing Zone blueprint. Application teams use it."

Part 9: Application Team Onboarding

Alex: "New team joins. What do they do?"

Jordan: "They don't create accounts or infrastructure. They use Landing Zone:

Request resources: 'I need prod and dev environments'
Platform team provisions: Terraform creates accounts, VPCs, databases.
Team gets credentials: Access to their dev account (full), prod account (limited).
Pre-built compliance: Everything is already encrypted, logged, monitored.
Deploy applications: Use Kubernetes (already set up in EKS), deploy via ArgoCD.

No infrastructure work. They focus on applications."

Alex: "That's self-service?"

Jordan: "Sort of. Platform team still provisions (via Terraform automation). But process is streamlined. Not manual."

Part 10: Cost Allocation & Chargeback

Alex: "Multiple accounts means multiple bills?"

Jordan: "Yes. Consolidated Billing aggregates into one invoice. But you can see costs per account.

Cost allocation:

Dev team's account: $2,000/month
Staging: $4,000/month
Prod: $15,000/month

Each team knows their costs. Can optimize. Finance can chargeback to teams. Accountability."

Alex: "Prevents cost waste?"

Jordan: "Massively. When people see their costs, they optimize. Old dev resources running? They shut it down."

Part 11: Scaling Beyond Initial Accounts

Alex: "Start with 6 accounts. Eventually you need more?"

Jordan: "Yes. Additional project accounts, data accounts, etc. Landing Zone is flexible.

Evolving structure:

├── Management
├── Security
├── Shared Services
├── Prod (main)
├── Staging (main)
├── Dev (main)
├── Data Account (new)
├── Project X Prod (new)
├── Project X Staging (new)
└── Project X Dev (new)

All connect via Transit Gateway. Same security model. Just more accounts."

Alex: "Terraform scales with this?"

Jordan: "Yes. Terraform modules generate accounts programmatically. Add new project account by updating a variable. Done."

Part 12: Account Closure & Cleanup

Alex: "What if you want to shut down an old project?"

Jordan: "Terraform destroy the account. Removes all resources, closes the account. Clean."

Alex: "What about backups?"

Jordan: "Before destroying, export data. Or keep backups in long-term storage account. Terraform can handle this (export databases, archive S3 buckets)."

Alex: "Safety?"

Jordan: "Terraform requires confirmation before destructive operations. And you review in Git before applying."

Part 13: Common Landing Zone Patterns

Alex: "Are there standard patterns?"

Jordan: "Yes. AWS publishes reference architecture. Also third-party tools:

AWS Control Tower: Fully managed Landing Zone. Clickops + automation. Good for small to medium.

Terraform Modules: Community modules (terraform-aws-modules). Can build custom Landing Zone.

Terraform Cloud Blueprints: Pre-built Terraform configurations.

Third-party (Gruntwork, Cloudposse): Commercial Terraform modules with support.**"

Alex: "We use custom Terraform?"

Jordan: "We have a mix. AWS modules for VPC and basic setup. Custom modules for our specific patterns."

Part 14: Challenges & Best Practices

Alex: "What goes wrong?"

Jordan: "Several pitfalls:

Over-Compartmentalization: Too many accounts makes management harder. Balance is key.

Cross-Account Complexity: Debugging issues across accounts is hard. Solution: good monitoring and logging.

Credential Rotation: More accounts means more credentials to manage. Solution: use IAM roles, automatic credential rotation.

Account Limits: AWS has limits per account (VPCs, NAT Gateways, etc.). Design for these limits.

Cost Visibility: Billing across accounts can be confusing. Solution: good tagging and cost allocation.

Onboarding Complexity: New teams confused by account structure. Solution: good documentation and automation."

Alex: "Mostly operational challenges?"

Jordan: "Yes. Landing Zones are architecturally clean. Operationally complex."

Part 15: Landing Zones & Terraform Workspaces

Alex: "How do workspaces fit?"

Jordan: "Terraform workspaces are a feature (separate state per workspace). Landing Zones might use workspaces for different accounts.

Example: terraform workspace prod (apply to prod account) terraform workspace staging (apply to staging)

But for true account separation, using separate Terraform backends (one per account) is cleaner. Avoids accidental cross-account operations."

Part 16: Bridging to Modules

Alex: "We've covered individual accounts and structure. What's the pattern for reusability?"

Jordan: "Modules. How do you package Landing Zone components so they're reusable across companies? That's what's next."

Alex: "So Landing Zones are the organizational pattern. Modules are the reusable building blocks?"

Jordan: "Exactly. Landing Zones define the overall structure. Modules define the components."

Part 17: The Bottom Line

Alex: "If I pitch this?"

Jordan: "Landing Zones are a prescriptive multi-account AWS architecture. Instead of one account (risky), you have separate accounts for dev, staging, production, security, shared services. Each is isolated but connected. Security and compliance are built-in. Costs are tracked per account. New teams onboard quickly with pre-built infrastructure. Everything is managed by Terraform. Scaling is handled automatically."

Alex: "And the commitment?"

Jordan: "We're saying: multi-account is non-negotiable. Safety through isolation. We own the architecture (via Terraform) and scale it as we grow."

Key Takeaways

| Aspect | Details | | ------------------- | ------------------------------------------------------------------------------- | | Core Concept | Multi-account AWS structure with separation of concerns and security | | Primary Benefit | Isolation, compliance, cost tracking, security enforcement | | Account Types | Management, Security, Shared Services, Production, Staging, Development | | Networking | Transit Gateway hub-and-spoke for inter-account communication | | Security | SCPs, IAM policies, VPC Flow Logs, CloudTrail, GuardDuty, Config Rules | | Cost Tracking | Per-account billing for chargeback and optimization | | Scaling | Terraform generates additional accounts programmatically | | Best Practices | Centralized logging, least-privilege access, automated compliance, good tagging |

L3 Series Progress

Terraform & OpenTofu ✓ (infrastructure definition language)
Landing Zones ✓ (account structure and guardrails)
Modules & Reusable Patterns (DRY infrastructure)

Next: Terraform Modules and reusable infrastructure patterns.