digital independence
Fakten statt Hype.
Open Source ehrlich und unpolitisch bewertet.
EN DE FR

Cloud-Infrastruktur

Europas Cloud: Souveränität vs. Skala

Auf dem globalen Markt für Cloud-Infrastruktur halten drei Unternehmen etwa 65–70 % Marktanteil: Amazon Web Services, Microsoft Azure und Google Cloud Platform. Alle drei sind US-Unternehmen, dem US-Recht unterworfen — einschließlich des CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), der es US-Behörden ermöglicht, US-Anbieter per Gerichtsbeschluss oder Subpoena zur Herausgabe von Daten zu zwingen — unabhängig davon, wo diese physisch gespeichert sind. Anbieter können solche Anordnungen gerichtlich anfechten, aber die jurisdiktionelle Exponierung bleibt.

Eine verbreitete Risikominderung besteht darin, ein europäisches Rechenzentrum eines US-Anbieters zu wählen. Das reduziert einige Risiken — Latenz, bestimmte Datenresidenz-Anforderungen — löst aber die Zuständigkeitsfrage nicht. Die Daten bleiben unter der Kontrolle eines US-Unternehmens, das dem US-Recht unterliegt. Das EU-US Data Privacy Framework (2023) bietet zusätzliche rechtliche Garantien für transatlantische Datenübertragungen — ist aber der dritte Anlauf, nach Safe Harbor (gekippt 2015) und Privacy Shield (gekippt 2020), die beide vom Europäischen Gerichtshof in den Schrems-I- und Schrems-II-Urteilen für ungültig erklärt wurden. Max Schrems hat signalisiert, dass er auch dieses Framework anfechten könnte. Seine langfristige Stabilität ist eine offene Frage.

In Europa ist das Bild noch deutlicher. US-Hyperscaler kontrollieren rund 70 % des europäischen Cloud-Marktes. Europäische Anbieter — OVHcloud, Hetzner, IONOS, Scaleway und Dutzende kleinerer Betreiber — kommen zusammen auf rund 15 %. Der Rest verteilt sich auf kleinere internationale Anbieter.

Das sind nicht nur Marktanteile. Sie beschreiben eine Abhängigkeit: Die Mehrheit der europäischen Unternehmen, öffentlichen Verwaltungen und zunehmend auch kritischen Infrastrukturen läuft auf Rechenressourcen unter US-Jurisdiktion. Die Frage ist nicht, ob ein Konzentrationsrisiko auf diesem Niveau ein Problem darstellt — jeder Risikomanager würde eine 70-prozentige Abhängigkeit von Anbietern unter einer einzigen ausländischen Jurisdiktion anmerken. Das Europäische Parlament hat genau das festgestellt. Die Frage ist, warum es fortbesteht und was — realistisch betrachtet — dagegen getan werden kann.

Der Preis-Mythos

Fragen Sie einen CTO, warum er AWS nutzt, und die Antwort lautet in der Regel eine Kombination aus „Ökosystem", „Managed Services" und „es funktioniert einfach". Selten sagt jemand „weil es billig ist". Und das hat seinen Grund.

Ein Vergleich gleichwertiger Rechenressourcen erzählt eine Geschichte, die der gängigen Meinung widerspricht. Ein dedizierter Server mit 64 GB RAM und einem 8-Kern-AMD-Ryzen-Prozessor bei Hetzner kostet etwa 40–50 € pro Monat. Eine vergleichbare EC2-Instanz auf AWS — etwa eine m6a.2xlarge — liegt bei rund 280 $ pro Monat, also mehr als fünfmal so viel. Der Abstand verringert sich etwas, wenn man Reserved Instances und Savings Plans einbezieht, aber selbst dann liegt der Preisaufschlag der US-Hyperscaler typischerweise beim 3–5-Fachen für Compute und 5–10-Fachen für Storage.

Das ist kein Geheimnis. Jedes europäische Startup, das über seine Anfangsfinanzierung hinausgewachsen ist, hat nachgerechnet. Was Organisationen bei Hyperscalern hält, ist nicht der Preis — es ist das Ökosystem. Managed Databases, serverlose Funktionen, Machine-Learning-APIs, Identitätsdienste, Monitoring, CDN, Dutzende vorintegrierter Dienste, die bei einem europäischen Anbieter jeweils einzeln aufgesetzt, gewartet und mit eigenem Know-how betrieben werden müssten. Die Managed-Service-Schicht ist der Burggraben, nicht die virtuelle Maschine.

Für Organisationen mit Standard-Workloads — Webanwendungen, Datenbanken, Dateispeicher, CI/CD-Pipelines — bieten europäische Anbieter ernstzunehmende Alternativen zu einem Bruchteil der Kosten. Für Organisationen, die tief in proprietäre Hyperscaler-Dienste eingebettet sind (Lambda, DynamoDB, BigQuery), ist der Wechsel teuer und komplex. Diese Unterscheidung ist entscheidend, denn sie bestimmt, ob eine Migration ein Wochenendprojekt oder ein Mehrjahresprogramm ist.

Die EUCS-Saga

Wer verstehen will, warum die europäische Cloud-Souveränität in dem Tempo vorankommt, in dem sie vorankommt, muss sich nur das EU Cloud Certification Scheme ansehen — EUCS.

2020 von ENISA (der EU-Cybersicherheitsagentur) vorgeschlagen, sollte EUCS Sicherheitsstufen für Cloud-Dienste definieren, die von EU-Regierungen und kritischen Infrastrukturen genutzt werden. Drei Stufen waren geplant: Basic, Substantial und High. Die „High"-Stufe sollte in den frühen Entwürfen Souveränitätsanforderungen enthalten — der Cloud-Anbieter hätte frei von nicht-europäischer Jurisdiktion sein müssen, mit Datenverarbeitung ausschließlich in Europa durch Einrichtungen unter europäischer Kontrolle.

Frankreich war die treibende Kraft dahinter. Paris hatte bereits ein eigenes nationales Schema, SecNumCloud, betrieben von der ANSSI (der französischen Cybersicherheitsbehörde). SecNumCloud verlangt, dass der Cloud-Anbieter mehrheitlich im Besitz von EU-Einrichtungen ist und dass kein außereuropäisches Recht zur Datenherausgabe zwingen kann. De facto eine Souveränitätsanforderung. Frankreich wollte, dass EUCS High mit SecNumCloud kompatibel ist — oder zumindest nicht schwächer.

Die US-Hyperscaler lobbyierten erwartungsgemäß massiv gegen Souveränitätsanforderungen. Ihr Argument: Der Ausschluss von US-Anbietern aus der höchsten Zertifizierungsstufe sei protektionistisch, schränke die Auswahl ein und verbessere nicht die Sicherheit. Mehrere EU-Mitgliedstaaten — insbesondere die Niederlande und die nordischen Länder — teilten diese Position und argumentierten, Souveränitätsanforderungen würden die leistungsfähigsten Anbieter aussperren.

Das Ergebnis nach über vier Jahren Verhandlung: Die Souveränitätsanforderungen wurden aus dem EUCS-Entwurf gestrichen. Die „High"-Stufe konzentriert sich nun auf technische Sicherheitsmaßnahmen — Verschlüsselung, Zugriffskontrollen, Audit-Logging — verlangt aber weder europäischen Besitz noch europäische Jurisdiktion. Frankreich äußerte Enttäuschung, blockierte das Schema aber nicht und entschied sich stattdessen, SecNumCloud als nationale Ergänzung beizubehalten.

Die EUCS-Saga illustriert die Schwierigkeit, Souveränitätsanforderungen zu definieren, die alle Beteiligten akzeptieren. Das Schema, das am Ende herauskommen wird, ist besser als nichts — aber es ist nicht das, was das Wort „Souveränität" impliziert.

Gaia-X: Die Konferenz, die ein Projekt wurde

Keine Diskussion über europäische Cloud-Souveränität ist vollständig, ohne Gaia-X zu erwähnen. Und keine Diskussion über Gaia-X ist vollständig ohne eine gewisse Ermüdung.

2019 von Deutschland und Frankreich mit großem Elan gestartet, sollte Gaia-X die europäische Antwort auf die Hyperscaler-Dominanz sein: eine föderierte Dateninfrastruktur auf Basis gemeinsamer Standards, die es europäischen Anbietern ermöglicht, interoperable Dienste nach europäischen Regeln anzubieten. Die Vision war überzeugend. Die Umsetzung war — um es höflich auszudrücken — langsam.

Bis 2024 hatte die Gaia-X Association über 350 Mitglieder. Darunter: AWS, Microsoft und Google. Die Organisation, die die Abhängigkeit von US-Hyperscalern verringern sollte, hatte die US-Hyperscaler eingeladen, die Regeln mitzugestalten. Das ist entweder Pragmatismus oder Absurdität, je nach Perspektive.

Was Gaia-X hervorgebracht hat, sind Standarddokumente, Compliance-Rahmenwerke und ein Trust Framework zur Kennzeichnung von Diensten. Was es nicht hervorgebracht hat, ist irgendetwas, das ein Systemadministrator an einem Montagmorgen installieren könnte. Die Gaia-X Digital Clearing Houses — zur Überprüfung der Compliance gedacht — haben sich nur langsam materialisiert. Leuchtturmprojekte existieren, bleiben aber Nische.

Die wohlwollende Lesart: Gaia-X ist eine Standardisierungsorganisation, kein Cloud-Anbieter. Standards brauchen Zeit. Die weniger wohlwollende Lesart: Gaia-X ist zum Symbol europäischer Ankündigungskultur geworden — viel diskutiert, gut dokumentiert, nie installiert.

Sovereign Cloud Stack: Der stille Erfolg

Wenn Gaia-X die Konferenz ist, dann ist Sovereign Cloud Stack (SCS) der Code.

Finanziert durch das Bundesministerium für Wirtschaft und Klimaschutz (BMWK) über das Gaia-X-Förderprogramm, verfolgte SCS einen anderen Ansatz: Statt Standards abstrakt zu definieren, wurde eine Referenzimplementierung gebaut. Der Stack basiert auf OpenStack für die Infrastruktur, Kubernetes für die Container-Orchestrierung und Keycloak für das Identitätsmanagement — alles Open Source, alles in der Praxis erprobt.

Der praktische Wert von SCS ist Interoperabilität: Workloads, die auf einer SCS-zertifizierten Cloud laufen, können ohne Änderung auf eine andere SCS-zertifizierte Cloud verschoben werden. Das adressiert direkt den Vendor Lock-in — nicht durch Regulierung, sondern durch Architektur.

Mehrere deutsche Anbieter haben SCS übernommen: plusserver, REGIO.cloud, Wavecon und andere. Die Verbreitung ist im Vergleich zur Hyperscaler-Dimension bescheiden, aber sie beweist, dass das Konzept funktioniert.

Die Herausforderung kam Ende 2024, als die BMWK-Förderung auslief. SCS wurde in eine Community-Governance unter der Open Source Business Alliance (OSBA) überführt. Ob ein community-finanziertes Projekt das Momentum eines staatlich geförderten aufrechterhalten kann, ist eine offene Frage. Der Code ist solide. Die Frage ist, ob das Ökosystem drumherum schnell genug wachsen wird.

Wenn die physische Realität zuschlägt: Der OVH-Brand

Am 10. März 2021 zerstörte ein Feuer das Rechenzentrum SBG2 in Straßburg, betrieben von OVHcloud — dem größten europäischen Cloud-Anbieter. 3,6 Millionen Websites gingen offline. Kundendaten gingen verloren. Das Feuer beschädigte auch die benachbarte Anlage SBG1.

Der Vorfall offenbarte eine unbequeme Wahrheit: Manche Kunden hatten angenommen, dass „Cloud" automatische geografische Redundanz bedeutet. Das tat es nicht. Die günstigeren Angebote von OVHcloud enthielten keine Off-Site-Backups als Standard. Kunden, die nicht explizit eine Multi-Site-Replikation konfiguriert hatten, verloren Daten unwiederbringlich.

Das Feuer bewies nicht, dass europäische Anbieter unzuverlässig sind. Brände in Rechenzentren können überall passieren — ein Brand in einer Cyxtera-Anlage (USA) in London verursachte 2022 ähnliche Störungen. Was der OVH-Brand zeigte: „Günstiger" bedeutet oft „weniger Standardleistungen". Hyperscaler integrieren geografische Redundanz in ihre Standardarchitektur. Europäische Anbieter, die über den Preis konkurrieren, bieten sie häufig als Option an. Für Organisationen, die von AWS zu Hetzner oder OVH migrieren, ist das Verständnis dessen, was nicht standardmäßig enthalten ist, ebenso wichtig wie der Preisvergleich.

Die nationalen Strategien

Während die EU über Zertifizierungsschemata debattiert, haben einzelne Mitgliedstaaten ihre eigenen Cloud-Souveränitätsstrategien aufgebaut — mit unterschiedlichem Ambitionsniveau und Erfolg.

Frankreich: SecNumCloud und Bleu

Frankreich hat den am weitesten entwickelten nationalen Rahmen. SecNumCloud, betrieben von der ANSSI, setzt strenge Souveränitätsanforderungen. Zertifizierte Anbieter müssen mehrheitlich im Besitz von EU-Einrichtungen sein. Kein außereuropäisches Recht darf auf die Daten Anwendung finden.

Das sichtbarste Ergebnis ist Bleu — ein Joint Venture von Orange und Capgemini, gestartet 2024, das Microsoft 365 und Azure-Dienste unter SecNumCloud-Zertifizierung betreibt. Das Konzept: Microsofts Software, aber auf französisch kontrollierter Infrastruktur, betrieben von französischen Einrichtungen, unter französischem Recht. Microsoft stellt die Technologie per Lizenz bereit; Bleu betreibt sie.

Das ist ein pragmatischer Kompromiss. Er gibt französischen Regierungsbehörden Zugang zu den vertrauten Microsoft-Werkzeugen und wahrt zugleich die rechtliche Souveränität über die Daten. Kritiker argumentieren, dass die tiefere Abhängigkeit damit nicht adressiert wird — Frankreich bleibt auf Microsofts Software, Updates und Roadmap angewiesen. Befürworter entgegnen, dass das Perfekte nicht der Feind des Guten sein sollte: Wenn die Alternative Regierungsdaten auf US-kontrolliertem Azure sind, ist Bleu eine substanzielle Verbesserung.

Deutschland: Delos Cloud und SCS

Deutschland verfolgt zwei parallele Pfade. Der Sovereign Cloud Stack, oben beschrieben, repräsentiert den Open-Source-Weg. Delos Cloud — ein Joint Venture von SAP und Arvato Systems (Bertelsmann) — spiegelt das französische Bleu-Modell: Microsoft-365-Dienste, betrieben unter deutscher Souveränität durch deutsche Einrichtungen.

Darüber hinaus kündigte Microsoft selbst im Juni 2025 Microsoft 365 Local an — eine On-Premises-Option, die Souveränitätsbedenken adressieren soll. Ob das ein echtes Zugeständnis ist oder eine Strategie, europäische Regierungen auf Microsofts Plattform zu halten, indem man den Jurisdiktionseinwand beseitigt, ist Ansichtssache. Für Microsoft ist das Worst-Case-Szenario nicht geringere Margen bei einem souveränen Deployment — es ist eine Regierung, die vollständig auf openDesk oder LaSuite umsteigt.

Dänemark: Systematische Anbieter-Diversifizierung

Im Sommer 2025 kündigte Dänemark ein systematisches Programm zur Reduzierung der Microsoft-365-Abhängigkeit in der Verwaltung an. Digitalministerin Caroline Stage Olsen formulierte es als Konzentrationsrisiko: „Wir dürfen uns niemals so abhängig von so wenigen machen."

Der dänische Ansatz ist umfassend. Das Ministerium für Digitale Angelegenheiten begann im Sommer-Herbst 2025 mit der Einführung von LibreOffice auf Regierungsarbeitsplätzen. Kopenhagen und Aarhus kündigten ähnliche Initiativen auf kommunaler Ebene an. Die Migration läuft, und das vollständige Bild wird sich erst über Jahre zeigen — aber Dänemark ist zum prominentesten Fall eines westeuropäischen Staates geworden, der sich auf nationaler Ebene explizit für den Abbau der Microsoft-Abhängigkeit entscheidet.

Die Managed-Services-Lücke

Hier die Bestandsaufnahme, die Souveränitätsbefürworter manchmal überspringen: Europäische Cloud-Anbieter sind bei Managed Services schwächer.

AWS bietet über 200 Managed Services an. Azure eine vergleichbare Bandbreite. Darunter Managed Databases (RDS, Cosmos DB), serverlose Compute-Dienste (Lambda, Azure Functions), KI-Dienste (SageMaker, Azure OpenAI), Analytics (Redshift, Synapse), IoT-Plattformen und Dutzende mehr. Jeder Managed Service bedeutet weniger operativen Aufwand für den Kunden — und mehr Lock-in.

Europäische Anbieter wie Hetzner und OVH punkten bei der Infrastruktur: virtuelle Maschinen, Bare-Metal-Server, Storage, Networking. Ihr Angebot an Managed Services wächst, bleibt aber im Vergleich bescheiden. Scaleway hat hier stärker investiert und bietet Managed Kubernetes, Datenbanken und KI-GPU-Instanzen an. Aber die Lücke ist real.

Für Organisationen, die eine Migration evaluieren, bedeutet das: Wenn Sie EC2, S3 und RDS in einer Standardkonfiguration nutzen, kann ein europäischer Anbieter Sie wahrscheinlich zu 3–5-fach niedrigeren Kosten bedienen. Wenn Sie tief in Lambda, Step Functions und DynamoDB eingebettet sind — ist ein Wechsel möglich, erfordert aber erhebliche Re-Architektur. Die Berechnung der Gesamtbetriebskosten (TCO) muss nicht nur die monatliche Rechnung umfassen, sondern auch den Migrationsaufwand.

Der Data Act: Regulierung als Wegbereiter

Ein Stück EU-Regulierung verdient besondere Erwähnung wegen seiner direkten Relevanz für Cloud-Migration: der Data Act (EU 2023/2854), anwendbar seit dem 12. September 2025.

Der Data Act verpflichtet Cloud-Anbieter, den Anbieterwechsel zu erleichtern: Sie müssen Datenexport-Werkzeuge bereitstellen, Datenportabilität unterstützen und dürfen keine überhöhten Wechselgebühren erheben. Ab Januar 2027 müssen Wechselgebühren vollständig entfallen.

Das ist nicht deshalb bedeutsam, weil es die Migration einfach macht — die technische Komplexität bleibt bestehen —, sondern weil es eine der Hürden beseitigt, die Cloud-Anbieter bewusst aufgebaut haben. Bisher war die Extraktion großer Datenmengen aus einem Hyperscaler häufig mit erheblichen Egress-Gebühren verbunden. Der Data Act verändert die ökonomische Kalkulation.

Wie eine realistische Migration aussieht

Organisationen, die erfolgreich Workloads von Hyperscalern abgezogen haben, teilen gemeinsame Merkmale:

1. Sie haben mit neuen Workloads begonnen. Statt bestehende Anwendungen zu migrieren (komplex, riskant, teuer), haben sie neue Projekte von Anfang an auf europäischen Anbietern aufgesetzt. Mit der Zeit verschob sich die Balance.

2. Sie haben proprietäre Dienste vermieden. Organisationen, die auf Kubernetes, PostgreSQL und S3-kompatiblen Object Storage gesetzt haben (alles bei europäischen Anbietern verfügbar), fanden die Migration unkompliziert. Wer auf Lambda und DynamoDB gebaut hatte, fand sie nicht.

3. Sie haben Hybrid akzeptiert. Die meisten erfolgreichen Migrationen führen nicht zu 100 % europäischem Hosting. Manche Dienste — insbesondere KI-APIs und globales CDN — bleiben möglicherweise bei Hyperscalern, während Kerndaten und Compute auf europäische Infrastruktur wechseln. Eine bewusste Hybrid-Strategie — mit klaren Kriterien, was bleibt und was migriert wird — ist nachhaltiger als ein Alles-oder-nichts-Ansatz.

4. Sie haben in den Betrieb investiert. Europäische Anbieter bieten weniger Rundum-Betreuung. Organisationen brauchen hauseigene oder beauftragte Expertise für Deployment, Monitoring und Incident Response. Die Gesamtbetriebskosten umfassen Menschen, nicht nur Server.

5. Sie haben offene Standards genutzt. Kubernetes, S3-kompatible APIs, PostgreSQL, OpenStack — je standardisierter der Stack, desto einfacher die Migration. Proprietärer Lock-in ist kein Cloud-Problem, sondern eine Designentscheidung.

Was bleibt

Europäische Cloud-Souveränität ist kein Technologieproblem. Europäische Anbieter bieten wettbewerbsfähige Infrastruktur. SCS hat gezeigt, dass interoperable, souveräne Cloud-Stacks funktionieren. Der Preisvorteil europäischer Anbieter ist real und erheblich.

Zwei regulatorische Fristen schaffen ein konkretes Handlungsfenster. Der Data Act ist seit September 2025 anwendbar und verpflichtet Cloud-Anbieter, Datenportabilität zu unterstützen. Ab Januar 2027 müssen Wechselgebühren vollständig entfallen. Erstmals werden die ökonomischen Barrieren, die Hyperscaler um ihre Plattformen errichtet haben, regulatorisch abgebaut.

Wenn Sie Workloads auf einem US-Hyperscaler betreiben und Alternativen in Betracht ziehen, ergibt sich aus den obigen Mustern eine klare Reihenfolge:

Jetzt starten:

  • Alle neuen Workloads auf europäischen Anbietern deployen. Neue Projekte haben keine Migrationskosten. Ein Kubernetes-Cluster auf Hetzner oder Scaleway kostet einen Bruchteil des AWS-Äquivalents — und Sie bauen keinen neuen Lock-in auf.
  • Bestehenden Stack auf proprietäre Abhängigkeiten auditieren. Wie tief stecken Sie in Lambda, DynamoDB oder Azure-spezifischen Diensten? Die Antwort bestimmt Komplexität und Zeithorizont Ihrer Migration. Dieses Audit dauert Tage, nicht Monate.

Vor Januar 2027 (Data Act: Wegfall der Wechselgebühren):

  • Migration für gebührenintensive Workloads planen. Wenn der Data Act die Wechselgebühren vollständig abschafft, sinken die Kosten für den Abzug großer Datenmengen von Hyperscalern erheblich. Nutzen Sie die Zeit bis dahin zur Vorbereitung: identifizieren, was umzieht, Zielumgebung testen, Team schulen.
  • Nächsten Cloud-Vertrag mit Exit-Klausel verhandeln. Wenn Ihr Enterprise Agreement vor 2027 verlängert wird, stellen Sie sicher, dass es Datenportabilitätsregelungen im Sinne des Data Act enthält.

Akzeptieren und steuern:

  • Hybrid ist kein Scheitern. KI-APIs, globales CDN und Nischen-Managed-Services bleiben möglicherweise bei Hyperscalern, während Kerndaten und Compute auf europäische Infrastruktur wechseln. Das Ziel ist bewusste Entscheidung, nicht dogmatische Reinheit. Für einen strukturierten Rahmen, was man selbst betreiben und was man mieten sollte, siehe Die Grenzen digitaler Unabhängigkeit.

Die Kosten des Abwartens: Wenn Sie Standard-Infrastruktur-Workloads (Compute, Storage, Datenbanken) auf AWS oder Azure betreiben, bieten europäische Anbieter das Gleiche zu 3–5x niedrigeren Kosten. Für ein typisches 50-Server-Deployment sind das Zehntausende Euro pro Jahr an unnötigen Ausgaben — Geld, das die Betriebsexpertise für souveräne Infrastruktur finanzieren könnte. Jedes Jahr Verzögerung vertieft den Lock-in und erhöht die Kosten.

Quellen

Themenübersicht: Cloud-Infrastruktur

Suche

Strg+K öffnet die Suche jederzeit