AWS hat seine European Sovereign Cloud (ESC) im Januar 2026 gestartet, und das ist ein bedeutender Schritt. Im Gegensatz zu standardmäßigen AWS-Regionen, die unter einer globalen Kontrollebene operieren, verwendet ESC ein "Independent Partition"-Modell. Das bedeutet in der Praxis, dass ESC einen eigenen IAM- und Abrechnungs-Stack hat, und entscheidend ist, dass es vollständig von EU-Bürgern betrieben wird. Dieses Maß an operativer Trennung soll Bedenken hinsichtlich der Nicht-EU-Jurisdiktion über die Kontrollebene adressieren und Kunden einen klareren Einblick geben, wer auf ihre Ressourcen zugreifen und diese verwalten kann.

Microsofts Ansatz umfasst Konzepte wie "Data Guardian"-Rollen und Azure Local-Regionen. Der "Data Guardian" ist eine faszinierende Rolle: Hierbei handelt es sich um in Europa ansässiges Personal, das jeden Fernzugriff, der von US-amerikanischen Ingenieuren zur Unterstützung angefordert wird, physisch genehmigen muss. Stellen Sie sich den Prozess vor: Ein in den USA ansässiger Ingenieur muss ein Problem beheben, aber anstatt direkten Zugriffs fungiert ein europäischer Data Guardian als Gatekeeper und stellt die Einhaltung lokaler Vorschriften sicher. Dies führt zu einer menschlich kontrollierten Schutzschaltung für grenzüberschreitenden Zugriff, was ich als einen starken Schritt zur Minderung der extraterritorialen rechtlichen Reichweite sehe.

Für diejenigen, die das höchste Maß an Isolation suchen, stellt Google Distributed Cloud (GDC) im "Disconnected"- oder "Air-Gapped"-Modus das dar, was ich als den Goldstandard für "Taktische Souveränität" betrachte. Mit GDC können Sie eine vollständige Google Cloud-Umgebung vollständig vor Ort bereitstellen, isoliert von Googles Public Cloud. In ihrer Air-Gapped-Konfiguration arbeitet diese Cloud ohne jegliche Verbindung zum öffentlichen Internet oder Googles US-Kontrollebene. Dies bedeutet, dass Updates, Patches und die Verwaltung lokal gehandhabt werden müssen, oft über physische Medien. Das ist ein erheblicher operativer Aufwand, aber für Umgebungen mit extremen Souveränitätsanforderungen, wie bestimmte Regierungs- oder kritische Infrastruktur-Anwendungsfälle, durchtrennt es effektiv die digitale Nabelschnur zu Nicht-EU-Jurisdiktionen.

Während diese Hyperscaler-Lösungen überzeugende Optionen bieten, binden ihre zugrunde liegenden Architekturen sie immer noch inherent an eine globale Entität. Dies führt mich dazu, Alternativen in Betracht zu ziehen, die von Grund auf jurisdiktionell nativ sind.

OVHcloud, ein Industrieführer mit Hauptsitz in Frankreich, ist ein Beispiel dafür. Ihre Auswahl für das Digital-Euro-Projekt 2026 spricht Bände über das Vertrauen, das sie aufgebaut haben. Was ich an OVHcloud besonders überzeugend finde, ist ihr integriertes Modell: Sie bauen ihre eigenen Server, betreiben ihre eigenen Rechenzentren und entwickeln ihren eigenen Software-Stack. Dies bietet eine "Hardware-zu-Hypervisor"-Souveränität, die US-amerikanische Firmen aufgrund ihrer globalen operativen Präsenz meiner Meinung nach nicht wirklich erreichen können. Es geht darum, die gesamte Lieferkette zu besitzen, vom Silizium bis zur API.

In Deutschland hat T-Systems, eine Tochtergesellschaft der Deutschen Telekom, mit Broadcom (VMware) zusammengearbeitet, um einen "Managed Sovereign Stack" anzubieten. Diese Initiative richtet sich insbesondere an den deutschen Mittelstand und den öffentlichen Sektor und bietet eine VMware-basierte Private-Cloud-Erfahrung, die vollständig nach deutschem Recht verwaltet und betrieben wird. Es ist ein interessanter Hybrid, der ausgereifte Virtualisierungstechnologie nutzt, sie aber in einen souveränen operativen und rechtlichen Rahmen einbettet.

Frankreich hat die Entstehung von "Trusted Cloud"-Anbietern wie Bleu (ein Joint Venture zwischen Orange und Capgemini) und S3NS (Thales) erlebt. Diese Anbieter arbeiten nach einem Modell, bei dem sie Software von US-Hyperscalern (wie Microsoft Azure oder Google Cloud) betreiben, jedoch auf Hardware, die lokal im Besitz ist, betrieben und physisch in Frankreich unter französischem und europäischem Recht gesichert wird. Die Idee ist, die Reichweite des "Cloud Act" der US-Muttergesellschaften zu entkräften, indem sichergestellt wird, dass die physische Infrastruktur und die operative Kontrolle vollständig innerhalb der EU liegen. Es ist eine pragmatische Möglichkeit, Hyperscaler-Funktionen zu nutzen und gleichzeitig Souveränitätsbedenken zu berücksichtigen.

Schließlich sind Akteure wie IONOS und Orange Business wichtige Beiträger zu Initiativen wie GAIA-X. GAIA-X zielt darauf ab, eine föderierte europäische Dateninfrastruktur aufzubauen, die ein Ökosystem sicherer, vertrauenswürdiger und souveräner Cloud- und Datendienste schafft. Ihr Fokus liegt weniger auf der Souveränität eines einzelnen Anbieters als vielmehr auf der Schaffung eines vernetzten Netzwerks, in dem die Datensouveränität durch gemeinsame Standards, Interoperabilität und transparente Governance über mehrere europäische Entitäten hinweg gewahrt wird. Hier geht es um den Aufbau der nächsten Generation einer wirklich europäischen digitalen Infrastruktur.

Die Landschaft der Anbieter zu verstehen, ist eine Sache, aber wie können wir als Architekten für dieses Maß an Souveränität bauen? Lassen Sie uns in einige konkrete technische Muster eintauchen, die sich für mich als effektiv erwiesen haben.

Eines der wirkungsvollsten Muster, die ich für die Datensouveränität implementiert habe, ist die "Encryption Lockbox" mit External Key Management (EKM). Dies verlagert die ultimative Kontrolle über die Verschlüsselungsschlüssel Ihrer Daten aus dem direkten Einflussbereich des Cloud-Anbieters. Anstatt das native Key Management System (KMS) des Cloud-Anbieters zu verwenden, konfiguriere ich Dienste so, dass sie eine EKM-Lösung nutzen, bei der die Schlüssel von einem Drittanbieter für europäische Hardware Security Module (HSM), wie Thales oder Entrust, verwaltet werden.

Dieses Muster bedeutet, dass selbst wenn die Kontrollebene eines Cloud-Anbieters kompromittiert würde oder eine Nicht-EU-Jurisdiktion eine Datenanfrage stellen würde, der Cloud-Anbieter nur Zugriff auf verschlüsselte Daten hätte. Ohne die externen Schlüssel, die physisch und logisch von einer separaten, jurisdiktionell eigenständigen Entität kontrolliert werden, bleiben die Daten unlesbar. Es macht den Zugriff des Cloud-Anbieters für die Datenexfiltration effektiv nutzlos.

Wie ich bereits erwähnt habe, reicht es nicht aus, lediglich eine europäische Region für Ihre Daten auszuwählen. Kontrollebenen-Isolation bedeutet, aktiv von standardmäßigen "regionalen" Bereitstellungen zu den fortschrittlicheren "souveränen Partitions"-Bereitstellungen der Hyperscaler oder, noch besser, zu den völlig separaten Betriebsmodellen regionaler nativer Anbieter überzugehen. Dies beinhaltet die Sicherstellung, dass die APIs, Verwaltungskonsolen und zugrunde liegenden Orchestrierungsebenen alle innerhalb der designierten souveränen Umgebung verbleiben. Wenn ich Systeme entwerfe, überprüfche ich akribisch Netzwerkflüsse, API-Endpunkte und administrative Zugriffspfade, um sicherzustellen, dass kein kritischer Verwaltungsdatenverkehr unbeabsichtigt die souveräne Grenze überschreitet.

Für den ultimativen Datenschutz, selbst während der Verarbeitung, setze ich auf Zero-Trust-Souveränität, ermöglicht durch Confidential Computing. Technologien wie Intel SGX (Software Guard Extensions) und AMD SEV (Secure Encrypted Virtualization) ermöglichen es, Daten nicht nur im Ruhezustand und bei der Übertragung zu verschlüsseln, sondern auch im Speicher, während sie verarbeitet werden. Dies schafft eine vertrauenswürdige Ausführungsumgebung (TEE), die Daten und Code selbst vor dem Hypervisor oder Betriebssystem des Cloud-Anbieters schützt. Wenn ich mit hochsensiblen Daten arbeite, stellt dieses Muster sicher, dass weder der Cloud-Betreiber noch jemand mit Host-Level-Zugriff die Arbeitslast oder die von ihr verarbeiteten Daten "sehen" kann. Es ist ein Game-Changer für kritische Anwendungen, bei denen selbst eine vorübergehende unverschlüsselte Datenexposition inakzeptabel ist.