Der Souveränitäts-Fahrplan: In 12 Monaten zur compliant Cloud

Executive Summary

Souveräne Cloud ist keine Frage des Ob, sondern des Wie und Wann. Dieser Artikel liefert einen praxiserprobten 4-Phasen-Fahrplan für DACH-Unternehmen, die innerhalb von 12 Monaten eine NIS2- und DSGVO-konforme Sovereign Landing Zone auf der AWS European Sovereign Cloud (ESC) aufbauen wollen. Der Fahrplan basiert auf dem AWS Migration Acceleration Program (MAP) und der praktischen Projekterfahrung von Storm Reply aus über 600 abgeschlossenen Cloud-Migrationen im DACH-Markt. Jede Phase enthält konkrete Meilensteine, Entscheidungspunkte und die häufigsten Fehler — damit Ihre Organisation den typischen Stolperfallen ausweicht.

Warum ein strukturierter Fahrplan entscheidend ist

Souveräne Cloud-Migrationen scheitern selten an der Technologie. Sie scheitern an fehlender Planung: unklare Scope-Definition, fehlende Stakeholder-Einbindung, unterschätzte Legacy-Komplexität und vernachlässigte Compliance-Dokumentation. Der Unterschied zwischen einem erfolgreichen und einem gescheiterten Projekt liegt fast immer in den ersten acht Wochen — in der Qualität der Assessment-Phase.

Die gute Nachricht: Die Migrationsmuster für souveräne Cloud sind inzwischen gut verstanden. AWS stellt mit dem Migration Acceleration Program (MAP) eine strukturierte Methodik bereit. Partner wie Storm Reply bringen projekterfahrene Spezialisten mit. Und die BSI hat mit dem C5-Katalog einen klaren Compliance-Rahmen definiert, gegen den Fortschritte messbar sind.

Der folgende 12-Monats-Fahrplan ist in vier Phasen gegliedert: Assessment, Architektur, Migration und Validierung. Jede Phase hat klare Ein- und Ausgangskriterien sowie definierte Entscheidungspunkte — sogenannte Stage Gates — an denen bewertet wird, ob die nächste Phase gestartet werden kann.

Der 4-Phasen-Fahrplan im Überblick

1. Phase 1 — Assessment (Monate 1–2): Lückenanalyse und Scope-Definition

   Ziel: vollständige Bestandsaufnahme des aktuellen Zustands, Klassifizierung aller Workloads nach Souveränitätsbedarf, Identifikation regulatorischer Lücken.

2. Phase 2 — Architektur (Monate 3–4): Sovereign Landing Zone und Zielarchitektur

   Ziel: Entwurf und Aufbau der Sovereign Landing Zone auf der ESC, Definition der Sicherheits- und Governance-Guardrails, Dienste-Mapping und Entscheidung über Migrationsstrategien pro Workload.

3. Phase 3 — Migration (Monate 5–10): Gestaffelte Workload-Migration

   Ziel: Migration aller souveränitätsrelevanten Workloads in priorisierten Wellen, Validierung von Compliance-Controls nach jeder Welle, Betriebsübergabe an eigene Teams.

4. Phase 4 — Validierung (Monate 11–12): Audit-Readiness und Zertifizierung

   Ziel: vollständige BSI-C5-Audit-Readiness, abgeschlossene NIS2-Dokumentation, BSI-Registrierung, Übergabe an Regelbetrieb mit definierten SLAs.

Phase 1: Assessment — Der Grundstein des Projekts (Monate 1–2)

Was in dieser Phase passiert

Das Assessment ist die wichtigste Phase des gesamten Projekts. Hier werden die Weichen gestellt: Was muss souverän sein? Was kann auf eu-central-1 verbleiben? Welche regulatorischen Anforderungen gelten konkret für diese Organisation? Wie groß ist die Lücke zum Zielzustand?

Das Assessment umfasst drei Arbeitsströme, die parallel laufen:

1. Workload-Inventarisierung und -Klassifizierung

   Alle Systeme, Anwendungen und Datensätze werden erfasst und nach Souveränitätsbedarf klassifiziert. Klassifizierungsdimensionen: Datentyp (personenbezogen, VS-NfD, Geschäftsgeheimnis), regulatorischer Rahmen (DSGVO Art. 9, NIS2 KRITIS, DORA), Verfügbarkeitsanforderung (RTO/RPO), externe Abhängigkeiten (Drittanbieter, APIs, SaaS).

2. Regulatorische Lückenanalyse (NIS2-Gap-Assessment)

   Abgleich des aktuellen Stands gegen NIS2-Anforderungen, BSI C5-Kontrollen und DSGVO-Pflichten. Output: priorisierter Maßnahmenplan mit Zeithorizont. Für NIS2-betroffene Organisationen, die noch nicht beim BSI registriert sind, muss die Registrierung sofort eingeleitet werden — sie hat eine separate Frist.

3. Technisches Discovery auf AWS

   Wenn bereits AWS-Konten existieren: automatisiertes Discovery mit AWS Migration Evaluator. Identifikation aller genutzten Dienste, Ressourceninventarisierung, Cost-Baseline. Diese Daten sind Grundlage für das Dienste-Mapping in Phase 2.

Stage Gate 1 — Entscheidungspunkt nach Phase 1

Vor Phase 2 wird bewertet: Ist der Scope klar und von allen Stakeholdern — IT, Recht, Datenschutz, Compliance, Vorstand — akzeptiert? Gibt es einen genehmigten Business Case? Ist das MAP-Programm beantragt? Nur wenn alle drei Fragen mit Ja beantwortet werden können, beginnt Phase 2.

Häufige Fehler in Phase 1

• Scope-Inflation: Zu viele Workloads werden als "souveränitätsrelevant" klassifiziert, ohne dass das regulatorisch begründbar ist. Das treibt Kosten und Komplexität unnötig.
• Fehlende Rechtsabteilung: Das Assessment wird rein technisch durchgeführt, ohne juristische Einschätzung der regulatorischen Anforderungen.
• Fehlende BSI-Registrierung: NIS2-betroffene Organisationen, die noch nicht registriert sind, riskieren, bereits im Verzug zu sein.

Phase 2: Architektur — Die Sovereign Landing Zone (Monate 3–4)

Was in dieser Phase passiert

Die Architekturphase hat zwei Outputs: die Sovereign Landing Zone (SLZ) auf der ESC und die Zielarchitektur für jeden souveränitätsrelevanten Workload.

Sovereign Landing Zone Aufbau

1. AWS Organizations und ESC-Account-Struktur

   Aufbau der Organisationsstruktur mit dedizierten OUs (Organizational Units) für Produktions-, Test- und Management-Umgebungen. Die ESC-Konten werden als separate OU innerhalb der bestehenden AWS-Organizations-Struktur angelegt — oder neu aufgebaut.

2. AWS Control Tower Deployment mit Sovereign Guardrails

   Control Tower ist das Herzstück der Landing Zone: automatisiertes Account-Vending, baseline Guardrails und Compliance-Monitoring. Für die ESC werden zusätzliche Sovereign Controls aktiviert: Blockierung von Datenexporten außerhalb der ESC, Erzwingung von Region-Locks, MFA-Pflicht für alle Zugriffe.

3. Service Control Policies (SCPs) Definition

   Organisationsweite SCPs, die verbotene Aktionen technisch unmöglich machen: Replikation in Nicht-EU-Regionen, Erstellung öffentlicher S3-Buckets, Deaktivierung von CloudTrail, Nutzung nicht-genehmigter AWS-Dienste. SCPs sind der letzte Sicherheitsanker — sie greifen auch dann, wenn IAM-Berechtigungen fehlerhaft konfiguriert sind.

4. Schlüsselmanagement-Strategie

   Definition der KMS-Schlüsselstruktur: welche Workloads brauchen Customer Managed Keys (CMKs), welche brauchen CloudHSM? Key-Rotation-Policy, Schlüssel-Lifecycle und Audit-Trail-Konfiguration via CloudTrail.

5. Netzwerkarchitektur

   Hub-and-Spoke VPC-Design mit Transit Gateway. PrivateLink für Service-to-Service-Kommunikation ohne Datenabfluss ins öffentliche Internet. Direct Connect für hybride on-premises-zu-ESC-Verbindungen. Network Firewall und WAF an den Netzwerkgrenzen.

6. Compliance-Monitoring Setup

   AWS Config mit Compliance-Rules gegen BSI C5, DSGVO und NIS2. AWS Security Hub als zentrales Compliance-Dashboard. AWS Audit Manager mit BSI C5 Assessment Framework für automatisierte Evidenzsammlung.

Dienste-Mapping und Migrationsstrategien

Für jeden souveränitätsrelevanten Workload wird die Migrationsstrategie festgelegt. AWS definiert sechs Strategien (die "6 R's"):

Rehost (Lift and Shift)

1:1-Migration ohne Architekturänderungen. Schnell, risikoarm, aber keine Cloud-Optimierung. Geeignet für einfache Applikationen ohne ESC-inkompatible Dienste.

Replatform (Lift, Tinker and Shift)

Migration mit minimalen Optimierungen: z.B. Wechsel von self-managed MySQL zu RDS, oder von EC2-basiertem Queue-System zu SQS. Geringe Änderungen, spürbare Effizienzgewinne.

Refactor / Re-architect

Signifikante Architekturänderungen: Containerisierung, Microservices-Trennung, serverless Migration. Höchster Aufwand, aber stärkste langfristige Kostenoptimierung und Resilienz.

Repurchase

Wechsel zu einem anderen Produkt, typischerweise einer SaaS-Lösung. Relevant, wenn aktuelle Software keine ESC-Kompatibilität hat und ein besseres ESC-natives Äquivalent verfügbar ist.

Retire

Stilllegung von Systemen, die keine Geschäftsfunktion mehr erfüllen. Oft entdeckt das Assessment 10–20 % der Workloads als Retire-Kandidaten — diese Systeme müssen nicht migriert werden.

Retain

Workloads, die vorerst on-premises oder in eu-central-1 verbleiben — entweder weil der benötigte Dienst noch nicht in der ESC verfügbar ist, oder weil das Souveränitätsrisiko bewertbar gering ist.

Stage Gate 2 — Entscheidungspunkt nach Phase 2

Die Landing Zone muss durch ein internes Sicherheits-Review und eine optionale externe Vorab-Prüfung durch einen BSI-akkreditierten Prüfer validiert werden. Erst dann startet Phase 3.

Phase 3: Migration — Gestaffelte Workload-Wellen (Monate 5–10)

Das Wellen-Modell

Souveräne Cloud-Migrationen werden in Wellen durchgeführt — typischerweise 3 bis 5 Wellen über 6 Monate. Die Priorisierung folgt einem klaren Prinzip: Welle 1 enthält die einfachsten, risikoärmsten Workloads. Jede folgende Welle erhöht die Komplexität schrittweise. Kritische Produktionssysteme kommen erst in Welle 3 oder später.

1. Welle 1 (Monate 5–6): Proof-of-Value-Workloads

   Einfache, nicht-kritische Systeme: Entwicklungsumgebungen, Testdaten-Repositorien, interne Tools. Ziel: operative ESC-Erfahrung sammeln, Prozesse testen, Monitoring validieren. Kein Produktionsdruck, aber echte ESC-Infrastruktur.

2. Welle 2 (Monate 7–8): Mittlere Komplexität

   Systeme mit moderatem Geschäftswert und klar definierter Datensouveränitätspflicht: interne Datamarts, HR-Systeme, Analytics-Plattformen. Hier wird die Verschlüsselungs- und Schlüsselmanagement-Strategie im produktiven Kontext validiert.

3. Welle 3–4 (Monate 9–10): Kritische Produktionssysteme

   Kern-Produktionssysteme mit höchstem Souveränitätsbedarf: Core-Banking, Patientendaten, KRITIS-OT-Systeme. Diese Wellen erfordern sorgfältige Rollback-Planung, parallelen Betrieb während der Übergangsphase und intensive Tests vor dem Cutover.

Compliance-Checkpoint nach jeder Welle

Nach jeder Welle wird ein Compliance-Checkpoint durchgeführt: Stimmen die konfigurierten Controls mit den BSI-C5-Anforderungen überein? Sind alle CloudTrail-Logs vollständig? Sind SCPs korrekt durchgesetzt? Dieser Checkpoint ist kein bürokratisches Ritual, sondern der Mechanismus, der sicherstellt, dass sich Compliance-Schulden nicht aufschichten.

Häufige Fehler in Phase 3

• Übersprungene Wellen: Druck, kritische Systeme früh zu migrieren, ohne ausreichende ESC-Betriebserfahrung. Das erhöht das Risiko ungeplanter Ausfälle erheblich.
• Fehlende Rollback-Planung: Jeder Cutover braucht einen getesteten Rollback-Pfad. "Wir können notfalls zurück" ist keine Rollback-Strategie.
• Vernachlässigte Dritt-Software: Viele Enterprise-Applikationen haben Abhängigkeiten zu SaaS-Diensten, die möglicherweise nicht ESC-kompatibel sind. Diese müssen in Phase 1 identifiziert und in Phase 2 adressiert werden.

Stage Gate 3 — Entscheidungspunkt nach Phase 3

Sind alle Ziel-Workloads erfolgreich migriert? Läuft der Betrieb stabil (mindestens 4 Wochen ohne kritische Incidents)? Sind alle Compliance-Checkpoints positiv abgeschlossen? Erst dann beginnt Phase 4.

Phase 4: Validierung — Audit-Readiness und Zertifizierung (Monate 11–12)

Was in dieser Phase passiert

Phase 4 ist keine technische Phase — sie ist eine Dokumentations- und Nachweisphase. Das Ziel: vollständige Audit-Readiness für BSI C5, NIS2 und bei Bedarf DORA. Nach Abschluss ist die Organisation in der Lage, einem Prüfer auf Anfrage sämtliche Compliance-Nachweise vorzulegen.

1. BSI-C5-Evidenzsammlung via AWS Audit Manager

   AWS Audit Manager generiert automatisch Compliance-Evidenzen für den BSI C5-Kontrollrahmen: Screenshots, Konfigurationsberichte, CloudTrail-Logs, Security Hub-Findings. Diese Evidenzen werden strukturiert in einem Audit-Paket zusammengefasst.

2. NIS2-Dokumentationspaket

   Vollständige Dokumentation der implementierten Cybersicherheitsmaßnahmen gemäß NIS2 Art. 21: Risikoanalyse, Business Continuity, Supply-Chain-Sicherheit, Verschlüsselung, Zugangskontrollen, Incident-Response-Plan, Meldeprozesse.

3. DSGVO-Verarbeitungsverzeichnis und TOMs

   Aktualisiertes Verzeichnis der Verarbeitungstätigkeiten (VVT) mit Verweis auf ESC als Verarbeitungsort. Technische und organisatorische Maßnahmen (TOMs) aktualisiert und auf ESC-spezifische Controls abgestimmt.

4. Abschluss-Assessment und Vorprüfung

   Optionale Vorprüfung durch externen BSI-akkreditierten Prüfer vor dem offiziellen Audit. Identifiziert verbleibende Lücken, die in den letzten Wochen vor dem Audit geschlossen werden können.

5. Betriebsübergabe und RACI-Aktualisierung

   Formelle Übergabe an den Regelbetrieb: aktualisierte RACI-Matrix für alle Souveränitätskontrollen, Betriebshandbuch für ESC-spezifische Prozesse (Schlüsselrotation, Incident Response, Änderungsmanagement), Runbooks für kritische Betriebssituationen.

Ergebnis nach Monat 12

Nach Abschluss von Phase 4 hat die Organisation:

• Alle souveränitätsrelevanten Workloads auf der ESC in produktivem Betrieb
• BSI C5 Type 2 Audit-Readiness — vollständige Evidenzdokumentation
• NIS2-Dokumentationspaket — bereit für BSI-Prüfung
• Aktualisiertes DSGVO-Verarbeitungsverzeichnis
• Intern geschultes Betriebsteam mit ESC-spezifischer Expertise
• Definierte SLAs und Eskalationspfade für den Souveränitäts-Regelbetrieb

AWS Migration Acceleration Program (MAP): Förderung und Methodik

Das AWS Migration Acceleration Program (MAP) ist der strukturelle Rahmen, in dem Storm Reply ESC-Migrationen durchführt. MAP bietet drei Kernvorteile:

Migration Credits

Finanzielle AWS-Gutschriften, die Migrationskosten direkt reduzieren. Die Höhe der Credits hängt vom Umfang der Migration ab und wird im MAP-Assessment definiert. Für DACH-Unternehmen, die noch keine ESC-Workloads haben, sind die Credits besonders wertvoll für die Übergangskostendeckung.

Bewährte Werkzeuge und Beschleuniger

MAP-Migrationen nutzen vorkonfigurierte Toolchains: AWS Application Migration Service (MGN) für Server-Migrationen, AWS Database Migration Service (DMS) für Datenbanken, CloudEndure für kontinuierliche Replikation während der Migrationsphase.

Technischer Support und Reviews

MAP-Projekte haben Zugang zu AWS-internen Architektur-Reviews, Migration-Playbooks und eskaliertem Support. Für ESC-Migrationen ist dieser Zugang besonders wertvoll, da die ESC-Plattform neu ist und Partner-ESC-Erfahrung noch selten ist.

Storm Reply ist MAP-qualifizierter Partner und kann MAP-Credits und -Ressourcen für Kundenprojekte aktivieren. Das MAP-Assessment wird typischerweise am Ende von Phase 1 eingeleitet.

Storm Reply: 12 Monate in der Praxis

Storm Reply ist AWS Premier Consulting Partner DACH mit AWS Migration Competency und AWS Security Competency. Die Storm-Reply-Methodik für ESC-Migrationen basiert auf über 600 abgeschlossenen Cloud-Projekten im DACH-Markt und integriert spezifisch deutsche Compliance-Anforderungen: NIS2-Umsetzung, BSI-Registrierung, DSGVO-Verarbeitungsverzeichnisse und branchenspezifische Anforderungen (KRITIS, DORA, TKG).

Für den 12-Monats-Fahrplan stellt Storm Reply typischerweise ein dediziertes Projektteam aus Migration-Architects, Security-Engineers, Compliance-Spezialisten und Projektmanagement bereit. Das Team arbeitet hybrid — Beratung vor Ort in DACH kombiniert mit remote Delivery aus Gütersloh, Hamburg, Frankfurt, Berlin, Dortmund oder München.

Storm Reply ist Teil der Reply-Gruppe mit 16 AWS-Kompetenzen, 17 Service Deliveries und 1.500+ AWS-Zertifizierungen. Storm Reply — AWS Premier Consulting Partner DACH. Mehr erfahren: reply.com/storm-reply

Quellen und weiterführende Links

1. AWS: AWS Migration Acceleration Program (MAP)
2. AWS: Europe Digital Sovereignty on AWS
3. AWS Dokumentation: AWS Control Tower — Landing Zone
4. BSI: BSI C5 Kriterienkatalog
5. BSI: NIS-2 in Deutschland — BSI
6. AWS Dokumentation: AWS Audit Manager