Sovereign Cloud in Europa: Residenz ist nicht dasselbe wie Jurisdiktion.

Diese Seite bietet die Engineering-Perspektive. Wenn Ihr DPO, Ihr Auditor oder eine Einkaufsprüfung fragt, was „souverän“ im Jahr 2026 tatsächlich bedeutet, ist dies die Version, die einer genauen Prüfung standhält.

Residenz vs. Souveränität: die Unterscheidung, die alles entscheidet

Die Cloud-Branche hat Käufer fünfzehn Jahre lang darauf trainiert, die falsche Frage zu stellen. „Wo werden die Daten gehostet?“ ist eine Residenzfrage. Die Antwort kann technisch korrekt und rechtlich bedeutungslos zugleich sein, denn Souveränität hat nichts mit Geografie zu tun. Es geht darum, welche Gerichte einen Anbieter zum Handeln zwingen können.

Eine EU-Region bei einem US-Hyperscaler, wie AWS Frankfurt, Azure West Europe oder GCP Belgien, hält die Bits in der EU. Sie entfernt das Mutterunternehmen nicht aus der US-Rechtsprechung. Unter dem US CLOUD Act (2018) kann ein Anbieter mit Hauptsitz in den USA gezwungen werden, Kundendaten offenzulegen, die überall auf der Welt gespeichert sind, einschließlich in EU-Regionen. FISA 702 bringt dieselbe Gefährdung für den Überwachungsaspekt mit sich. Der Europäische Datenschutzausschuss hat dies explizit als Schrems-II-Problem eingestuft.

"Sovereign" bedeutet also drei konkrete Dinge, gleichzeitig:

1. Die juristische Einheit, die Ihre Daten hält, hat kein Mutterunternehmen in einem Drittstaat mit extraterritorialen Gesetzen zur Datenoffenlegung.
2. Auch kein Subprozessor im Datenpfad befindet sich in einem solchen Land.
3. Sie, nicht der Anbieter, kontrollieren die Verschlüsselungscodes, oder die Schlüssel liegen bei einem Treuhänder außerhalb des Drittlands.

Bestehen Sie alle drei Kriterien, haben Sie Souveränität. Scheitern Sie an einem davon, haben Sie Residenz. Die Terminologie in Ihrem DPA, Ihrer Datenschutzrichtlinie und Ihren kundenseitigen Seiten sollte widerspiegeln, um welches der beiden es sich tatsächlich handelt.

Warum „EU-Tochtergesellschaft“ nicht die Antwort ist

Eine gängige Ausweichlösung der US-Hyperscaler ist die Struktur der EU-Tochtergesellschaft. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. Das Argument lautet, dass die europäische Einheit der Vertragspartner nach EU-Recht ist.

Dies löst das jurisdiktionelle Problem nicht. Nach dem CLOUD Act ist nicht entscheidend, welche Tochtergesellschaft den Vertrag unterschrieben hat. Entscheidend ist, ob das Mutterunternehmen „Besitz, Verwahrung oder Kontrolle“ über die Daten hat. Eine hundertprozentige EU-Tochtergesellschaft wird konstruktionsbedingt vom Mutterunternehmen kontrolliert. Die Analyse des EuGH und des EDSA in Schrems II betrachtet die Exposition des Mutterunternehmens als maßgeblich.

Wenn ein Anbieter also einen „europäischen“ Tarif anbietet, der von einer EU-Tochtergesellschaft einer US-Gruppe betrieben wird, lautet die richtige Frage: „Kann Ihr US-Mutterunternehmen gezwungen werden, Sie zur Offenlegung von Daten ohne unsere Zustimmung oder unser Wissen anzuweisen?“ Die ehrliche Antwort ist Ja.

Die pseudo-souveräne Mittelschicht

2024 bis 2026 kam eine Welle angekündigter "Sovereign"-Partnerschaften, bei denen typischerweise ein europäischer Systemintegrator den Technologie-Stack eines US-Hyperscalers lizenziert und unter europäischer Verwaltung betreibt. Beispiele im heutigen Markt:

• Lizenzierte Sovereign-Angebote, aufgebaut auf US-Hyperscaler-Technologie, betrieben von einer europäischen Telekom-Tochtergesellschaft.
• Bleu, eine französische Sovereign Cloud auf Basis der Microsoft Azure-Technologie, betrieben von Capgemini und Orange.
• S3NS, ein Joint Venture von Thales und Google in Frankreich.

Diese Angebote können für bestimmte Compliance-Regime nützlich sein, sind aber nicht das, was ein Engineering-Team ohne Einschränkung als souverän bezeichnen sollte. Der Technologie-Stack, die Plattform-Updates, die Sicherheitspatches und - entscheidend - das operative Know-how stammen vom US-Partner. Im Worst-Case-Szenario, in dem die US-Seite die Zusammenarbeit einstellt oder dazu gezwungen wird, erbt der europäische Betreiber einen Stack, den er nicht eigenständig warten kann.

Für die meisten Käufer ist die saubere architektonische Antwort, auf einer Infrastruktur aufzubauen, bei der überhaupt keine US-Abhängigkeit in der Lieferkette besteht. Genau das meinen wir bei Binadit, wenn wir von einem souveränen Stack sprechen.

Wie ein souveräner EU-Stack tatsächlich aussieht

Hier ist eine konkrete Referenzarchitektur für einen Mid-Market-SaaS- oder regulierten Workload, der vollständig unter EU-Jurisdiktion läuft. Keine davon ist exotisch; alle sind produktionsreif.

• Compute & Storage: Binadit Managed Compute und dedizierte Hardware, auf EU-Infrastruktur unter EU-Gerichtsbarkeit.
• Object Storage: Ceph oder MinIO, S3-kompatibel, von uns auf derselben Infrastruktur betrieben.
• CDN: Bunny.net (SI), KeyCDN (CH), oder self-managed am Edge für volle Kontrolle.
• DNS: PowerDNS oder Knot, autoritativ und DNSSEC-signiert, oder Bunny DNS, wenn Sie es gebündelt mit dem CDN wünschen.
• E-Mail-Zustellung: Mailgun EU (mit Vorsicht, wegen des US-Mutterkonzerns), oder vollständig EU-basierte Optionen wie Postmark EU, Mailpace, Tuta Business, oder self-hosted Postfix auf derselben Infrastruktur.
• Error Tracking: Self-hosted GlitchTip oder Sentry, oder Sentrys EU-Region-Deployment mit dokumentierten Kompromissen.
• Analytics: Plausible (EU-gehostet), Matomo (self-hosted oder EU Cloud), Pirsch.
• Observability: Selbst gehostetes Prometheus + Grafana + Loki, oder EU-verwaltete Äquivalente (Grafana Cloud EU, Last9 mit EU-Region).
• Key Management: Hashicorp Vault auf EU-Infrastruktur, oder EU-verwaltete KMS-Anbieter; für High-Trust-Szenarien On-Premises-HSM mit Cloud-seitigem BYOK.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, oder die GitLab.com EU-Instanz. Niemals das Standard-github.com für Code, der personenbezogene Daten betrifft, ohne zusätzliche Maßnahmen.

Der Punkt ist nicht, dass eine dieser Optionen „die“ Antwort ist. Der Punkt ist, dass der gesamte Stack mit Anbietern mit Hauptsitz in der EU zusammengestellt werden kann und ein Managed-Infrastructure-Partner ihn genauso betreiben kann, wie ein AWS-nativer Partner AWS betreiben würde.

Der Vier-Fragen-Test im Detail

1. Speicherort: wo, genau

Nicht "in der EU", sondern welches Rechenzentrum, in welchem Land, unter welcher Jurisdiktion. Die EU ist kein einheitliches Rechtsregime; die GDPR ist harmonisiert, aber die Aufsichtsbehörde ist lokal, und ebenso der Rechtsweg, falls ein Anbieter ausfällt. Dokumentieren Sie den Ländercode für primäre, sekundäre und Backup-Standorte in Ihrer DPA.

2. Subprozessoren: jeder Einzelne von ihnen

In unseren Audits von Mid-Market-Umgebungen ist die nicht erfasste Subprozessor-Kette der häufigste Befund. Die Anwendung läuft auf EU-Infrastruktur, was gut ist. Aber die aufgerufene Bildoptimierungs-API ist in den USA gehostet. Die Transaktions-E-Mail wird über einen US-ESP versendet. Der Error-Tracker ist die US-Standardlösung. Das Customer-Support-Widget lädt JavaScript von einem US-CDN. Jeder davon ist ein separater Datenfluss. Jeder benötigt eine Rechtsgrundlage, wenn Daten in ein Drittland übertragen werden.

Ein souveräner Stack erfordert eine vollständige Subprozessoren-Liste, einschließlich der Drittanbieter-APIs, die Ihre Anwendung aufruft, nicht nur der Infrastrukturanbieter. Unsere wird vollständig im Auftragsverarbeitungsvertrag genannt, und wir senden sie, bevor Sie etwas unterschreiben.

3. Gerichtsbarkeit: wer Offenlegung erzwingen kann

Die Frage des Rechtsverfahrens. Ermitteln Sie für jede Einheit in Ihrem Datenpfad den Hauptsitz des Mutterunternehmens. Befindet sich ein Mutterunternehmen in den USA, China, Russland oder einem anderen Land mit extraterritorialen Gesetzen zum Datenzugriff, ist diese Einheit exponiert. Der Status als EU-Tochtergesellschaft eines US-Mutterunternehmens löst das Problem nicht.

Hier wird das Architekturdiagramm zu einem juristischen Dokument. Einmal zeichnen, vierteljährlich überprüfen.

4. Schlüsselverwahrung: wer die Daten technisch lesen kann

Verschlüsselung im Ruhezustand ist notwendig, aber nicht ausreichend. Die Frage ist, wer die Schlüssel besitzt. Vom Anbieter verwaltete Schlüssel bieten keinen Schutz, wenn der Anbieter zur Entschlüsselung gezwungen wird. BYOK (Bring Your Own Key) hilft der Compliance-Argumentation; der Anbieter hält weiterhin eine Laufzeitkopie. HYOK (Hold Your Own Key) ist das einzige Modell, bei dem der Cloud-Anbieter die Daten physisch nicht lesen kann, ohne einen aktiven Aufruf an Ihren Schlüsselverwalter zu tätigen. Wählen Sie das Modell, das das Bedrohungsmodell erfordert.

Der Migrationspfad: von AWS Frankfurt zu einem souveränen Stack

Die Angst, sich von einem Hyperscaler zu lösen, ist meist größer als das eigentliche Projekt. Eine typische Migration im Mid-Market-Bereich läuft in drei Phasen ab:

1. Bestandsaufnahme und Audit (1-2 Wochen). Kartieren Sie jeden Datenfluss, identifizieren Sie jeden Subprozessor, klassifizieren Sie nach US-Exposition. Ergebnis: eine nach Risiko und Migrationskomplexität geordnete Sanierungsliste.
2. Quick-Win-Entfernungen (2-4 Wochen). Ersetzen Sie zuerst die weichen Abhängigkeiten: Error Tracking, Analytics, CDN, DNS, E-Mail. Diese lassen sich mit wenig oder keiner Anwendungsänderung migrieren.
3. Kernmigration (4-8 Wochen). Compute, Storage, Datenbank. Nutzen Sie Streaming-Replikation für Datenbank-Umzüge ohne Ausfallzeit; nutzen Sie Blue-Green- oder DNS-Failover-Muster auf der Anwendungsebene. Der schwierige Teil ist selten die Technologie. Es ist die Choreografie.

Gesamtaufwand für ein 6-8-köpfiges Engineering-Team, das dies neben dem Tagesgeschäft erledigt: zehn bis sechzehn Wochen. Mit einem Managed-Infrastructure-Partner, der die Migration vorantreibt, vier bis zwölf. Der Kostenunterschied zwischen dem Betrieb des souveränen Stacks und dem Hyperscaler ist unserer Erfahrung nach bei vorhersehbaren Workloads neutral bis negativ, bei Workloads mit Lastspitzen leicht höher und, sobald Egress und Bandbreite berücksichtigt werden, deutlich niedriger.

Ist Sovereign Cloud teurer? Die ehrliche Antwort

Bei 80% der Mid-Market-Workloads ist der souveräne Stack über fünf Jahre günstiger, hauptsächlich weil EU-Anbieter keine strafenden Egress-Gebühren erheben und weil dedizierte und Bare-Metal-Preise deutlich besser sind als vergleichbare Hyperscaler-Instanztypen. Die Fälle, in denen der souveräne Stack teurer ist, sind: stark bursthafte Workloads, die von Sub-Sekunden-Autoscaling profitieren, Workloads, die auf einen bestimmten Managed Service (DynamoDB, BigQuery, Lambda) setzen, für den es keine saubere Entsprechung gibt, und ML-Trainings-Workloads, die eine bestimmte Accelerator-Generation erfordern.

Eine kompetente technische Prüfung sagt Ihnen innerhalb einer Woche, in welcher Kategorie Sie sich befinden. Falls Sie eine wünschen, das ist unser Kerngeschäft.

Regulatorischer Rückenwind: NIS2, DORA, EHDS und AI Act

Die regulatorische Entwicklungsrichtung bis 2027 geht in Richtung strengerer Verantwortlichkeit in der Lieferkette:

• NIS2 (Artikel 21): Wesentliche und wichtige Einrichtungen müssen Risikobewertungen der Lieferkette durchführen und Sicherheitsverpflichtungen vertraglich an Subprozessoren weitergeben. Ein Subprozessor unter US-Gerichtsbarkeit ist in dieser Bewertung ohne zusätzliche Maßnahmen schwer zu rechtfertigen.
• DORA (in Kraft seit Januar 2025): Finanzunternehmen müssen ein Register der ICT-Drittanbieter sowie eine Exit-Strategie für kritische Anbieter führen. Die Formulierung zum Konzentrationsrisiko zielt explizit auf die Abhängigkeit von dominanten Nicht-EU-Anbietern ab.
• European Health Data Space (EHDS): Die Sekundärnutzung von Gesundheitsdaten ist auf Verarbeitungsumgebungen unter EU-Gerichtsbarkeit beschränkt.
• EU AI Act: Hochrisiko-KI-Systeme erfordern eine nachvollziehbare Herkunft der Trainingsdaten, was bei einer US-Foundation-Model-API praktisch sehr schwierig ist.

Keine dieser Regulierungen verbietet US-Anbieter. Sie erhöhen den Dokumentations- und Zusatzmaßnahmenaufwand so stark, dass ein souveräner Stack für die meisten Anwendungsfälle die reibungsärmere Wahl ist.

Was wir nicht behaupten

Um ehrlich zu sein: Es gibt Workloads, bei denen ein souveräner EU-Stack schwieriger ist als ein Hyperscaler. Multi-Region Active-Active mit globaler Latenz unter 50ms. Bestimmte Managed-Analytics-Warehouses. Hyperscale-ML-Inferenz auf den neuesten Accelerators. Wir sagen Ihnen, wenn Ihr Workload in diese Kategorie fällt. Bei 90% der SaaS-, E-Commerce-, B2B-Plattformen und regulierten Workloads, die wir sehen, ist der souveräne Stack nicht nur konform. Er ist auch schneller, günstiger und leichter nachvollziehbar.

Wo Binadit ansetzt

Wir sind ein Auftragsverarbeiter gemäß Artikel 28 mit Hauptsitz in Rotterdam, Niederlande. Unsere Infrastruktur läuft zu 100 % über Anbieter mit Hauptsitz in der EU. Unsere Liste der Subunternehmer ist vollständig im Auftragsverarbeitungsvertrag benannt und auf Anfrage verfügbar. Wir übernehmen keine Aufträge, die im Standard-Datenpfad einen Subunternehmer unter US-Jurisdiktion erfordern würden. Falls ein Workload tatsächlich einen solchen benötigt (z. B. eine SaaS-Lösung eines Drittanbieters, auf der der Kunde besteht), dokumentieren wir dies schriftlich, ergänzen die zusätzlichen Maßnahmen und legen das Restrisiko vor Vertragsunterzeichnung dem DPO offen.

Wenn das nach der Art von Partner klingt, nach der Sie gesucht haben, ist der nächste Schritt ein 30-minütiges Scoping-Gespräch.