Case: Cloud Landing Zone

Lernziele

Nach dieser Lektion kannst du den Case „AWS Landing Zone für ein cloud-natives Unternehmen” im Interview durchspielen: Du erklärst Account-Struktur und Guardrails, kannst Account Vending mit Terraform begründen, hast Antworten auf Hub-Spoke-Netzwerk und SCP-Einwände parat und weißt, wie fünf Platform Engineers 30 App Teams enablement ohne Bottleneck versorgen.

Das Szenario

Die Aufgabe: „Unser Unternehmen wird cloud-native. Designe eine AWS Landing Zone. Wir haben fünf Platform Engineers und 30 App Teams. Compute-Plattform ist EKS, IaC mit Terraform, Identity über Okta. Compliance: SOC2, Encryption everywhere.” Der Case testet, ob du Landing Zone als Produkt verstehst — nicht als einmaliges Terraform-Apply, sondern als wiederholbaren Prozess, der neue Accounts und Teams mit eingebauten Guardrails versorgt.

Anforderungen klären: Organisation vor Infrastruktur

Diese Fragen bestimmen, ob du drei Accounts oder dreißig baust:

• „Wie viele Umgebungen, wie strikt die Trennung?” — Angenommen: prod, staging, dev — jeweils eigene Accounts oder OU-Gruppen. Kein Shared-Prod-Dev.
• „Wer darf Accounts anlegen — nur Platform oder auch Teams?” — Angenommen: Platform Team vendet Accounts über Self-Service-Portal, Teams bekommen vorkonfigurierte Workload-Accounts.
• „Welche Shared Services?” — Angenommen: ECR, Route53, zentrales Logging, Vault, CI-Plattform. Diese leben in einem Shared-Services-Account.
• „Welche Guardrails sind nicht verhandelbar?” — Angenommen: keine öffentlichen S3-Buckets, Verschlüsselung at rest Pflicht, keine Root-Access-Keys, Region-Lock auf eu-central-1.
• „Bestand oder Greenfield?” — Angenommen: Greenfield, aber ein Legacy-Account mit Daten wird migriert. Das beeinflusst den Rollout.

Fasse zusammen: „AWS Organizations mit Management-, Shared-Services- und Workload-Accounts, EKS pro Umgebung, Terraform für alles, Okta-SSO, SCPs als Guardrails — einverstanden?”

Architektur: Accounts, Netzwerk, Identity

Account-Struktur. AWS Organizations als Wurzel. Management Account nur für Billing, Organizations, SCPs — keine Workloads. Organizational Units (OUs): Security, Infrastructure, Workloads (mit Sub-OUs prod/staging/dev). Shared Services Account: ECR, Route53 Hosted Zones, zentrales Monitoring, Vault, CI. Workload Accounts: pro Team oder Team-Gruppe, je nach Blast-Radius-Wunsch — 30 Teams ergeben eher 10–15 Accounts (Teams teilen staging), nicht 30.

Account Vending. Terraform-Modul modules/aws-account: Input Team-Name, OU, Tags → erzeugt Account via Organizations API, hängt Default-VPC ab, aktiviert CloudTrail, setzt SCP, provisioniert EKS-Cluster-Grundgerüst (VPC, Subnets, IAM-Rollen). Auslöser: Pull Request im Platform-Git-Repo oder Backstage-Template. Jeder neue Account ist in unter 30 Minuten einsatzbereit — reproduzierbar, auditierbar.

Netzwerk — Hub-Spoke. Transit Gateway im Shared-Services-Account als Hub. Jeder Workload-Account ist Spoke mit eigenem VPC, verbunden über TGW. Zentrale Ausgänge (NAT, Firewall) im Hub — Teams kontrollieren nicht selbst das Internet-Gateway. AWS Network Firewall oder VPC-Endpoints für AWS-Services, damit Traffic nicht über das öffentliche Internet läuft.

Identity. Okta → AWS IAM Identity Center (SSO): Gruppen mappen auf Permission Sets. Platform Engineers: AdministratorAccess im Management (mit MFA und Break-Glass). App Teams: PowerUser oder custom Policy im eigenen Workload-Account. Keine IAM-User mit Access Keys — nur SSO.

Guardrails — Defense in Depth. Service Control Policies (SCPs) auf OU-Ebene: Deny unencrypted S3, Deny public S3 ACLs, Deny root user actions, Deny regions outside eu-central-1. Darunter Kyverno/Gatekeeper im EKS-Cluster für Workload-Policies. SCPs fangen an der API-Grenze, Kubernetes-Policies im Cluster — zwei Schichten, ein Ziel.

Einwände des Interviewers

„Control Tower oder Custom Landing Zone?” Control Tower ist schneller am Start, aber weniger flexibel und teurer. Mit fünf erfahrenen Platform Engineers und Terraform-Kompetenz: Custom Landing Zone, weil Account Vending und Netzwerk exakt auf eure OU-Struktur passen müssen. Control Tower als Referenzarchitektur, nicht als Zwangsjacke.

„30 Teams, 5 Platform Engineers — wie skaliert das?” Account Vending und Golden Paths eliminieren manuelle Arbeit. Teams deployen selbst in ihren Accounts. Platform betreibt nur Hub, Shared Services und die Vending-Pipeline. Metrik: Time-to-New-Account < 1 Tag ohne Platform-Ticket.

„Ein Team will RDS in einer anderen Region.” SCP blockt es. Ausnahme über dokumentierten SCP-Override mit Ablaufdatum — oder Team akzeptiert eu-central-1. Konsistenz schlägt Flexibilität, außer regulatorisch begründet.

„Terraform State für 15 Accounts — wo?” Remote State in S3 im Management Account, DynamoDB Lock, OIDC-Federation von GitHub Actions — kein langlebiger Access Key im CI.

Praxis

Spiele den Case 45 Minuten am Whiteboard. Diese fünf Punkte müssen vorkommen:

1. Account-Struktur mit Management, Shared Services, Workload-OUs — begründet, warum nicht ein Account.
2. Account-Vending-Flow: Portal/PR → Terraform → fertiger Account mit Guardrails.
3. Hub-Spoke mit Transit Gateway und zentralem Egress.
4. Okta-SSO mit Permission Sets, keine IAM-User.
5. SCPs plus Kubernetes-Policies als Defense in Depth.

Variiere: „Ein Workload-Account wurde kompromittiert — was ist der Blast Radius?”

Typische Stolperfallen

Alles in einen Account packen. Spart kurzfristig Komplexität, zerstört Blast-Radius-Trennung und SOC2-Nachweise.

Landing Zone als einmaliges Projekt. Ohne Vending-Pipeline und OU-Governance driftet die Struktur innerhalb von sechs Monaten.

SCPs ohne Test. Ein zu aggressives SCP (Deny all S3) legt die gesamte OU lahm. SCPs zuerst im Audit-Modus (CloudTrail-Analyse), dann enforce.

Netzwerk vergessen. Viele Kandidaten zeichnen Accounts, aber kein TGW — dann hat jedes Team eigenes NAT und eigene Firewall-Regeln.

Interview-Vorbereitung

Deine Kernbotschaft: AWS Organizations mit OU-Struktur, Account Vending per Terraform, Hub-Spoke-Netzwerk, Okta-SSO, SCPs als Cloud-Guardrails plus Kyverno im Cluster — Landing Zone als wiederholbarer Prozess, nicht als Einmal-Setup.

Rechne mit diesen Follow-ups:

• „Wer besitzt die Landing Zone vs. Workloads?” — Platform Team: Accounts, Netzwerk, Guardrails. App Teams: Workloads in ihren Accounts innerhalb der Guardrails.
• „Wie onboarded ein neues Team?” — Backstage-Template → PR → Terraform vendet Account → EKS-Cluster provisioniert → Team bekommt SSO-Zugang.
• „GCP statt AWS?” — Gleiche Konzepte: Organization, Folders, Shared VPC, Organization Policies ≈ SCPs. Prinzipien bleiben.

Zusammenfassung

Der Landing-Zone-Case prüft Organisations-Denken: Account-Trennung für Blast Radius, Account Vending für Skalierung, Hub-Spoke für zentrale Kontrolle, SCPs plus Cluster-Policies für Defense in Depth, SSO statt Access Keys. Fünf Platform Engineers skalieren über Automatisierung, nicht über Heldentum. In der nächsten Lektion kehrst du in den Cluster zurück: Ein Team monopolisiert 70 % der Ressourcen — du designst Fairness-Mechanismen ohne dedizierte Cluster.