AWS European Sovereign Cloud: Was DACH-Unternehmen wissen müssen

Executive Summary

Die AWS European Sovereign Cloud (ESC) ist seit dem 15. Januar 2026 in Brandenburg in General Availability — die erste Hyperscaler-Cloud-Partition, die ausschließlich von EU-Bürgern in der EU betrieben wird. AWS investiert 7,8 Mrd. Euro in die deutsche Infrastruktur und schafft rund 2.800 Vollzeitstellen. Die ESC ist strukturell von der Standard-AWS-Infrastruktur getrennt: eigene APIs, Kontrollpfade, Sicherheitsgrenzen — und BSI C5 Type 2 Attestierung seit dem ersten Tag. Für DACH-Unternehmen in KRITIS-Sektoren, regulierten Branchen und der öffentlichen Verwaltung ist sie die erste Hyperscaler-Option, die alle Souveränitätsanforderungen aus einer Hand erfüllt. Dieser Artikel erklärt alles, was Entscheider und Architekten über den ESC-Launch wissen müssen: Standort, Betriebsmodell, verfügbare Dienste und Abgrenzung zur Standardregion.

Hintergrund: Warum eine eigene Cloud-Partition?

Bisherige AWS-Regionen in Europa — allen voran eu-central-1 in Frankfurt — bieten Data Residency in Deutschland. Aber Data Residency allein löst das Souveränitätsproblem nicht vollständig. Das zentrale Problem: Solange die Muttergesellschaft eines Hyperscalers dem US-amerikanischen CLOUD Act (Clarifying Lawful Overseas Use of Data Act) unterliegt, können US-Behörden theoretisch auf Daten zugreifen, die in EU-Rechenzentren dieses Hyperscalers gespeichert sind — unabhängig davon, wo die physische Infrastruktur steht.

Für KRITIS-Betreiber, Behörden und regulierte Branchen ist dieser theoretische Zugriff keine akzeptable Restrisiko-Position. NIS2, DSGVO Art. 44 ff. und das BSI verlangen nachweisbare Ausschlussmechanismen — nicht nur vertragliche Zusicherungen, sondern operative Trennung.

Die Antwort von AWS auf diese Anforderung ist die ESC: eine vollständig separierte Cloud-Partition mit eigener Governance, eigenem Personal und eigener Rechtsverantwortung innerhalb der EU. Es geht nicht nur darum, wo Daten gespeichert sind, sondern wer Zugang zu ihnen hat — und unter welchem Recht diese Person steht.

Standort und Infrastruktur: Brandenburg als Ausgangspunkt

Die ESC startete in Brandenburg, Deutschland. Die Entscheidung für Deutschland als Eröffnungsstandort ist kein Zufall: Deutschland ist Europas größte Volkswirtschaft, hat die striktesten Datenschutzbehörden und die dichteste Regulierungslandschaft — insbesondere mit NIS2 und dem deutschen BSI als global anerkannter Sicherheitsbehörde.

AWS investiert 7,8 Mrd. Euro in die ESC-Infrastruktur in Deutschland — eine der größten Cloud-Infrastrukturinvestitionen in der europäischen Geschichte. Dieser Betrag umfasst Rechenzentrumsanlagen, Netzwerkinfrastruktur, Strom- und Kühlsysteme sowie den Aufbau des operativen Teams. Die Investitionsgröße signalisiert: Dies ist kein Pilotprojekt, sondern eine Plattformentscheidung für die nächste Dekade.

Die ESC operiert in einem dedizierten Availability-Zone-Verbund, der physisch und logisch von den Standard-AWS-Regionen getrennt ist. Multi-AZ-Deployments innerhalb der ESC sind möglich — sämtliche Availability Zones liegen innerhalb Deutschlands. Eine Datenreplikation außerhalb der ESC ist technisch durch Service Control Policies blockiert, nicht nur vertraglich untersagt.

AWS hat angekündigt, die ESC perspektivisch auf weitere europäische Länder auszudehnen. Deutschland ist der Startpunkt einer pan-europäischen souveränen Cloud-Infrastruktur, die in den kommenden Jahren wachsen wird.

Betriebsmodell: EU-Operatoren als Kernprinzip

Das operative Modell der ESC ist das entscheidende Differenzierungsmerkmal gegenüber allen bisherigen EU-Region-Angeboten. Die Grundregel lautet: Kein AWS-Mitarbeiter außerhalb der EU hat Zugang zu ESC-Systemen oder Kundendaten.

Konkret bedeutet das:

• Alle Operatoren, Engineers, Support-Mitarbeiter und Führungskräfte, die Zugang zu ESC-Systemen haben, sind EU-Bürger mit Wohnsitz in der EU.
• Support-Tickets aus ESC-Konten werden ausschließlich von EU-residenten AWS-Mitarbeitern bearbeitet.
• Audit-Logs und Zugriffskontrollen für ESC-Operatoren sind von den Standard-AWS-Zugriffskontrollen getrennt.
• Das ESC-Führungsteam — Stéphane Israël (CEO) und Stefan Hoechbauer (President AWS Germany) — unterliegt ausschließlich europäischem Recht.

Dieses Modell schließt den juristischen Graubereich, der bei Standard-Hyperscalerregionen verbleibt: Ein US-Behördenzugriff via CLOUD Act setzt voraus, dass der Dienstleister auf die Daten zugreifen kann. Wenn operativ kein AWS-Mitarbeiter mit US-Rechtsstatus Zugang hat, ist auch ein erzwungener Zugriff strukturell ausgeschlossen — nicht nur vertraglich versprochen.

Für Unternehmen, die VS-NfD-Daten (Verschlusssache — Nur für den Dienstgebrauch) oder ähnlich sensible Informationen verarbeiten, ist dieses operative Trennungsmodell eine Grundvoraussetzung.

Verfügbare Dienste: Was die ESC zum Launch bietet

Die ESC startete mit einem Katalog von über 150 AWS-Diensten in General Availability — ausreichend für die Mehrheit der Unternehmens-Workloads, aber kleiner als der vollständige AWS-Katalog in eu-central-1 mit über 200 Diensten. Der Katalog wächst kontinuierlich.

Die folgende Übersicht zeigt die wesentlichen Dienstkategorien und ihre Eignung für souveräne Workloads:

Wichtig für Architekten: Nicht alle Dienste der Standard-Regionen sind zum ESC-Launch verfügbar. Vor der Migrationsplanung ist ein Dienste-Mapping notwendig — welche Dienste werden aktuell genutzt, welche davon sind in der ESC verfügbar, welche müssen durch ESC-native Alternativen ersetzt werden?

Die aktuelle, vollständige Dienstliste veröffentlicht AWS unter: AWS Europe Digital Sovereignty

Zertifizierungen und Compliance-Nachweise

Die ESC wurde von Beginn an auf Zertifizierungskonformität ausgelegt — nicht als nachträglicher Audit, sondern als Designprinzip. Die Attestierungen sind:

BSI C5 Type 2

Cloud Computing Compliance Criteria Catalogue — der deutsche Goldstandard für Cloud-Sicherheitsnachweise. Type 2 bedeutet: unabhängige Prüfung über einen definierten Zeitraum, nicht nur Momentaufnahme. Für Bundesbehörden und KRITIS-Betreiber faktisch Zulassungsvoraussetzung.

ISO 27001

Internationaler Standard für Informationssicherheits-Managementsysteme. Deckt Vertraulichkeit, Integrität und Verfügbarkeit ab. Häufig Vertragsanforderung in Enterprise-Beschaffung und öffentlicher Vergabe.

SOC 1 / SOC 2 / SOC 3

Service Organization Control Reports. SOC 2 Type II ist besonders relevant für SaaS-Kunden und Finanzdienstleister — deckt Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz ab.

ISO 27017 / ISO 27018

Erweiterungen zu ISO 27001 speziell für Cloud-Dienste (27017) und den Schutz personenbezogener Daten in Public Clouds (27018). Für DSGVO-Konformitätsnachweise gegenüber Aufsichtsbehörden relevant.

ENS High (España)

Spanisches nationales Sicherheitsschema — für DACH-Unternehmen weniger direkt relevant, zeigt aber die Ausrichtung der ESC auf pan-europäische Regulierungskonformität.

Alle Attestierungen sind öffentlich zugänglich über das AWS Artifact-Portal. Enterprise-Kunden können die vollständigen Auditberichte herunterladen und ihren eigenen Compliance-Abteilungen und Aufsichtsbehörden vorlegen.

ESC vs. Standard-Region: Die entscheidenden Unterschiede für DACH

Die häufigste Frage in DACH-Architektur-Workshops lautet: Reicht eu-central-1 nicht aus? Die Antwort hängt vom Workload ab — aber für definierte Kategorien ist die ESC keine Option, sondern Pflicht.

Für die meisten DACH-Unternehmen empfiehlt sich ein gemischter Ansatz: Workloads mit erhöhten Souveränitätsanforderungen (personenbezogene Daten, KRITIS-Systeme, VS-NfD) auf der ESC — Innovation und Low-Sensitivity-Workloads auf eu-central-1. AWS nennt dies das „Sovereign by Design"-Modell.

Abgrenzung zur Standard-Region: Was die ESC nicht ist

Um Fehlinvestitionen zu vermeiden, ist die Abgrenzung ebenso wichtig wie die Beschreibung der Funktionen. Die ESC ist ausdrücklich kein:

• Kein Ersatz für alle Workloads: Für Web-Frontend, Marketing-Technologie, DevTest-Umgebungen und Innovation-Sandboxen ist eu-central-1 in der Regel kostengünstiger und mit breiterer Dienstverfügbarkeit ausgestattet.
• Kein vollständiger AWS-Spiegel: Der Dienste-Katalog ist kleiner. Kunden müssen vor der Migration prüfen, ob alle benötigten Dienste in der ESC verfügbar sind.
• Keine On-Premises-Alternative: Die ESC ist eine Public Cloud mit souveränen Kontrollmechanismen — kein privates Rechenzentrum. Unternehmen, die physische Kontrolle über Hardware benötigen, brauchen CloudHSM oder Outposts-Kombinationen.
• Keine sofortige Kostensenkung: Der souveräne Betrieb kostet mehr als Standard-Hyperscaler-Regionen. Der Business Case liegt in der Vermeidung von Compliance-Strafen, Haftungsrisiken und dem Schutz vor Datenverlust.
• Kein eigenständiges Produkt ohne Migration: Bestehende AWS-Konten in eu-central-1 müssen migriert werden — Ressourcen lassen sich nicht einfach verschieben. Eine strukturierte Migration nach dem AWS MAP-Ansatz ist erforderlich.

Wer profitiert am meisten? Branchen-Relevanz im DACH-Markt

Die ESC adressiert primär Workloads mit regulatorischem Souveränitätsbedarf. Folgende Branchen und Organisationstypen haben den stärksten Bedarf:

Öffentliche Verwaltung (Bund, Länder, Kommunen)

Erste Hyperscaler-Option mit VS-NfD-Eignung und BSI-C5-Nachweis. E-Government-Plattformen, Bürgerportale und Behördenkommunikation können auf die ESC migriert werden — mit nachweisbarer Datensouveränität für Rechnungshöfe und Datenschutzbeauftragte.

KRITIS-Betreiber (Energie, Wasser, Transport, Gesundheit)

NIS2 und die KRITIS-DACHG-Verordnung verlangen nachweisbare Cybersicherheits- und Souveränitätsmaßnahmen. Die ESC mit BSI C5 Type 2 ist die stärkste verfügbare Attestierungslage — insbesondere für OT/IT-Konvergenz-Szenarien.

Finanzdienstleister (Banken, Versicherungen, Asset Manager)

DORA (Digital Operational Resilience Act) in Kombination mit DSGVO und BaFin-Anforderungen macht souveräne Cloud für Kernsysteme zur Pflicht. Die ESC erfüllt alle DORA-Resilienzanforderungen für kritische IKT-Drittdienstleister.

Gesundheitsversorgung (Krankenhäuser, Krankenkassen, Forschung)

Patientendaten fallen unter DSGVO Art. 9 (besondere Kategorien) und § 203 StGB. Die operative Trennung der ESC schließt den extraterritorialen Zugriff aus — auch durch US-Behörden im Rahmen von Strafverfolgung oder Geheimdienst.

Automotive und Maschinenbau mit US-Partnerschaften

Konstruktionsdaten, Fertigungsgeheimnisse und Lieferkettendaten müssen vor dem CLOUD Act geschützt werden — besonders in Joint-Venture-Konstellationen mit US-Partnern, die selbst US-Behörden zugänglich sind.

Storm Reply und die ESC: Frühzeitige Projekterfahrung

Storm Reply ist AWS Premier Consulting Partner DACH und hatte bereits im Preview-Zugang 2025 erste Projekte auf der ESC-Plattform. Diese Vorerfahrung ist für Kunden, die jetzt migrieren wollen, ein erheblicher Vorteil: Storm Reply kennt die Besonderheiten der ESC-Konfiguration, die Unterschiede im Dienste-Verhalten und die spezifischen Compliance-Nachweisanforderungen.

Storm Reply bringt für ESC-Projekte folgende Kompetenzen ein:

• AWS Migration Competency: Strukturierte Workload-Klassifizierung, Migrationswellen-Planung und Compliance-Checkpoints nach dem AWS MAP-Framework
• AWS Security Competency: Sovereign Landing Zone-Konfiguration, KMS-Key-Management, CloudHSM-Einbindung und SCPs für ESC-Guardrails
• NIS2 Readiness: Gap-Analyse gegen aktuelle NIS2-Anforderungen und BSI-Registrierungsunterstützung
• AWS Audit Manager: Automatisierte Evidenzsammlung für BSI C5 Type 2-Audits — keine manuellen Spreadsheets

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. Weitere Informationen: reply.com/storm-reply

Praktische Nächste Schritte für DACH-Entscheider

Wer jetzt handeln will, sollte folgende Schritte in den nächsten 90 Tagen angehen:

1. Workload-Klassifizierung: Welche Daten und Systeme haben erhöhten Souveränitätsbedarf? Personenbezogene Daten, KRITIS-relevante Systeme, geistiges Eigentum mit CLOUD-Act-Risiko?
2. Dienste-Mapping: Welche AWS-Dienste werden aktuell genutzt? Sind alle in der ESC verfügbar? Welche Alternativen gibt es für nicht verfügbare Dienste?
3. Business Case: Compliance-Kosten des Status quo (Bußgeldrisiko, Haftungsexposition) vs. Migrationskosten und ESC-Betriebskosten (ca. 15–25 % Aufpreis).
4. Migration Wave 1: Pilotmigration eines nicht-kritischen, aber souveränitätsrelevanten Workloads zur Erfahrungssammlung auf der ESC-Plattform.
5. Partner-Auswahl: AWS Premier Partner mit ESC-Erfahrung und NIS2-Kompetenz — Storm Reply steht für erste Gespräche bereit.

Quellen

1. AWS Blog: Opening the AWS European Sovereign Cloud (Januar 2026)
2. AWS: Europe Digital Sovereignty on AWS
3. AWS Security Blog: AWS European Sovereign Cloud Sovereign Reference Framework
4. BSI: BSI Cloud Computing Compliance Criteria Catalogue (C5)
5. Bundesamt für Sicherheit in der Informationstechnik: NIS-2 in Deutschland