Landing Zones und Cloud Foundation Design

Lernziele

Nach dieser Lektion kannst du erklären, was eine Landing Zone ist und warum sie vor dem ersten Cluster existieren muss: Account-Struktur, Netzwerk-Topologie, Identity, zentrales Audit-Logging und organisationsweite Guardrails. Du kannst die gängigen Account-Strategien gegeneinander abwägen und im Interview sauber trennen, welche Leitplanken auf Cloud-Ebene gehören und welche auf Kubernetes-Ebene.

Das Problem: die gewachsene Wildwest-Cloud

So beginnen viele Cloud-Geschichten: Ein Team braucht 2019 „mal schnell” einen AWS-Account, die Kreditkarte des Abteilungsleiters hinterlegt. Drei Jahre später existieren vierzig Accounts, von denen niemand eine vollständige Liste hat. IAM-Benutzer mit Admin-Rechten und ohne MFA, Access Keys in alten Repos, Security Groups offen für die Welt, keine zentrale Kostenzuordnung — und als der Auditor fragt, wer wann was in Produktion geändert hat, ist die Antwort ein Achselzucken, weil Audit-Logs nie zentral gesammelt wurden.

Das Tückische: Jede einzelne Entscheidung war damals bequem. Cloud-Fehlkonfiguration entsteht nicht durch große Fehler, sondern durch hundert kleine Defaults. Eine Landing Zone ist die Gegenmaßnahme — die vorbereitete, standardisierte Cloud-Umgebung, in der neue Workloads „landen”: mit fertiger Account-Struktur, Netzwerk-Baseline, Identity-Anbindung, zentralem Logging und Guardrails, die die schlimmsten Fehler strukturell unmöglich machen. Für die IDP aus Lektion 8 ist sie die Schicht L0 — alles darüber erbt ihre Qualität oder ihre Schwächen.

Baustein 1: Account-Struktur als Isolationsgrenze

Der Account (AWS) bzw. die Subscription (Azure) oder das Projekt (GCP) ist die härteste Isolationsgrenze, die die Cloud bietet: eigene IAM-Welt, eigene Quotas, eigene Rechnung, harter Blast Radius. Landing Zones organisieren viele Accounts in einer Hierarchie — bei AWS über Organizations mit Organizational Units (OUs):

Organization Root
├── Security OU
│   ├── Log-Archive-Account     (unveränderliche Audit-Logs)
│   └── Audit-Account           (Security-Tooling, Lesezugriff überall)
├── Infrastructure OU
│   ├── Network-Account         (zentrales Netzwerk, Hub)
│   └── Shared-Services-Account (DNS, Registry, CI-Runner)
└── Workloads OU
    ├── team-checkout-prod
    ├── team-checkout-nonprod
    └── …

Zwei Prinzipien stecken dahinter: Trennung von Pflichten (die Logs liegen in einem Account, in dem Workload-Admins nichts löschen können) und Vererbung (Regeln, die an einer OU hängen, gelten automatisch für alle Accounts darunter).

Für den Workload-Teil gibt es drei Grundstrategien, jede mit ehrlichem Preis: Accounts pro Team und Umgebung (stärkste Isolation, klare Kostenzuordnung — aber hunderte Accounts, die nur mit vollautomatischem Account-Vending beherrschbar sind), Accounts pro Umgebung (wenige Accounts, einfacher Betrieb — aber Teams teilen sich Quotas und Blast Radius), ein gemeinsamer Account (nur für sehr kleine Organisationen vertretbar). Der Branchentrend geht klar zu vielen kleinen Accounts plus Automatisierung — die Isolationsgrenze des Providers ist zuverlässiger als jede selbstgebaute.

Baustein 2: Netzwerk und Identity als Baseline

Netzwerk: Das verbreitete Muster ist Hub-and-Spoke — ein zentrales Netzwerk (Hub) im Network-Account hält die teuren, geteilten Komponenten (Internet-Übergänge, VPN/Direct Connect ins Firmennetz, zentrale Firewall, DNS), die Workload-Netze (Spokes) der Accounts hängen daran. Der Vorteil: Egress und Ingress passieren kontrollierte Punkte, IP-Adressräume werden zentral geplant (Überlappungen rächen sich Jahre später beim Peering), und ein neues Workload-Netz ist ein Standardvorgang statt einer Design-Diskussion. Der Preis: Der Hub ist ein kritischer Single Point — er verdient die meiste Sorgfalt und klare Kapazitätsplanung.

Identity: Menschen bekommen Zugang über die Anbindung des zentralen Identity Providers (SSO) mit kurzlebigen Rollen statt dauerhafter Benutzer — der IAM-User mit Access Key im Repo ist das Anti-Pattern, das Landing Zones beerdigen. Genauso wichtig: Workloads bekommen Identität ohne gespeicherte Credentials, etwa über die Kopplung von Kubernetes-ServiceAccounts an Cloud-Rollen (bei AWS als IRSA bekannt, bei Azure und GCP als Workload Identity). Damit verschwinden statische Cloud-Schlüssel aus Clustern und Pipelines.

Audit: Alle API-Aufrufe aller Accounts (CloudTrail bzw. Pendants) fließen unveränderlich in den Log-Archive-Account. Das ist unspektakulär — bis zum ersten Sicherheitsvorfall oder Audit, wo es über Stunden oder Wochen Aufklärungsarbeit entscheidet.

Baustein 3: Guardrails — und auf welcher Ebene sie gehören

Landing Zones erzwingen Regeln präventiv auf Organisationsebene: bei AWS über Service Control Policies (SCPs), bei Azure über Azure Policy. SCPs sind keine Rechtevergabe, sondern eine Obergrenze — was die SCP verbietet, kann selbst der Account-Admin nicht tun. Klassische Beispiele: Regionen außerhalb der EU blockieren (Data Residency), das Deaktivieren von Audit-Logging verbieten, das Verlassen der Organization verbieten, bestimmte teure oder ungeprüfte Services sperren.

Für Interviews wichtig ist die Ebenen-Trennung, weil sie zeigt, dass du das Gesamtsystem verstehst:

• Cloud-Ebene (SCP/Policy): alles, was niemals und für niemanden gehen darf — Regionen, Audit-Schutz, Identitäts-Grundregeln. Grobkörnig, dafür unumgehbar.
• Kubernetes-Ebene (Admission Policies, Lektion 8): workload-nahe Regeln — Image-Herkunft, Ressourcen-Limits, Privilegien. Feinkörnig und schnell anpassbar.

Faustregel: so tief wie nötig, so hoch wie möglich. Eine Regel, die auf Cloud-Ebene durchsetzbar ist, gehört dorthin — sie gilt dann auch für alles, was nicht in Kubernetes läuft.

Praktisch baut man Landing Zones heute nicht von Hand: AWS Control Tower, Azure Landing Zones oder Terraform-basierte Frameworks liefern das Gerüst; die eigentliche Arbeit ist die Anpassung an die eigene Organisation — und das Account-Vending: der automatisierte Prozess, der neue Accounts fertig verdrahtet (Netzwerk, SSO, Logging, Baseline) in Minuten bereitstellt. Ohne Vending wird die schönste Struktur zum Ticket-Flaschenhals.

Praxis: eine Landing Zone auf Papier entwerfen

Szenario: Ein Versicherungs-Startup, 12 Entwicklungsteams, AWS, Kundendaten müssen in der EU bleiben, ein Plattform-Team entsteht gerade.

1. OU-Hierarchie: Skizziere den Organization-Baum mit Security-, Infrastructure- und Workloads-OU. Entscheide dich für eine Account-Strategie im Workload-Teil und begründe sie in zwei Sätzen gegen eine Alternative.
2. Drei SCP-Guardrails: Formuliere drei Regeln in Prosa, jeweils mit dem Schaden, den sie verhindern — z. B. „Deny aller Aktionen außerhalb von eu-central-1 und eu-west-1, verhindert Data-Residency-Verstöße durch versehentliche Ressourcen in US-Regionen.”
3. Ebenen-Zuordnung: Ordne diese fünf Regeln der richtigen Ebene zu (SCP oder K8s-Admission): EU-Regionen erzwingen / keine privilegierten Container / Audit-Logging unabschaltbar / Images nur aus der Haus-Registry / keine IAM-User mit Access Keys.
4. Vending-Skizze: Liste die acht bis zehn Dinge, die dein Account-Vending bei jedem neuen Account automatisch einrichten muss, damit er „landefertig” ist.

(Kontrolle zu Schritt 3: EU-Regionen, Audit-Schutz und IAM-User-Verbot → SCP; Container-Privilegien und Image-Herkunft → K8s-Admission.)

Typische Stolperfallen

Cluster vor Foundation. Wer zuerst Kubernetes baut und die Landing Zone „später nachzieht”, migriert später laufende Produktion über Account- und Netzwerkgrenzen — eine der teuersten nachholbaren Entscheidungen überhaupt.

IP-Adressplanung aufschieben. Überlappende Netzbereiche fallen erst auf, wenn zwei Netze verbunden werden müssen — dann sind sie nur noch mit Umbauten zu beheben. Adressräume gehören von Anfang an zentral vergeben.

Guardrails als Genehmigungsprozess missverstehen. Eine Landing Zone, in der jeder neue Account ein vierwöchiger Antragsprozess ist, reproduziert das Ticket-Modell auf Cloud-Ebene. Präventive Policies plus automatisches Vending — nicht Formulare.

Die Security-Accounts vernachlässigen. Log-Archive und Audit-Account wirken wie Bürokratie, bis zum ersten Incident. Unveränderlichkeit (kein Löschrecht für Workload-Admins) ist dabei der Punkt, nicht das Sammeln selbst.

Interview-Vorbereitung

Auf „Was ist eine Landing Zone und warum braucht eine Plattform sie?” antwortest du am stärksten so: Problem (gewachsene Wildwest-Cloud: kein Überblick, kein Audit, offene Defaults) → Definition (standardisierte Multi-Account-Umgebung mit Netzwerk-, Identity-, Logging-Baseline und präventiven Guardrails) → Kernbausteine (OU-Hierarchie mit Security/Infrastructure/Workloads, Hub-and-Spoke, SSO plus Workload Identity, SCPs) → Bezug zur IDP (Schicht L0 — alles darüber erbt ihre Qualität).

Rechne mit diesen Follow-ups:

• „Account pro Team oder geteilte Accounts?” — Trend zu vielen kleinen Accounts wegen harter Isolation und Kostenzuordnung; Bedingung ist automatisiertes Vending, sonst Ticket-Hölle.
• „Was gehört in eine SCP, was in eine Kubernetes-Policy?” — SCP: das Unverhandelbare auf Org-Ebene (Regionen, Audit-Schutz, Identitätsregeln); K8s: workload-nahe, feinkörnige Regeln. So hoch wie möglich, so tief wie nötig.
• „Wie bekommen Workloads Cloud-Zugriff ohne gespeicherte Keys?” — Kopplung von ServiceAccounts an Cloud-Rollen (IRSA/Workload Identity): kurzlebige Credentials statt statischer Schlüssel.
• „Bestehende Wildwest-Cloud — wie migrierst du?” — Nicht big bang: Landing Zone parallel aufbauen, neue Workloads nur noch dort, Bestand priorisiert nach Risiko nachziehen.

Zusammenfassung

Eine Landing Zone ist das Cloud-Fundament der Plattform: eine Multi-Account-Struktur mit OU-Hierarchie und Pflichten-Trennung, Hub-and-Spoke-Netzwerk mit zentral geplanten Adressräumen, SSO und Workload Identity statt statischer Credentials, unveränderlichem zentralem Audit-Logging und präventiven Guardrails (SCPs) für das Unverhandelbare. Beherrschbar wird das Ganze erst durch automatisiertes Account-Vending — sonst entsteht das Ticket-Modell von vorn.

Auf diesem Fundament stellt sich die nächste Skalierungsfrage: Wie viele Cluster, wie geschnitten, über welche Regionen? Das ist das Thema der nächsten Lektion.