AWS European Sovereign Cloud: Chancen und Grenzen der neuen EU-Infrastruktur

Mit der European Sovereign Cloud hat Amazon Web Services Mitte Januar 2026 eine physisch und logisch getrennte Cloud-Infrastruktur in Betrieb genommen. Die ausschließlich in der EU betriebene Partition soll Anforderungen an Datenhoheit erfüllen – kommt jedoch zunächst mit funktionalen Einschränkungen. Wie kürzlich von Rich Mogull, Chief Analyst, Cloud Security Alliance (CSA) beschrieben, erfordert die neue Plattform eine sorgfältige Evaluierung.

Neue Partition für europäische Datensouveränität

Amazon Web Services stellte am 15. Januar 2026 die European Sovereign Cloud (ESC) bereit. Die neue Partition bildet eine vollständig isolierte Version der AWS-Infrastruktur, die komplett innerhalb der Europäischen Union gehostet und betrieben wird. Sämtliche Komponenten befinden sich auf EU-Territorium, ohne technische Verbindungen zu US-amerikanischen Systemen.

Anders als bestehende EU-Regionen von AWS verfügt die ESC über eine eigenständige Verwaltungs- und Kontroll­ebene. Während reguläre AWS-Regionen weltweit auf eine zentrale Steuerungsebene in den USA zugreifen – etwa für Dienste wie IAM oder Route53 – arbeitet die ESC vollständig autonom innerhalb europäischer Grenzen.

Grafik Quelle: Cloud Security Alliance (CSA)

Rechtliche Struktur und Betriebsmodell

Obwohl Amazon als US-Konzern Eigentümer der Infrastruktur bleibt, erfolgt die Verwaltung durch spezialisierte europäische Rechtsträger nach deutschem Recht. Der Betrieb wird schrittweise auf EU-Bürger mit Wohnsitz in der EU umgestellt. Dies umfasst den täglichen Betrieb, technischen Support und Kundenservice.

Die Kombination aus rechtlichen Strukturen, technischen Isolationsmechanismen und der AWS-Nitro-Hardware schafft weitreichende Abschottung gegenüber US-Einfluss. Experten bewerten dies als wirksamen Schutz, selbst unter Berücksichtigung des CLOUD Act.

Verfügbare Services und Einschränkungen

Zum Start stehen zentrale AWS-Dienste bereit, darunter EC2, S3, Bedrock und Lambda. Die vollständige Liste wird kontinuierlich erweitert. CloudFront fehlt derzeit und soll im vierten Quartal verfügbar werden.

Bei Sicherheits- und Governance-Funktionen zeigen sich Lücken. AWS Organizations wird unterstützt, allerdings ohne zahlreiche Governance-Features. Service Control Policies sind verfügbar, delegierte Verwaltung hingegen nicht. Dies erfordert die Ausführung von Services wie CloudFormation StackSets direkt vom Management-Konto.

Verfügbare Sicherheitstools umfassen GuardDuty, Config und Security Hub inklusive CSPM. Amazon Inspector für Workload-Scanning steht noch aus. S3 Block Public Access ist vorhanden, jedoch nicht standardmäßig aktiviert wie in der Hauptpartition. GuardDuty bietet eingeschränkte Funktionalität ohne Organisationsebenen-Verwaltung und neuere Features.

IAM Identity Center fehlt

Die bedeutendste Funktionslücke betrifft das IAM Identity Center. Dieses zentrale Tool zur Identitäts- und Zugriffsverwaltung über AWS-Organisationen hinweg ist nicht verfügbar. Normalerweise ermöglicht es die Anbindung externer Identitätsanbieter und die zentrale Zuweisung von Benutzerrechten auf Rollen und Konten.

Ohne IAM Identity Center müssen Organisationen für jedes AWS-Konto separat einen Identitätsanbieter einbinden. Dies erhöht den Verwaltungsaufwand erheblich und erschwert den Wechsel zwischen Konten sowie den Zugriff per Kommandozeile und API.

Für CLI-Nutzer entsteht ein praktisches Problem: Die Rollenübernahme erfordert einen vertrauenswürdigen Prinzipal. Ohne IAM Identity Center bleiben nur IAM-Benutzer mit statischen Zugangsdaten oder spezialisierte CLI-Tools für den jeweiligen Identitätsanbieter. Da Zugriffsschlüssel die Hauptquelle für Kompromittierungen von AWS-Konten darstellen, gilt die zeitnahe Integration des IAM Identity Center als dringlich.

Resilienz und geografische Verfügbarkeit

Aktuell existiert eine einzige Region. Die Expansion in weitere EU-Mitgliedstaaten erfolgt zunächst über Local Zones. Diese Erweiterungen einer Region auf zusätzliche Standorte dienen primär der Latenzoptimierung und unterstützen typischerweise ein reduziertes Service-Portfolio, hauptsächlich EC2 und VPC. Sie helfen bei länderspezifischen Anforderungen an Datenresidenz.

Die Partitionsisolierung bietet einen Vorteil: Bei Ausfällen in us-east-1 bleiben ESC-Anwendungen verfügbar. Allerdings verursacht die Datensynchronisation zwischen Partitionen Kosten für Internet-Übertragungen oder private Netzwerkverbindungen. Im Unterschied zu Multicloud-Ansätzen ist keine Neukonzeption der Architektur nötig – Infrastructure-as-Code-Implementierungen lassen sich partitionsübergreifend migrieren und bereitstellen.

Die beschränkte Anzahl an Availability Zones schränkt hochverfügbare Architekturen ein. Für geschäftskritische Anwendungen ohne Toleranz für Ausfallzeiten empfiehlt sich derzeit Zurückhaltung.

Handlungsempfehlungen

Unternehmen mit europäischem Geschäft sollten die ESC evaluieren. Die Einrichtung einer Organisation mit Sandbox-Konto ermöglicht praktische Erfahrungen mit den Unterschieden zur Hauptpartition.

Initiale Deployments sollten begrenzt bleiben. Fehlende zentrale IAM-Funktionen und Governance-Tools erhöhen Sicherheitsrisiken. Die erweiterte Nutzung von IAM-Benutzern ist zu vermeiden – SSO lässt sich auch ohne Identity Center implementieren.

CSPM- und CNAPP-Anbieter unterstützen die ESC möglicherweise noch nicht. Eine Anfrage mit konkretem Zeitplan ist ratsam. Die Resilienz-Beschränkungen durch eine einzelne Region mit begrenzten Availability Zones erfordern besondere Aufmerksamkeit bei der Architekturplanung.

AWS wird voraussichtlich zügig weitere Services migrieren, da keine Neuentwicklung erforderlich ist, sondern Migration, Tests und Freigabe bestehender Funktionen. Die Sicherheitsgrundlagen inklusive Nitro-Architektur, KMS, IAM und Security Groups sind vollständig verfügbar – die ESC bietet bereits ein Sicherheitsniveau, das AWS in früheren Jahren nicht erreichte.

Mehr Lesestoff:

---

Bild/Quelle: https://depositphotos.com/de/home.html