Lesson 1: Enterprise Account Hierarchy & Landing Zones

🧠 The Concept (Explain Like I'm 5)

A startup starts with one AWS account containing everything: dev, staging, prod, databases, and billing.

Then an intern runs a test script that deletes the production database.

An Enterprise Landing Zone solves this by creating hundreds of isolated "rooms" (AWS Accounts) inside a secure "building" (AWS Organization). Dev cannot touch Prod. Billing is isolated from engineering. Security teams have a central telescope looking into every room.

---

🏢 The Enterprise Context (Why Platform Architects Care)

1. Blast Radius Isolation: A security compromise or accidental deletion in Account A cannot bring down Account B.
2. Quota & Rate Limits: Cloud providers impose hard API limits per account. Splitting workloads across accounts prevents noisy neighbors from starving critical services.
3. Consolidated Billing & FinOps: Centralized payment with cost allocation tags per business unit.
4. Automated Account Vending: In high-performing engineering orgs, developers request an account via Backstage and a Terraform/Account Factory pipeline automatically provisions a fully compliant account in under 15 minutes.

---

🗺️ Visual Architecture: Enterprise Multi-Account Topology

flowchart TD
    Root["<b>Root Management Account</b><br/>(Billing, IAM Identity Center, SCP Roots)"]

    subgraph SecurityOU ["🔒 Security Organizational Unit (OU)"]
        SecLog["Log Archive Account<br/>(Immutable S3 WORM Storage)"]
        SecTool["Security Tooling Account<br/>(Security Hub, GuardDuty, AWS Config)"]
    end

    subgraph InfraOU ["🌐 Core Infrastructure OU"]
        NetHub["Central Networking Account<br/>(Transit Gateway, Firewall, NAT Egress)"]
        SharedSvc["Shared Services Account<br/>(Artifactory, Golden AMI Pipeline)"]
    end

    subgraph WorkloadOU ["💼 Workloads OU (SDLC)"]
        DevAcc["Dev Workload Account"]
        StgAcc["Staging Workload Account"]
        ProdAcc["Production Workload Account"]
    end

    Root --> SecurityOU
    Root --> InfraOU
    Root --> WorkloadOU

---

🛡️ Service Control Policies (SCPs): The Enterprise Guardrail

An SCP (Service Control Policy) is an organization-wide rule that sets the maximum permissions that any identity inside an account can ever have.

Even the root user or an Administrator with AdministratorAccess inside a member account CANNOT override an explicit Deny in an SCP.

flowchart TD
    Req["Developer triggers: ec2:RunInstances in eu-central-1"]
    SCP{"SCP Check:<br/>Is region allowed in approved list?"}
    IAM{"IAM Policy Check:<br/>Does user have ec2:RunInstances?"}
    Action["Action Allowed ✅"]
    Deny["Action Blocked ❌ (Access Denied by Org Policy)"]

    Req --> SCP
    SCP -->|Denied by SCP| Deny
    SCP -->|Allowed by SCP| IAM
    IAM -->|Allowed| Action
    IAM -->|Denied| Deny

Example SCP: Enforce Region Restriction

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

---

📝 Knowledge Check

Question 1

If an account administrator has an IAM Policy granting *:* (Full Admin), but an SCP attached to their OU denies s3:DeleteBucket, can that administrator delete an S3 bucket?

Question 2

Why do enterprises store centralized logs in a completely dedicated "Log Archive" AWS account with S3 Object Lock enabled?