Am Anfang wirkt alles unproblematisch: ein paar AWS-Accounts, einige IAM-User, vielleicht eine geteilte VPC. Doch sobald Teams wachsen, Umgebungen sich vervielfachen und Compliance-Fragen auftauchen, zeigen sich Risse. Security wird reaktiv. Kosten sind schwer zu erklären. Und Besitzverhältnisse sind plötzlich unklar.
Genau dieses Problem sollen AWS Landing Zones lösen.
Dieser Beitrag führt durch die wichtigsten AWS-Landing-Zone-Referenzarchitekturen, erklärt, wann welches Modell sinnvoll ist, und nutzt Praxis-Szenarien, damit der richtige Einstieg klar wird — nicht nur die „enterprise-lastigste“ Option.
Was ist eine AWS Landing Zone?
Eine AWS Landing Zone ist eine gut entworfene Multi-Account-AWS-Umgebung, die Wachstum, Security und Governance von Tag 1 an unterstützt.
Statt alles in einen einzigen AWS-Account zu packen, nutzt eine Landing Zone mehrere Accounts, organisiert unter AWS Organizations, mit gemeinsamen Security-, Logging- und Identity-Kontrollen. So entstehen natürliche Isolationsgrenzen, während zentrale Sichtbarkeit und Kontrolle erhalten bleiben.
Eine gute Landing Zone beantwortet Fragen wie:
- Wo laufen Production-Workloads?
- Wie werden Logs und Security-Events gesammelt?
- Wie erhalten Teams Zugriff, ohne Regeln zu brechen?
- Wie lässt sich wachsen, ohne alles neu zu designen?
AWS stellt Guidance und Tools bereit — insbesondere AWS Control Tower — um diese Muster mit bewährten Defaults umzusetzen.
Kernideen hinter allen Landing Zones
Bevor es in die einzelnen Architekturen geht, hilft ein Blick auf die Prinzipien, die alle Modelle teilen.
Eine Landing Zone geht davon aus, dass nicht alle Workloads gleich sind. Produktionssysteme sollten schwerer zu beschädigen sein als Entwicklungsumgebungen. Security-Tools sollten nicht im selben Account wie Anwendungscode laufen. Logs sollten vor Manipulation geschützt sein.
Typische Bausteine dafür sind:
- Mehrere AWS-Accounts zur Reduzierung des Blast Radius
- Zentralisierte Security und Logging
- Starke Identity- und Access-Kontrollen
- Guardrails, die riskante Aktionen verhindern
Was sich zwischen Architekturen unterscheidet, ist die Gruppierung der Accounts und die Strenge der Kontrollen.
1. Basic Landing Zone: Einfach starten
Die Basic Landing Zone ist die kleinste sinnvolle Variante eines Multi-Account-Setups in AWS.
Typischerweise besteht sie aus einem Management-Account, einem oder zwei Workload-Accounts und manchmal einem Shared-Services-Account. Alle Accounts liegen in einer einfachen Organisationsstruktur mit minimalen Policies.
Dieser Ansatz funktioniert besonders gut, wenn die Organisation klein ist und Geschwindigkeit wichtiger ist als formale Governance.
Wann diese Architektur sinnvoll ist
Für Startups oder kleine Teams, die AWS strukturierter angehen, ist das oft der richtige Einstieg. Häufig gibt es nur eine Production-Anwendung und eine Non-Production-Umgebung. Compliance-Anforderungen sind überschaubar, und dieselben Engineers übernehmen Infrastruktur, Security und Deployments.
Das zentrale Ziel ist, die Single-Account-Falle zu vermeiden, ohne das Team auszubremsen.
Ein Praxisbeispiel
Beispiel: Ein Startup startet das erste SaaS-Produkt. Es gibt einen AWS-Account für Production und einen für Development und Testing. Abrechnung bleibt zentralisiert, Logging ist zunächst basic.
Damit entsteht Isolation zwischen Prod und Non-Prod bei geringem operativem Overhead.
Trade-off
Die Basic Landing Zone ist leicht zu verstehen und schnell auszurollen, skaliert aber nicht unbegrenzt. Sobald mehr Teams oder Services hinzukommen, wird Governance inkonsistent und Berechtigungen werden unübersichtlich. Es ist ein Startpunkt — kein Endzustand.
2. Environment-Based Landing Zone: Risiko trennen
Eine Environment-Based Landing Zone organisiert AWS-Accounts nach Umgebungstyp statt nach Anwendung.
In diesem Modell liegen Production-Accounts in einer „Prod“-Organizational Unit, Non-Production-Accounts in „Non-Prod“, und Shared Services sowie Security-Tooling in eigenen Bereichen.
Die Struktur ist besonders hilfreich, wenn Production deutlich strengere Kontrollen braucht als alles andere.
Wann diese Architektur sinnvoll ist
Dieser Ansatz passt gut für wachsende Organisationen, in denen mehrere Teams in gemeinsame Umgebungen deployen. Stabilität in Production ist wichtig, und es braucht klare Garantien, dass experimentelle Änderungen in Development keine Kund:innen betreffen.
Er eignet sich auch, sobald erste Compliance-Anforderungen entstehen, aber vollständige Enterprise-Governance noch Overkill wäre.
Ein Praxisbeispiel
Beispiel: Ein mittelgroßes SaaS-Unternehmen mit mehreren Teams für zusammenhängende Services. Production-Umgebungen sind stark kontrolliert: eingeschränkte Berechtigungen, striktes Monitoring. Development-Umgebungen erlauben mehr Freiheit, damit Teams schnell liefern können.
Trade-off
Das Modell ist simpel und effektiv, kann aber Teamautonomie einschränken. Änderungen in gemeinsamen Umgebungen müssen häufiger abgestimmt werden, und Anpassungen pro Produkt werden mit zunehmendem Wachstum schwieriger.
3. Workload-Based Landing Zone: Teams skalieren, nicht nur Infrastruktur
Eine Workload-Based (oder Product-Based) Landing Zone gruppiert Accounts nach Anwendung oder Produkt statt nach Umgebung.
Jedes Produkt besitzt typischerweise ein eigenes Account-Set — Development, Testing und Production — zusammengefasst in einer Einheit. Ein zentrales Platform- oder Cloud-Team liefert Guardrails, aber einzelne Teams verantworten den gesamten Lebenszyklus.
Wann diese Architektur sinnvoll ist
Dieses Modell passt besonders gut bei mehreren autonomen Teams und einer starken DevOps-Kultur. Teams deployen unabhängig, betreiben eigene Infrastruktur und sind innerhalb definierter Grenzen für Security und Kosten verantwortlich.
Es ist ein natürlicher Fit für Microservices, Platform-Unternehmen und Organisationen, die Engineering-Teams skalieren möchten, ohne neue Bottlenecks zu schaffen.
Ein Praxisbeispiel
Beispiel: Ein großes Tech-Unternehmen mit Dutzenden Services nutzt eine workload-basierte Landing Zone. Jedes Team besitzt eigene AWS-Accounts und kann im eigenen Rhythmus deployen. Kosten lassen sich klar zuordnen, Ownership ist sichtbar, und Ausfälle bleiben auf einzelne Produkte begrenzt.
Trade-off
Der Ansatz skaliert sehr gut, erfordert aber Reife. Automatisierung, standardisierte Pipelines und starke Baseline-Policies sind essenziell. Ohne diese drohen Account-Sprawl und inkonsistente Praktiken.
4. Compliance-Driven Landing Zone: Für Regulierung gebaut
Eine Compliance-Driven Landing Zone richtet sich an Organisationen mit strengen regulatorischen oder Audit-Anforderungen.
Accounts werden sorgfältig segmentiert, häufig mit Trennung regulierter von nicht regulierten Workloads. Security- und Audit-Accounts sind stark eingeschränkt, und Service Control Policies begrenzen strikt, was Workloads tun dürfen.
Wann diese Architektur sinnvoll ist
In Branchen wie Finanzen, Gesundheitswesen oder öffentlicher Verwaltung ist diese Architektur oft nicht verhandelbar. Regulatorik kann starke Separation of Duties, unveränderliche Logs und klare Audit-Trails verlangen.
Ein Praxisbeispiel
Beispiel: Eine Healthcare-Plattform verarbeitet sensible Patientendaten und nutzt eine compliance-getriebene Landing Zone. Production-Workloads mit regulierten Daten sind in streng kontrollierten Accounts isoliert. Logs fließen in dedizierte Security-Accounts, die von Anwendungsteams nicht verändert werden können. Auditor:innen erhalten Read-only-Views, ohne Live-Systeme anzufassen.
Trade-off
Compliance-getriebene Landing Zones bieten starken Schutz, erhöhen aber die Komplexität. Ohne Automatisierung kann Entwicklungsgeschwindigkeit leiden. Erfolgreiche Teams investieren stark in Tooling, damit sichere Wege die einfachen Wege sind.
5. Multi-Region Enterprise Landing Zone: Betrieb auf globaler Skala
Die Enterprise Multi-Region Landing Zone baut auf den vorherigen Modellen auf und ergänzt geografische Skalierung.
Accounts, Security-Tooling und Logging sind so entworfen, dass sie über mehrere AWS-Regionen funktionieren. Disaster Recovery, Failover und Anforderungen an Datenresidenz sind erstklassige Themen.
Wann diese Architektur sinnvoll ist
Dieses Modell passt für große Unternehmen mit globalen Nutzer:innen, strengen Uptime-Anforderungen oder regionalen Compliance-Regeln. Auf diesem Level ist Downtime teuer, und Architekturentscheidungen wirken direkt auf das Business.
Ein Praxisbeispiel
Beispiel: Eine globale Plattform betreibt Workloads in mehreren Regionen für weltweite Kundschaft. Daten werden über Regionen repliziert, Security-Monitoring ist zentralisiert, und Governance-Policies berücksichtigen regionale Unterschiede bei Regulierung und Verfügbarkeitsanforderungen.
Trade-off
Das ist das mächtigste — und komplexeste — Landing-Zone-Modell. Es braucht erfahrene Teams, disziplinierte Prozesse und eine klare Business-Begründung.
Wo AWS Control Tower hineinpasst
AWS Control Tower ist der „opinionated“ Ansatz von AWS, um Organisationen bei der Umsetzung von Landing Zones zu unterstützen.
Es automatisiert Account-Erstellung, setzt Baseline-Guardrails und richtet zentralisiertes Logging und Security ein. Für die meisten Teams ist Control Tower der schnellste Weg zu einer soliden Landing Zone.
Control Tower passt besonders gut zu Basic-, Environment-Based- und Workload-Based-Architekturen. Fortgeschrittene Enterprise-Setups erweitern es häufig mit eigener Automatisierung und Policies.
Die richtige Landing Zone auswählen
Es gibt nicht die eine „beste“ Landing Zone — sondern nur die beste für die eigene Phase und Ziele.
Eine einfache Regel funktioniert erstaunlich gut: Design für den Stand in ein bis zwei Jahren, nicht für den Stand von heute.
Zu komplex zu starten bremst Teams aus. Zu simpel zu starten und zu lange dort zu bleiben führt später zu teuren Problemen.
Abschließende Gedanken
Bei AWS Landing Zones geht es nicht um Kontrolle um der Kontrolle willen. Es geht darum, Wachstum planbar zu machen.
Eine gute Landing Zone macht Security zur Routine, schafft klares Ownership und reduziert Schmerzen beim Skalieren. Teams können schnell liefern, ohne Regeln ständig neu zu erfinden oder fundamentale Fehler zu reparieren.
Wenn die Basis stimmt, wird der Rest von AWS deutlich einfacher im Betrieb.