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:

1. VPC Peering: Direct network connection between VPCs
2. Transit Gateway: Central hub connecting all VPCs
3. PrivateLink: Private endpoint connections
4. 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:

1. AWS Organizations module: Set up organization structure.
2. Account module: Create Security, Shared Services, Prod, Dev accounts.
3. Networking module: Create VPCs, Transit Gateway, subnets.
4. Security module: Enable CloudTrail, GuardDuty, Config Rules.
5. IAM module: Define cross-account roles, policies.
6. 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:

1. Request resources: 'I need prod and dev environments'
2. Platform team provisions: Terraform creates accounts, VPCs, databases.
3. Team gets credentials: Access to their dev account (full), prod account (limited).
4. Pre-built compliance: Everything is already encrypted, logged, monitored.
5. 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