Landing Zone Best Practices für 2026

Multi-Account-Struktur ist nicht verhandelbar

Der Account (AWS), die Subscription (Azure) oder das Projekt (GCP) ist die stärkste Isolationsgrenze, die der Provider bietet: Blast Radius, IAM-Scope und Kostengrenze in einem. Eine tragfähige Basis: Management-, Security/Audit-, Log-Archiv- und Shared-Services-Accounts, dann getrennte Produktions- und Non-Produktions-Accounts pro Workload, organisiert in Organizational Units oder Management Groups, die abbilden, wie sich Policies unterscheiden. Das Organigramm ist dafür kein guter Bauplan.

Widerstehen Sie beiden Extremen. Ein Account 'der Einfachheit halber' ist der Tod der Governance; ein Account pro Microservice ist Betriebsaufwand ohne passende Risikogrenze.

Identität vor allem anderen

Jedes Langzeit-Credential in einer CI-Pipeline oder auf einem Laptop ist ein Breach, der auf sein Leak wartet. Menschen per SSO mit MFA in kurzlebige Sessions föderieren (IAM Identity Center, Entra ID, Google Cloud Identity), für CI/CD Workload Identity Federation (OIDC) statt gespeicherter Keys. Definieren Sie ein kleines Set von Berechtigungsrollen pro Account-Stufe statt maßgeschneiderter Policies pro Person.

Break-Glass-Zugang mit Hardware-Token-Schutz und Alarm bei Nutzung einrichten und prüfen, dass der Alarm wirklich feuert. Ein unüberwachter Break-Glass-Account ist nur eine Hintertür mit Papierkram.

Guardrails: präventiv zuerst, detektiv immer

Präventive Kontrollen (AWS SCPs, Azure-Policy-Deny-Effekte, GCP Organization Policy Constraints) verhindern ganze Fehlerklassen: Deployment außerhalb freigegebener Regionen, Abschalten des Audit-Loggings, öffentlicher Storage, Löschen des Log-Archivs. Halten Sie das präventive Set klein und nicht verhandelbar: Es definiert, was unmöglich ist, nicht, was unerwünscht ist.

Detektive Kontrollen (AWS Config, Security Hub, Azure Defender for Cloud, GCP Security Command Center) fangen den Rest. Die Praxis, die zählt: Jeder detektive Befund hat einen Verantwortlichen und einen Routing-Pfad. Ein Compliance-Dashboard, das niemand triagiert, ist Dekoration.

Netzwerk- und Logging-Defaults

Hub-and-Spoke bleibt der vernünftige Default: zentralisierter Egress und Inspektion, überschneidungsfreier IP-Raum von Anfang an geplant (nachträglich schmerzhaft), private Konnektivität zu Provider-Diensten als Standard, DNS-Auflösung zentral entschieden. Die meisten Workloads brauchen nie ein öffentliches Subnetz. Machen Sie privat zum Default und öffentlich zur Review-pflichtigen Ausnahme.

Alle Control-Plane- und Plattform-Logs - CloudTrail, Activity Logs, Audit Logs, Flow Logs wo verhältnismäßig - ins Log-Archiv-Konto senden, mit Aufbewahrung nach regulatorischen Anforderungen und Object-Lock bzw. Unveränderbarkeit aktiviert. Zentrales, manipulationssicheres Logging ist das eine Artefakt, nach dem jedes Framework von ISO 27001 bis DORA fragt.

Kosten-Governance gehört ins Fundament

Der billigste Moment, Kostenzuordnung durchzusetzen, ist die Account-Erstellung. Backen Sie das verpflichtende Tag- oder Label-Set in den Vending-Prozess, sodass kein Account ohne Verantwortlichen, Team und Kostenstelle existieren kann, und hängen Sie von Tag eins ein Default-Budget mit Alarmen an diesen Verantwortlichen. Zuordnung nachträglich über eine gewachsene Umgebung zu legen ist ein Quartal Archäologie - sie in der Landing Zone zu erzwingen ist ein Formularfeld.

Dasselbe gilt für Guardrails mit direkter Kostenwirkung: teure Instanzfamilien und Regionen in Non-Production einschränken, Lifecycle-Policies auf Storage per Default verlangen und die Ressourcentypen blockieren, die niemand manuell anlegen sollte. Nichts davon behindert einen legitimen Workload - es behindert die Unfälle.

Eine realistische Bau-Reihenfolge für die ersten 30 Tage

Landing-Zone-Projekte scheitern daran, alles entwerfen zu wollen, bevor irgendetwas gebaut wird. Eine Sequenz, die in der Praxis funktioniert:

• ✓Tage 1-5: Org-Struktur, Management- und Log-Archiv-Accounts, SSO-Föderation und Break-Glass - die irreversiblen Entscheidungen, bewusst getroffen.
• ✓Tage 6-12: Baseline-Terraform-Module (Logging, IAM-Rollen, Netzwerk-Skelett), State-Backend und CI-Pipeline für das Plattform-Repo selbst.
• ✓Tage 13-20: präventives Guardrail-Set (Regionen, öffentlicher Storage, Audit-Log-Schutz), zentrale Log-Zustellung Ende-zu-Ende verifiziert.
• ✓Tage 21-30: Account-Vending automatisiert, erster echter Workload-Account darüber erstellt, detektive Kontrollen an einen Triage-Verantwortlichen geroutet.
• ✓Nach Tag 30: Workloads in Wellen nach Kopplungsgrad migrieren; jede Welle härtet die Module für die nächste.

Alles in Terraform, Accounts eingeschlossen

Die Landing Zone selbst muss Code sein: Org-Struktur, Policies, Netzwerk, IAM-Rollen, Logging, per Pull Request reviewt, per Pipeline applied, mit Drift-Erkennung. Account-Erstellung sollte ein Vending-Prozess sein (ein Modulaufruf plus Freigabe), sodass ein neues Team in Stunden einen konformen Account mit vorapplizierten Baselines bekommt.

Zwei Muster zahlen sich aus: ein kleines Set versionierter Baseline-Module, die jeder Account konsumiert, und State-Isolation pro Account, damit ein fehlerhaftes Apply nicht die ganze Umgebung trifft. Gehört Migration auf die Landing Zone zum Auftrag: Workload-Umzüge in Wellen planen, erst Fundament, dann Workloads nach Kopplungsgrad.

FAQ