Skip to content

Enterprise AWS Landing Zone

Multi-account foundation with guardrails, central logging and IaC

Production experience — sanitized case studyImplemented & validated locally

Basis: CV: designed and implemented multi-account AWS architecture including VPC topologies, network segmentation and IAM governance across multiple client environments. The published code is a reference implementation of that pattern — all names, accounts and values are synthetic.

Overview

An AWS Organizations layout with security, logging, shared-services and workload accounts, SCP guardrails, IAM Identity Center access, centralized CloudTrail and a VPC baseline — all from Terraform modules.

Problem

Putting every environment in one account makes blast radius, billing and access control hard. Teams end up with long-lived IAM users and no reliable audit trail.

Solution

Separate accounts by function and environment under organizational units, enforce non-negotiables with SCPs, centralize logs in an account workloads cannot modify, and grant human access only through Identity Center permission sets.

Architecture

  1. Management

    • Organizations

      SCPs, billing

    • Identity Center

      permission sets

  2. Security OU

    • Log archive

      org CloudTrail, Config

    • Security tooling

      GuardDuty, Security Hub admin

  3. Infrastructure OU

    • Shared services

      Transit Gateway, DNS, CI

  4. Workloads OU

    • dev

    • staging

    • prod

Organizational structure; logs flow one way into the log archive account.

Technology stack

  • AWS Organizations
  • IAM Identity Center
  • Service Control Policies
  • CloudTrail
  • AWS Config
  • GuardDuty
  • Security Hub
  • Transit Gateway
  • Terraform

Implementation

  • Terraform modules for the organization and OUs, account vending, SCP guardrails, an org CloudTrail log archive, Identity Center, an account baseline and a Transit Gateway network hub, composed into management, shared-services and workload environments.
  • SCPs: region allow-list with global-service exemptions, IMDSv2 required on RunInstances, security services protected, root denied, tags required on create, Suspended OU denies everything.
  • SCP checker enforces AWS limits in CI — minified size under 5,120 characters and at most 5 policies per target, counting FullAWSAccess.
  • An SCP simulator answers questions like 'can a prod account launch EC2 in a non-approved region?' — a teaching approximation, documented as such.
  • Policy attachments, template values and the CIDR plan live in JSON read by both Terraform and the Python tools, so CI checks exactly what would be deployed.
  • 130 unit tests; README examples are re-run and compared by the test suite; 10 Terraform directories validate in a CI matrix.

Security

  • No IAM users for humans; access through Identity Center permission sets, including a PowerUser set that denies IAM and Organizations changes.
  • Log archive bucket with Object Lock, versioning, a TLS-only policy scoped to the organization, and a KMS-encrypted multi-region trail with log file validation.
  • Per-account baseline: EBS default encryption, S3 account-level public access block, password policy, Access Analyzer and a budget.

Reliability

  • Transit Gateway route tables per environment, with RFC 1918 blackhole routes so prod and nonprod cannot reach each other even via the shared egress path.
  • Spoke CIDRs are checked for overlaps and RFC 1918 compliance both in Terraform and in CI.

Cost

  • Transit Gateway attachments and data processing plus NAT in the egress VPC are the largest line items; centralizing egress trades NAT count for TGW processing (figures in the cost doc are illustrative).
  • Per-account budgets and consolidated billing give showback per team; tags are enforced at creation.

Results

No quantified results are published for this project. Figures from client work are confidential, and this portfolio only shows numbers that can be verified or reproduced.

Code & documentation

Lessons learned

  • Decide the OU structure by policy boundary, not by org chart.
  • Control Tower / Account Factory is often the right answer; this shows the primitives underneath it.
  • Known gaps, stated in the README: two bootstrap steps are manual, member-account GuardDuty/Config recorders are not configured, and nothing has run in a real organization.