Die EU-Region eines US-Hyperscalers hält Ihre Daten physisch in Europa — rechtlich nicht. Wann Hetzner wirklich gewinnt, wann AWS EU weiterhin richtig ist, und wie Sie entscheiden.

EU-souveränes Cloud-Hosting bedeutet Infrastruktur, bei der alle drei Ebenen innerhalb der EU liegen: wo die Daten physisch liegen, welches Unternehmen die Plattform betreibt, und welches Rechtssystem Zugriff erzwingen kann. Eine Frankfurt-Region bei einem US-Hyperscaler liefert die erste Ebene — und nur die erste.

Die kurze Antwort: Unterliegt ein Anbieter der US-Jurisdiktion, erlaubt der CLOUD Act US-Behörden, ihn zur Herausgabe von Daten zu zwingen, die er kontrolliert — egal, in welchem Land die Server stehen. Das macht AWS oder GCP für deutsche Unternehmen nicht unbrauchbar — für die meisten Workloads ist eine EU-Region mit kundenverwalteten Schlüsseln ein vertretbares Setup. Aber es bedeutet: „Unsere Daten liegen in Frankfurt“ ist eine Aussage über Latenz, nicht über Souveränität. Und sobald man die rechtliche Frage von der ökonomischen trennt, taucht eine zweite Überraschung auf: Bei Dauerlast- und traffic-intensiven Workloads sind EU-Anbieter wie Hetzner nicht nur die souveräne Wahl — sie sind oft dramatisch günstiger. Der Trick besteht darin, zu wissen, welcher Ihrer Workloads wohin gehört.

Wir konzipieren Cloud-Plattformen für mittelständische DACH-Unternehmen über AWS, GCP und Hetzner hinweg, und diese Frage — „Ist unsere Frankfurt-Region tatsächlich compliant, und zahlen wir zu viel dafür?“ — ist zum häufigsten Einstieg in unsere Cloud-Architektur-Projekte geworden. Hier das ganze Bild.

Was der CLOUD Act tatsächlich erreicht

Der Clarifying Lawful Overseas Use of Data Act wurde 2018 US-Gesetz. Sein Kernmechanismus ist einfach: US-Behörden können einen Anbieter, der der US-Jurisdiktion unterliegt, zur Herausgabe von Daten in seinem „Besitz, seiner Obhut oder Kontrolle“ verpflichten — unabhängig davon, wo diese Daten gespeichert sind. Der physische Standort des Servers ist rechtlich irrelevant. Entscheidend ist, wer ihn kontrolliert.

Jahrelang beantworteten die Vertriebsfolien der Hyperscaler das mit Prozesssprache: Anfragen seien selten, würden vor Gericht angefochten, es gebe Transparenzberichte. Alles wahr. Dann, im Juni 2025, brach die Abstraktion in einem einzigen Satz zusammen. Vor einer Untersuchung des französischen Senats zur digitalen Souveränität wurde der Direktor für öffentliche und rechtliche Angelegenheiten von Microsoft France gefragt, ob er garantieren könne, dass die Daten französischer Bürger niemals ohne französische Genehmigung an US-Behörden übermittelt würden. Seine Antwort, unter Eid: „Nein, ich kann es nicht garantieren.“

Das ist kein Skandal — es ist schlicht das Gesetz, wie es geschrieben steht. Ein Anbieter mit Hauptsitz in den USA kann sich nicht vertraglich aus einem US-Gesetz herauswinden, und keine noch so große Investition in EU-Rechenzentren ändert die Jurisdiktion der Muttergesellschaft.

Für die meisten Unternehmen ist die praktische Exposition gering — CLOUD-Act-Anordnungen gegen gewöhnliche Mittelständler sind selten. Aber „selten“ trägt in vieler Compliance-Dokumentation eine schwere Last. Wenn Sie Gesundheitsdaten verarbeiten, kritische Infrastruktur betreiben, Kunden im öffentlichen Sektor bedienen oder Geschäftsgeheimnisse halten, die ein US-Wettbewerber gern läse, werden Ihr Betriebsrat, Ihr Datenschutzbeauftragter und zunehmend Ihre Unternehmenskunden die Jurisdiktionsfrage stellen. „Frankfurt-Region“ ist keine Antwort darauf.

„Dann nehmen wir eben die Sovereign Cloud“

Die Hyperscaler wissen das alles — deshalb gibt es die AWS European Sovereign Cloud: eine Investition von 7,8 Milliarden €, eine erste Region in Brandenburg, gestartet Anfang 2026, betrieben von einer deutschen Muttergesellschaft (AWS European Sovereign Cloud GmbH) nach deutschem Recht, mit EU-Bürgern als Geschäftsführern und der Zusage, dass Kundeninhalte und Metadaten innerhalb der EU-Grenzen bleiben.

Ehre, wem Ehre gebührt — das ist eine ernsthafte strukturelle Anstrengung, keine Marketing-Region. Für viele Organisationen wird es genügen. Aber wir erwiesen Ihnen einen schlechten Dienst, wenn wir das Kleingedruckte übersprängen: Die oberste Muttergesellschaft bleibt ein US-Konzern, und Rechtsexperten bezweifeln offen, ob die Konzernstruktur einer entschlossenen US-Gerichtsanordnung standhielte, die mit Beugestrafen gegen die Mutter bewehrt ist. Die Aussage von Microsoft France ist hier lehrreich — auch Microsoft betreibt EU-Rechenzentrumsregionen mit umfangreichen vertraglichen Schutzmaßnahmen, und die eigenen Juristen lehnten es ab, das Ergebnis zu garantieren.

Behandeln Sie „Sovereign Cloud“-Angebote also als Risikominderung, nicht als Risikobeseitigung. Wo der Unterschied zählt — und wo nicht — ist eine Entscheidung pro Workload, und genau deshalb gehört die Ökonomie an denselben Tisch.

Wo Hetzner wirklich gewinnt: die Ökonomie

Hetzner ist ein deutsches Hosting-Unternehmen, gegründet 1997, mit seinen Hauptrechenzentren in Falkenstein und Nürnberg (plus Helsinki für EU-Workloads). Ein deutscher Betreiber, deutsche Rechenzentren, deutsche Jurisdiktion — das Souveränitäts-Häkchen ist schlicht gesetzt, ohne Whitepaper, das erklärt, warum es kompliziert sei. Was die meisten Kunden überrascht, ist die zweite Hälfte: die Preisliste.

Der mit Abstand dramatischste Unterschied ist der Traffic. AWS berechnet rund 0,09 $/GB für Datenübertragung aus seinen EU-Regionen ins Internet (nach 100 GB/Monat gratis), mit Mengenrabatten, die erst bei zweistelligen Terabyte-Beträgen ins Gewicht fallen. Hetzner enthält 20 TB Traffic bei jedem Cloud-Server und berechnet darüber hinaus rund 1,19 €/TB.

Beim Compute zeigt sich dasselbe Muster, weniger extrem, aber für Always-on-Workloads dennoch entscheidend: Öffentliche Vergleiche haben äquivalente Hetzner-Ressourcen durchweg auf einen Bruchteil beziffert — häufig ein Drittel bis ein Fünftel — des On-Demand-Hyperscaler-Preises, sobald Storage und Traffic einbezogen sind. Wo sich das aufsummiert, ist die Dauerlast: die Datenbank, die rund um die Uhr läuft, die Datenpipeline, die jede Nacht verarbeitet, die API, die konstanten Traffic bedient. Hyperscaler-Preise sind für eine Elastizität gebaut, die Sie nicht nutzen; Sie zahlen einen Verfügbarkeitsaufschlag auf Kapazität, die Sie dauerhaft belegen.

Die Workloads, bei denen diese Rechnung am härtesten aufgeht:

• Dauerlast-Compute — Datenbanken, Kubernetes-Worker-Pools, Scheduler, interne Tools. Alles, was rund um die Uhr bei vorhersehbarer Last läuft.
• Egress-intensive Systeme — Media-Auslieferung, Backups und Disaster-Recovery-Replikation, Datenprodukte, die Dateien oder Feeds an Kunden ausliefern, Bewegung von ML-Trainingsdaten.
• Dev, Staging und CI — Umgebungen, die keine fünf Neunen und nichts Managed brauchen, aber klammheimlich ein Drittel vieler Hyperscaler-Rechnungen verschlingen.

Wo Hetzner verliert — und AWS EU die richtige Antwort ist

Das sagen wir Ihnen lieber jetzt als nach einer Migration: Hetzner ist Infrastruktur, keine Plattform. Es gibt kein RDS, kein BigQuery, kein SageMaker, kein Managed Kafka. Jeder Managed Service, auf den Sie sich heute stützen, wird zu etwas, das Ihr Team betreibt — oder das wir containerisieren, automatisieren und mit Runbooks übergeben. Das ist mit modernem Tooling gut machbar, aber es ist nicht kostenlos, und etwas anderes zu behaupten ist der Weg, auf dem „günstiges Hosting“ zur Ops-Krise wird.

Hinzu kommt der Aspekt der Compliance-Zertifizierung, der in beide Richtungen schneidet: Hyperscaler bringen BSI-C5-Testate, ISO-Stacks und Audit-Artefakte mit, die Einkaufsabteilungen von Großunternehmen auf den ersten Blick anerkennen. Wenn Ihr Vertriebszyklus in diesem Quartal von diesen Dokumenten abhängt, ist das ein legitimer Grund, auf AWS EU zu sein — Souveränitätsdebatten bezahlen keine Rechnungen.

Der Data Act hat gerade die Exit-Rechnung verändert

Eine weitere Variable hat sich kürzlich bewegt. Der EU Data Act gilt seit dem 12. September 2025, und seine Bestimmungen zum Cloud-Wechsel zielen direkt auf Lock-in: Anbieter müssen Wechselhindernisse beseitigen, Wechselgebühren sind während einer Übergangsphase auf nachweisbare Kosten gedeckelt, und ab dem 12. Januar 2027 sind Gebühren für den Wechselvorgang — einschließlich des Daten-Egress beim Wegzug — vollständig verboten. Die Hyperscaler sahen es kommen: AWS erlässt Kunden, die die Plattform vollständig verlassen, den Egress bereits seit März 2024 auf Anfrage.

Der alltägliche operative Egress bleibt unberührt — der 0,09-$/GB-Zähler läuft weiter, solange Sie bleiben. Aber die einmalige Mautstation am Ausgang wird abgebaut, was das strategische Kalkül verändert: Die Kosten, eine Workload-Klasse in Hetzner auszuprobieren oder sein Estate aufzuteilen, waren nie niedriger. Vendor-Lock-in ist zunehmend eine Funktion Ihrer Architektur (proprietäre Managed Services, per Konsole gebaute Infrastruktur) und nicht des Preismodells Ihres Anbieters — und genau diesen Teil können Sie mit Infrastructure-as-Code wegkonstruieren.

Ein pragmatischer Entscheidungsrahmen

Wir führen das nicht als Glaubenskrieg — Hyperscaler gegen Bare Metal —, sondern als Sortierung pro Workload. Die Version unten ist verdichtet aus dem, was wir in den ersten zwei Wochen eines Projekts tun:

1. 01

   Daten nach Souveränitätsanforderung klassifizieren

   Sortieren Sie jede Datenklasse in drei Töpfe: darf niemals für eine Nicht-EU-Jurisdiktion erreichbar sein (Gesundheitsdaten, öffentlicher Sektor, betriebsratssensible HR-Daten, Kronjuwelen-IP), sollte mit Schutzmaßnahmen EU-ansässig bleiben (die meisten personen- und geschäftsbezogenen Daten) und standortunabhängig (öffentliche Assets, kurzlebiges Compute). Die meisten Unternehmen stellen fest, dass der erste Topf 10–20 % ihres Estates ausmacht — nicht 100 % und nicht 0 %.

   ⏱ Schritt 1

2. 02

   Die Workload-Form profilieren

   Ziehen Sie 12 Monate Abrechnungsdaten und trennen Sie Dauerlast von elastischem Verbrauch. Alles, was rund um die Uhr über ~60 % Durchschnittsauslastung läuft, ist ein Kandidat für feste EU-Infrastruktur; wirklich sprunghafte Workloads verdienen ihren Hyperscaler-Aufschlag. Markieren Sie egress-intensive Systeme separat — sie sind meist die schnellsten Erfolge.

   ⏱ Schritt 2

3. 03

   Den Exit einpreisen, nicht nur das Hosting

   Schätzen Sie für jeden Managed Service das selbst betriebene Äquivalent ehrlich ein: Software, Engineering-Stunden, On-Call-Last. Manche Wechsel sind nahezu kostenlos (Object Storage, Container-Runtime); manche sind teuer (ein gut getuntes BigQuery). Wo der Wechsel teuer ist, ist das Bleiben mit kundenverwalteten Schlüsseln und einer dokumentierten Transfer-Folgenabschätzung die vernünftige Antwort.

   ⏱ Schritt 3

4. 04

   Das Estate aufteilen — in Code

   Der Endzustand ist meist hybrid: Topf-eins-Daten und Dauerlast-Compute auf Infrastruktur unter EU-Jurisdiktion (Hetzner oder ähnlich), elastische und von Managed Services abhängige Workloads auf AWS/GCP-EU-Regionen mit CMK-Verschlüsselung. Alles in Terraform oder Pulumi, sodass die Grenze zwischen beiden eine Variable ist, kein Rewrite.

   ⏱ Schritt 4

Genau diese hybride Aufteilung haben wir für einen Kunden im Gesundheitswesen gebaut, dessen patientennahe Daten rechtlich nicht unter US-Jurisdiktion liegen durften: Die EU-souveräne Customer Data Platform betreibt den sensiblen Kern auf EU-Infrastruktur und hält zugleich die Tür für elastische Workloads anderswo offen. Keine Single-Vendor-Reinheit — nur jeder Workload dort, wo er vertretbar und am günstigsten ist.

Übrigens halten wir uns an dieselbe Sortierung: diese Website, unsere Analytics und unser internes Tooling laufen auf Hetzner — Dauerlast, egress-arm, sauber bei der Jurisdiktion und langweilig im besten Sinne. Das Burst-Compute unserer Kunden läuft dort, wo Burst-Compute hingehört.

Nicht sicher, in welchen Topf Ihre Workloads fallen?

Schicken Sie uns eine grobe Skizze Ihres Stacks und Ihre Cloud-Rechnung des letzten Quartals. Wir sagen Ihnen, was wirklich EU-Jurisdiktion braucht, was für nie genutzte Elastizität zu viel zahlt, und was genau dort bleiben sollte, wo es ist.