Landing Zone Design: Die Grundlage jeder Enterprise-Migration auf AWS

Warum Landing Zone Design jetzt entscheidend ist

Cloud-Migrationen scheitern selten an der eigentlichen Migration. Sie scheitern an dem, was davor hätte passieren müssen. Fehlendes Netzwerk-Design, keine Account-Isolation, kein zentrales Logging — diese Versäumnisse zeigen sich erst Monate nach dem Go-Live, wenn die ersten Workloads produktiv laufen und Compliance-Audits anstehen.

AWS selbst beziffert den Aufwand für nachträgliche Korrekturmaßnahmen als vielfach höher als den initialen Landing-Zone-Aufbau. Die AWS Prescriptive Guidance empfiehlt deshalb, den Aufbau einer Landing Zone als allerersten Schritt jeder Migration zu behandeln — noch vor dem Assessment einzelner Workloads (AWS Prescriptive Guidance).

Für DACH-Unternehmen kommt eine regulatorische Dimension hinzu: DSGVO-konforme Datenhaltung, BSI-Grundschutz-Anforderungen und die NIS2-Richtlinie erfordern eine durchdachte Account-Struktur mit klarer Trennung von Verantwortlichkeiten und durchgängiger Nachvollziehbarkeit.

Was ist eine Landing Zone?

Eine Landing Zone ist eine vorkonfigurierte, sichere Multi-Account-AWS-Umgebung, die als Startpunkt für Cloud-Workloads dient. Sie umfasst vier Kernbereiche:

Account-Struktur

Organisatorische Trennung von Workloads, Umgebungen und Verantwortlichkeiten über AWS Organizations und Organizational Units (OUs).

Identity & Access Management

Zentrales SSO (AWS IAM Identity Center), föderierter Zugriff über bestehende Verzeichnisdienste (Active Directory), rollenbasierte Berechtigungen.

Netzwerk-Design

Shared VPCs oder dedizierte VPCs pro Account, Transit Gateway für zentrale Konnektivität, DNS-Auflösung und optionale Anbindung an On-Premises via Direct Connect oder VPN.

Security & Compliance Baseline

Zentrale Logs (CloudTrail, Config), Guardrails via Service Control Policies (SCPs), automatisierte Compliance-Prüfungen und Verschlüsselung by Default.

AWS empfiehlt, Landing Zones grundsätzlich mit AWS Control Tower aufzubauen — dem verwalteten Service, der die gesamte Einrichtung automatisiert und kontinuierlich überwacht (AWS Docs: Plan your Control Tower Landing Zone).

AWS Control Tower: Das Werkzeug für den Landing-Zone-Aufbau

AWS Control Tower ist der zentrale Service für den automatisierten Aufbau und die laufende Governance einer Landing Zone. Er orchestriert mehrere AWS-Services und konfiguriert sie nach Best Practices.

Was Control Tower automatisch einrichtet

1. Management Account: Das Root-Account der Organisation mit AWS Organizations.
2. Log Archive Account: Zentraler Speicher für CloudTrail-Logs, Config-Aufzeichnungen und Access Logs — getrennt vom operativen Betrieb.
3. Audit Account: Schreibgeschützter Zugriff auf alle Accounts für Security-Teams und Compliance-Prüfungen.
4. IAM Identity Center (SSO): Föderierter Zugriff über ein zentrales Portal, integrierbar mit Active Directory.
5. Guardrails: Vorkonfigurierte Regeln — sowohl präventiv (SCPs, die bestimmte Aktionen blockieren) als auch detektiv (AWS Config Rules, die Abweichungen erkennen).
6. Account Factory: Automatisierte Bereitstellung neuer Accounts nach standardisiertem Template.

Control Tower setzt auf AWS Organizations, AWS Config, AWS CloudTrail, AWS IAM Identity Center und AWS Service Catalog auf. Es ist keine Eigenentwicklung nötig — die Grundkonfiguration steht in wenigen Stunden (AWS Control Tower Features).

Die empfohlene OU-Struktur für DACH-Unternehmen

AWS empfiehlt, Organizational Units (OUs) nach Funktion und Kontrollbedarf zu strukturieren — nicht nach Abteilungen oder Geschäftsbereichen. Die folgende Struktur hat sich in der Praxis bei DACH-Migrationen bewährt (AWS: Recommended OUs and Accounts):

AWS Prescriptive Guidance rät, die OU-Hierarchie flach zu halten — maximal zwei bis drei Ebenen. Jede zusätzliche Ebene erhöht die Komplexität bei der SCP-Vererbung und dem Troubleshooting (AWS: OU Structure Best Practices).

Guardrails und Service Control Policies

Guardrails sind Regeln, die unerwünschtes Verhalten in AWS-Accounts verhindern oder erkennen. AWS Control Tower unterscheidet drei Kategorien:

Präventive Guardrails (SCPs)

Service Control Policies (SCPs) setzen harte Grenzen, die kein IAM-User und keine IAM-Rolle umgehen kann. Typische Einsatzszenarien:

• Region-Restriction: Workloads dürfen nur in EU-Regionen (eu-central-1, eu-west-1) deployed werden — zentral für DSGVO-Konformität.
• Root-Account-Schutz: Verbot der Nutzung des Root-Users für operative Aufgaben.
• Verschlüsselungspflicht: S3-Buckets, EBS-Volumes und RDS-Instanzen müssen verschlüsselt sein.
• Logging-Schutz: CloudTrail und Config dürfen nicht deaktiviert werden.

Detektive Guardrails (Config Rules)

AWS Config Rules erkennen Abweichungen von der Baseline und melden sie an Security Hub oder per SNS-Notification. Beispiele:

• S3-Buckets mit öffentlichem Zugriff erkennen
• Security Groups mit offenen Ports (0.0.0.0/0) melden
• IAM-User ohne MFA identifizieren
• Unverschlüsselte Ressourcen flaggen

Proaktive Guardrails

Seit 2023 bietet Control Tower proaktive Controls, die CloudFormation-Templates vor dem Deployment prüfen. Nicht-konforme Ressourcen werden gar nicht erst erstellt — eine Shift-Left-Strategie für Compliance (AWS: Control Tower Update Best Practices).

Typische Fehler: Warum Migrationen ohne Landing Zone scheitern

Aus über 600 begleiteten Cloud-Projekten identifiziert Storm Reply wiederkehrende Muster, die auf eine fehlende oder unzureichende Landing Zone zurückgehen:

Muster 1: Der Single-Account-Ansatz

Alle Workloads in einem einzigen AWS-Account. Konsequenzen: keine Isolation zwischen Entwicklung und Produktion, keine granulare Kostenallokation, IAM-Policies werden unüberschaubar komplex, ein Sicherheitsvorfall betrifft alles.

Muster 2: Kein zentrales Logging von Tag 1

CloudTrail wird nicht aktiviert oder Logs werden im selben Account gespeichert. Bei einem Incident fehlen die Spuren — oder sie sind kompromittiert. Der nachträgliche Aufbau eines Log Archive Accounts erfordert die Reorganisation aller bestehenden Accounts.

Muster 3: Fehlende Netzwerk-Segregation

Alle VPCs mit überlappenden CIDR-Ranges, kein Transit Gateway, kein zentrales DNS. Spätere Integration mit On-Premises-Netzwerken (Direct Connect) wird zum architektonischen Albtraum.

Muster 4: Security als Nachgedanke

Keine SCPs, keine Region-Restriction, kein MFA-Zwang. Entwickler deployen versehentlich in us-east-1, S3-Buckets werden öffentlich, Root-Credentials sind aktiv. Die Korrektur erfordert Downtime und Reorganisation.

Diese Muster erklären, warum AWS den Landing-Zone-Aufbau als obligatorische Mobilize-Phase im Migration Acceleration Program (MAP) verankert hat.

Storm Reply Landing-Zone-Ansatz

Storm Reply ist AWS Premier Consulting Partner mit AWS Migration Competency und Cloud Operations Competency. Der Landing-Zone-Aufbau folgt einem standardisierten Vier-Phasen-Modell:

1. Discovery (1 Woche): Analyse der bestehenden IT-Landschaft, Netzwerk-Topologie, Identitätsmanagement und regulatorischer Anforderungen.
2. Design (1 Woche): OU-Struktur, Netzwerk-Architektur (Hub-and-Spoke vs. dezentral), SCP-Katalog und IAM-Konzept.
3. Implementierung (1-2 Wochen): Control Tower Setup, Account Factory Konfiguration, VPC-Design, Transit Gateway, SSO-Integration.
4. Validierung & Übergabe: Compliance-Check gegen DSGVO/BSI-Anforderungen, Dokumentation, Schulung des internen Teams.

Das Ergebnis: Eine produktionsreite Landing Zone in 2-4 Wochen, die als Grundlage für die anschließende Workload-Migration dient.

Praxisbeispiel: Audi Cloud Service

Ein exemplarisches Projekt für skaliertes Landing-Zone-Design ist der Audi Cloud Service, den Storm Reply gemeinsam mit der Audi AG umgesetzt hat.

Ausgangslage: Audi benötigte eine automatisierte Lösung zur Bereitstellung von AWS-Accounts für verschiedene Geschäftsbereiche — mit standardisierten Sicherheits- und Compliance-Vorgaben, aber flexiblen Nutzungsmöglichkeiten.

Lösung: Ein serverloses, automatisiertes Account-Provisioning-Tool, das Accounts aus einem vordefinierten Katalog bereitstellt. Jeder Account wird mit einheitlicher Security Baseline, SSO-Integration und automatisierter Governance ausgeliefert.

Ergebnis:

• 3x mehr AWS-Accounts als 2018 — skaliert durch Automatisierung
• 285 erfolgreich implementierte Projekte auf der Plattform
• 4.000+ aktive Nutzer mit zentralem Single Sign-On
• Stetiges Wachstum der AWS-Umgebung bei gleichbleibender Governance

Der Case zeigt: Eine durchdachte Landing Zone ist kein Einmal-Projekt, sondern eine Plattform, die mit dem Unternehmen wächst.

Regulatorische Anforderungen an Landing Zones im DACH-Raum

Für Unternehmen in Deutschland, Österreich und der Schweiz gelten spezifische regulatorische Anforderungen, die direkt in das Landing-Zone-Design einfließen müssen:

Storm Reply integriert diese Anforderungen direkt in den SCP-Katalog und die Config-Rule-Baseline — nicht als nachträgliches Add-on, sondern als fester Bestandteil des Landing-Zone-Designs.

Vorteile und Herausforderungen

Vorteile einer professionellen Landing Zone

• Sicherheit by Default: Guardrails verhindern Fehlkonfigurationen, bevor sie entstehen.
• Skalierbarkeit: Neue Accounts in Minuten statt Wochen — über Account Factory automatisiert.
• Compliance-Readiness: DSGVO, BSI und NIS2-Anforderungen sind strukturell verankert.
• Kostenttransparenz: Account-basierte Kostenallokation ermöglicht granulares FinOps.
• Geringeres Migrationsrisiko: Zielumgebung steht und ist validiert, bevor der erste Workload migriert wird.

Herausforderungen und Limitierungen

• Initiale Komplexität: Der Aufbau erfordert Expertise in Organizations, Control Tower, Networking und IAM — gleichzeitig.
• Organisatorischer Wandel: Multi-Account-Strategie bedeutet neue Prozesse für Account-Requests, Budgets und Verantwortlichkeiten.
• SCP-Vererbung: Falsch konfigurierte SCPs können legitime Workloads blockieren. Staging-OU für Policy-Tests ist unerlässlich.
• Netzwerk-Planung: CIDR-Ranges müssen langfristig geplant werden — nachträgliche Änderungen sind aufwendig.
• Kein Selbstläufer: Eine Landing Zone muss kontinuierlich gewartet werden: neue Guardrails, Control-Tower-Updates, Account-Lifecycle-Management.

Häufige Fragen zum Landing Zone Design

Kann ich eine Landing Zone nachträglich einführen?

Ja, aber mit erheblichem Aufwand. Bestehende Accounts müssen in die neue OU-Struktur migriert, SCPs schrittweise eingeführt und Netzwerke neu organisiert werden. Der Aufwand ist typischerweise 3-5x höher als der initiale Aufbau.

Wie viele Accounts brauche ich mindestens?

Control Tower erstellt initial drei Accounts (Management, Log Archive, Audit). Für eine produktive Landing Zone empfiehlt Storm Reply mindestens 6-8 Accounts: zusätzlich Network Hub, Shared Services und je ein Workload-Account für SDLC und Produktion.

Funktioniert Control Tower mit bestehendem Active Directory?

Ja. IAM Identity Center (ehemals AWS SSO) integriert sich über SAML 2.0 oder direkte AD-Connector-Anbindung mit bestehendem Active Directory. Bestehende Gruppen und Benutzer werden übernommen.

Was kostet eine Landing Zone?

Control Tower selbst ist kostenlos. Die Kosten entstehen durch die genutzten AWS-Services (Organizations, Config, CloudTrail, etc.) und die Beratungsleistung für Design und Implementierung. Im Rahmen des AWS MAP-Programms können diese Kosten über die Mobilize-Phase gefördert werden.

Ausblick: Landing Zones als Plattform-Fundament

Landing Zones entwickeln sich zunehmend von einer einmaligen Einrichtung zu einer kontinuierlich verwalteten Plattform. AWS erweitert Control Tower regelmäßig um neue Controls — seit 2023 mit proaktiven Guardrails, die CloudFormation-Templates vor dem Deployment prüfen.

Für DACH-Unternehmen wird die regulatorische Dimension weiter an Bedeutung gewinnen. Die NIS2-Richtlinie, die ab Oktober 2024 in nationales Recht umgesetzt wird, verschärft die Anforderungen an Supply-Chain-Security und Incident Reporting. Eine sauber aufgesetzte Landing Zone mit zentralem Logging, automatisierten Compliance-Checks und klarer Account-Isolation ist die technische Voraussetzung, um diese Anforderungen effizient zu erfüllen.