---
title: "Was wirklich in eine Landing Zone gehört — und was ohne Grund hineingeschoben wird"
description: "Eine Landing Zone ist keine Liste von Diensten, sondern die Menge der Entscheidungen, die sich später nicht mehr zurücknehmen lassen. Azure, AWS und Google beschreiben ihre mit unterschiedlichen Worten und landen beim selben Kern — alles andere lässt sich ergänzen, wenn der erste Workload längst läuft."
author: Aleksei Aleinikov
date: 2026-08-25
lang: de
tags: [landing-zone, azure-landing-zone, aws-landing-zone, cloud-landing-zone, gcp-landing-zone, aws-control-tower, cloud-adoption-framework]
canonical: https://www.alekseialeinikov.com/de/blog/topics/cloud/was-gehoert-in-eine-cloud-landing-zone-2026
source: alekseialeinikov.com
---
# Was wirklich in eine Landing Zone gehört — und was ohne Grund hineingeschoben wird
Fragen Sie fünf Ingenieure, was eine Landing Zone ist, und Sie bekommen fünf Inventarlisten. Eine enthält die CI/CD-Pipeline. Eine den Monitoring-Stack. Eine besteht darauf, dass nichts fertig ist, solange die FinOps-Dashboards nicht laufen.
Die Anbieter helfen wenig weiter. Azure dokumentiert acht Design-Bereiche, Google nennt vier Kernelemente, und AWS definiert den Begriff in einem einzigen Satz, der das Netzwerk komplett auslässt.
Alle beschreiben etwas Reales. Nur nicht dasselbe.
Die brauchbare Definition ist keine Komponentenliste, sondern diese: **Eine Landing Zone ist die Menge der Entscheidungen, die Sie nicht mehr zurücknehmen können, sobald Workloads darauf laufen.** Alles andere ist ein Roadmap-Punkt, der zum Blocker befördert wurde.
## Azure, AWS und Google Landing Zones sind sich beim Kern einig
Das interessante Indiz: Unabhängig entstandene Frameworks mit unterschiedlicher Terminologie und unterschiedlichen Produkten kommen inhaltlich am selben Punkt heraus.
**Google** nennt vier Kernelemente, die für eine Landing Zone entworfen werden müssen: Identitätsbereitstellung, Ressourcenhierarchie, Netzwerk und Sicherheitskontrollen.
**Microsofts Cloud Adoption Framework** teilt Azure Landing Zones in acht Design-Bereiche in zwei Gruppen. Umgebungsbereiche: Azure-Abrechnung und Tenant, Identitäts- und Zugriffsverwaltung, Ressourcenorganisation, Netzwerktopologie und Konnektivität. Compliance-Bereiche: Sicherheit, Management, Governance sowie Plattformautomatisierung und DevOps.
**AWS** definiert eine Landing Zone als gut architektierte Multi-Account-Umgebung auf Basis von Sicherheits- und Compliance-Best-Practices — als unternehmensweiten Container für Ihre Organisationseinheiten, Konten, Benutzer und weiteren Ressourcen.
Acht gegen vier gegen einen Satz sieht nach Uneinigkeit aus. Stellt man sie nebeneinander, ist es keine:
| Substanz | Google | Microsoft | AWS |
| --- | --- | --- | --- |
| Wer Sie sind | Identitätsbereitstellung | Identitäts- und Zugriffsverwaltung | IAM-Identity-Center-Verzeichnis |
| Wie Ressourcen angeordnet sind | Ressourcenhierarchie | Ressourcenorganisation | Organizations-OUs, Account Factory |
| Wie Pakete fließen | Netzwerk | Netzwerktopologie und Konnektivität | *nicht Teil der Definition* |
| Was erzwungen wird | Sicherheitskontrollen | Sicherheit, Governance | Controls: preventive, detective, proactive |
| Wie es ausgerollt wird | (Best Practice: IaC + GitOps) | Plattformautomatisierung und DevOps | Account Factory, CloudFormation StackSets |
| Wie es betrieben wird | (zusätzliches Element) | Management | Dashboard, Drift-Erkennung |
| Kaufmännischer Rahmen | (Voraussetzung: Organisation + Abrechnungskonto) | Abrechnung und Tenant | Management-Konto, Organizations |
Microsoft erhebt zu erstklassigen Bereichen, was Google unter Voraussetzungen und Best Practices ablegt. Das ist eine Dokumentationsentscheidung, keine architektonische Meinungsverschiedenheit.
AWS ist der wirklich abweichende Fall, und der lohnt einen Moment.
## Die AWS Landing Zone hat einen anderen Zuschnitt
AWS fasst den Begriff enger als die beiden anderen. Eine Control-Tower-Landing-Zone liefert Ihnen einen Root, eine Security-OU mit den Konten Log Archive und Audit, optional eine Sandbox-OU, ein IAM-Identity-Center-Verzeichnis und einen Satz Controls, die organisationsweit greifen. Das Netzwerk steht nicht auf dieser Liste. Kein Adressplan, kein Konnektivitätsdesign, kein Segmentierungsmodell — das bleibt Ihre Aufgabe und läuft separat.
Diese Asymmetrie hat eine praktische Folge: **Eine zwischen Clouds kopierte Landing-Zone-Checkliste führt in die Irre.** Wer als Azure-Architekt einem AWS-Team „die Landing-Zone-Anforderungen" übergibt, überspezifiziert Konten und unterspezifiziert VPCs. Umgekehrt gilt dasselbe.
Der zweite Unterschied ist die Zeitangabe. AWS nennt für Control Tower weniger als eine Stunde. Google sagt, Entwurf und Bereitstellung könnten mehrere Wochen dauern. Beides stimmt, weil Verschiedenes gemessen wird: Control Tower *rollt eine fertige Meinung aus*, während Googles Leitfaden *den Prozess beschreibt, sich eine eigene zu bilden*. Passt die Meinung von AWS zu Ihrer Organisation, haben Sie den teuren Teil legitim übersprungen. Passt sie nicht, ist die eingesparte Stunde nicht die relevante Zahl.
Und Tempo kauft keine Umkehrbarkeit. Die AWS-Dokumentation ist da erfreulich direkt:
> these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch
Eine Entscheidung über Namen und Einbindung der geteilten Konten, getroffen in der ersten Stunde, mit der Sie dauerhaft leben. Dem Umkehrbarkeitstest ist gleichgültig, wie schnell das Deployment war.
Vier Entscheidungen, die man einmal trifft, und eine Schicht, die man jahrelang ergänzt.
## Es gibt keine Standard-Landing-Zone, und Google sagt das selbst
Bevor Sie irgendeine Landing-Zone-Checkliste übernehmen, lesen Sie diesen Satz aus Googles Architecture Center:
> The diagram above is only an example, because there is no single or standard implementation of a landing zone.
Das Design hängt ab von Branche, Organisationsstruktur, Sicherheits- und Compliance-Anforderungen, den zu migrierenden Workloads, der vorhandenen Infrastruktur sowie dem Standort von Unternehmen und Kunden.
Das ist auch kaufmännisch relevant. Wenn ein Partner oder ein Blogbeitrag *die* Landing Zone als festes Lieferobjekt präsentiert, verkauft man Ihnen eine Meinung mit Preisschild. Manchmal ist diese Meinung ausgezeichnet und der Kauf richtig. Aber Sie sollten wissen, dass Sie eine Meinung kaufen und keine Spezifikation.
## Der eigentliche Test: Lässt sich das später ändern?
Hier ist der Filter, der die Diskussion sortiert. Fragen Sie zu jedem Kandidaten: **Was kostet die Korrektur, wenn Workloads bereits laufen?**
### Besteht den Test nicht — vor dem ersten Workload entscheiden
**Ressourcenhierarchie.** Ihre Struktur aus Organisation, Ordnern und Projekten bestimmt, wo Richtlinien greifen und wo Budgets zusammenlaufen. Projekte zwischen Ordnern zu verschieben ist möglich; eine Hierarchie unter laufenden Workloads neu zu bauen, während IAM und Organisationsrichtlinien daraus erben, ist ein Projekt, für das sich niemand meldet.
**Netz-Adressraum.** Die CIDR-Vergabe ist die klassische unumkehrbare Entscheidung. Überlappende Bereiche tauchen Jahre später auf, bei einer Übernahme oder einer Partneranbindung, und die Korrektur heißt Umadressierung der Produktion. Planen Sie auch für Regionen, die Sie noch nicht eröffnet haben.
**Identitätsdomäne und Föderation.** Welches Verzeichnis maßgeblich ist, wie es synchronisiert, wie der Vertrauenspfad aussieht. Alles Weitere in Ihrem Sicherheitsmodell erbt daraus.
**Sicherheitsgrenzen.** Wo die Grenzen tatsächlich verlaufen — VPC-Service-Controls-Perimeter in Googles Beispielarchitektur, Netzsegmentierung, der Zuschnitt Ihrer Shared VPC. Sie bestimmen, was später überhaupt ausdrückbar ist.
### Besteht den Test — ergänzen, wenn nötig
Google listet diese ausdrücklich als Elemente jenseits des Kerns, zu ergänzen nach Geschäftsanforderung:
- Monitoring und Logging
- Backup und Disaster Recovery
- Compliance-Werkzeuge
- Kosteneffizienz und -kontrolle
- API-Management
- Cluster-Management
Keines davon zwingt Sie, irgendetwas neu zu bauen. Sie werden die meisten wollen, einige dringend. Das ist eine andere Aussage als „das Fundament ist ohne sie nicht fertig".
## Der am häufigsten überdimensionierte Punkt jedes Fundamentprojekts
Dieser Punkt verdient einen eigenen Abschnitt, weil Googles Dokumentation etwas sagt, das die meisten Fundamentprojekte nicht glauben wollen:
> if your first workload does not require access to on-premises network resources, you could build connectivity to your on-premises environment later.
Hybride Konnektivität — Interconnect, Direct Connect, ExpressRoute, der VPN-Rückfall, das Routing-Design, die Firewall-Change-Requests, die Warteschlange des Netzwerkteams — ist regelmäßig der längste Balken im Plan. Und sie ist für den ersten Workload häufig unnötig, weil dieser oft ein neuer, cloud-nativer, internetseitiger Dienst ist, der mit nichts im Rechenzentrum spricht.
Sie nach dem ersten Deployment einzuplanen macht sie nicht optional. Es macht sie parallel statt blockierend.
Die Reihenfolge zählt mehr als die Inventarliste. Am falschen Punkt zu blockieren kostet Monate.
## Modular heißt: Die erste Version ist absichtlich falsch
Googles Empfehlung enthält ein Eingeständnis, das zitiert gehört, weil es dem üblichen Projektzuschnitt widerspricht:
> because a landing zone is modular, your first iteration of a landing zone is often not your final version.
Und die praktische Anweisung dazu: das Anfangsdesign auf die Elemente ausrichten, die für die Migration der ersten Workloads nötig sind, und weitere Elemente später ergänzen.
Vergleichen Sie das mit dem typischen Fundamentprogramm, das vollständig sein will, bevor irgendetwas läuft. Diese Programme überziehen — Google merkt an, die Bereitstellung könne „mehrere Wochen" dauern und Projektmanagement sei unerlässlich, was in Dokumentationssprache *das verschiebt sich* heißt — und liegen am Ende trotzdem daneben, weil jede Anforderung darin ohne echten Workload erraten wurde.
Teams, die das gut machen, liefern ein bewusst unvollständiges Fundament, setzen einen echten Workload darauf und lassen diesen Workload sagen, was die zweite Iteration braucht.
## Wenn eine Landing Zone nicht reicht
Gut zu wissen, bevor Sie ein einziges Design für einen sperrigen Workload verbiegen: Google unterstützt ausdrücklich **mehr als eine Landing Zone**, wenn einzelne Workloads sehr abweichende Skalierungs- oder Compliance-Anforderungen haben.
Teilbar: Identitäten, Abrechnung, Organisationsressource.
Typischerweise unterschiedlich: Netzwerkaufbau, Deployment-Mechanismen, Richtlinien auf Ordnerebene.
Wenn ein regulierter Workload das gesamte Design verformt, ist eine zweite Landing Zone womöglich günstiger als der Kompromiss. Sie kostet dauerhaft — also treffen Sie die Entscheidung bewusst.
## Was tatsächlich schiefgeht
Muster, die es zu benennen lohnt, weil sie Quartale kosten und nicht Sprints:
- **Auf hybride Konnektivität warten**, die der erste Workload gar nicht nutzt. Der häufigste Terminkiller.
- **Adressplanung verschieben**, weil „wir starten ja nur in einer Region". Die Rechnung kommt bei der Übernahme, der Partneranbindung oder der zweiten Region.
- **Die Pipeline für das Fundament halten.** IaC und GitOps sind eine technische Best Practice für den Rollout der Landing Zone — wirklich wichtig, aber nicht dasselbe wie eine unumkehrbare Entscheidung.
- **Für erdachte Workloads bauen.** Ohne echten Dienst erratene Anforderungen sind Vermutungen mit einem Terraform-Modul daran.
- **Eine Landing-Zone-Checkliste zwischen Clouds kopieren.** Azure und Google zählen das Netzwerk zum Kern, AWS lässt es aus der Definition heraus. Ein zwischen Anbietern portiertes Anforderungsdokument überspezifiziert die eine Hälfte und lässt die andere still unter den Tisch fallen.
- **„Wir wollen das" mit „ohne das können wir nicht starten" verwechseln.** Monitoring ist essenziell. Und an einem Dienstag ergänzbar.
- **Das falsche Team.** Googles Empfehlung verlangt Sicherheit, Identität, Netzwerk und Betrieb in einem Raum, mit einer Leitung, die die Plattform kennt. Eine nur vom Netzwerkteam entworfene Landing Zone sieht auch genau so aus.
## Landing-Zone-Checkliste: acht Fragen vor dem Bau
1. Schreiben Sie Ihre vier auf: Identitätsquelle, Ressourcenhierarchie, Adressplan, Sicherheitsgrenzen. Fehlt eine, haben Sie noch kein Fundament.
2. Fragen Sie zu jedem weiteren Element, was es kostet, es in sechs Monaten zu ergänzen. Lautet die Antwort „wenig", gehört es vom kritischen Pfad.
3. Prüfen Sie, ob Ihr erster Workload wirklich Zugriff aufs Rechenzentrum braucht. Wenn nicht, entkoppeln Sie das Konnektivitätsprojekt.
4. Planen Sie Adressraum für Regionen, die noch nicht offen sind. Jetzt kostenlos, später teuer.
5. Auf AWS: Entscheiden Sie Namen und Einbindung der geteilten Konten vor dem Start — das ist dokumentiert dauerhaft — und planen Sie das Netzwerk separat, denn Control Tower nimmt Ihnen das nicht ab.
6. Rollen Sie es als Code mit Pipeline aus — Googles eigene Best Practice — aber lassen Sie den Pipeline-Bau nicht zum Fundamentprojekt werden.
7. Wählen Sie einen echten ersten Workload, bevor das Design fertig ist. Er findet die Lücken, die Ihr Dokument nicht kennt.
8. Verformt ein Workload alles, kalkulieren Sie stattdessen eine zweite Landing Zone.
## Der Punkt
Eine Landing Zone ist kein Produkt, keine Checkliste und kein Partnerprojekt. Googles Dokumentation sagt unmissverständlich, dass es keine standardisierte Umsetzung gibt und die erste Version nicht die letzte sein soll. AWS baut Ihnen eine in einer Stunde — und händigt Ihnen dabei Entscheidungen aus, die es selbst als dauerhaft bezeichnet.
Was sie tatsächlich ist: vier Entscheidungen, deren Rücknahme teuer ist, plus eine modulare Schicht, die Sie erweitern, solange die Plattform existiert. Ihre Anforderungen in diese beiden Töpfe zu sortieren, ist der größte Teil der Architekturarbeit — und die Projekte, die scheitern, sind fast immer die, die etwas Aufschiebbares auf den kritischen Pfad und etwas Dauerhaftes ins Backlog gelegt haben.
---
**Weiterlesen:** Für die Schicht darüber siehe [Platform Engineering auf Kubernetes](https://www.alekseialeinikov.com/de/blog/topics/devops/platform-engineering-auf-kubernetes-2026) und die [Secure-by-Default-GKE-Referenzarchitektur](https://www.alekseialeinikov.com/de/blog/topics/architecture/secure-by-default-gke-referenzarchitektur-2026). Zur Identitätsentscheidung in der Praxis siehe [Service-Account-Schlüssel abschaffen](https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-workload-identity-federation-2026). Zum Resilienz-Element siehe [Backups sind kein Disaster Recovery](https://www.alekseialeinikov.com/de/blog/topics/cloud/backups-sind-kein-disaster-recovery-2026).
**Quellen:** [Landing zone design in Google Cloud](https://docs.cloud.google.com/architecture/landing-zones) (zuletzt geprüft am 2. Januar 2026), [Azure landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas) (Cloud Adoption Framework, aktualisiert Dezember 2025) sowie [What is AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) und [How AWS Control Tower works](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html).
