Das Trojanische Pferd der „sovereign cloud“
Das trojanische Pferd der „Sovereign Cloud" Warum Europas neue Souveränität oft nur …


Die Diskussion um digitale Souveränität in Europa ist alt – aber sie ist aktueller denn je. Spätestens seit der geopolitischen und regulatorischen Verschärfung der letzten Jahre ist klar geworden, dass die Frage, wo und wie Daten verarbeitet werden, nicht mehr nur eine technische, sondern eine strategische ist.
Staaten, Unternehmen und Behörden beginnen zu verstehen, dass digitale Unabhängigkeit mehr bedeutet als Datenschutz und mehr erfordert als ein EU-Rechenzentrum.
Doch während die öffentliche Debatte sich an Begriffen wie „Sovereign Cloud" festhält, bleibt ein wesentlicher Punkt meist ungesagt: Echte Souveränität entsteht nicht durch Marketingetiketten oder neue Verträge – sondern durch Architektur.
Was heute unter „Sovereign Cloud" vermarktet wird, ist oft nicht mehr als eine semantische Beruhigungspille. Hyperscaler bieten europäische Instanzen ihrer Dienste an, hosten Daten in Frankfurt oder Paris, schalten zusätzliche Verschlüsselungsschichten dazwischen und präsentieren lokale Partnergesellschaften, um Compliance Anforderungen zu erfüllen.
Doch die Eigentums- und Kontrollverhältnisse bleiben dieselben. Eine AWS „German Sovereign Region" bleibt AWS. Eine Microsoft „Cloud Deutschland" bleibt Microsoft. Die Kontrolle über Software, Updates, APIs, Service-Verfügbarkeit und Preisgestaltung liegt weiterhin außerhalb europäischer Hoheit.
Das Problem ist strukturell: Datenstandort ist nicht gleich Datenhoheit. Wer die Kontrolle über die Plattform besitzt, besitzt die Kontrolle über den Betrieb. Das gilt unabhängig davon, wo die Server physisch stehen.
Deshalb ist die „Sovereign Cloud"-Rhetorik der Hyperscaler zwar rechtlich geschliffen, technisch aber irrelevant. Sie verändert nicht die Abhängigkeit, sie verlagert sie nur.
Niemand bestreitet, dass AWS, Azure und Google Cloud technologisch führend sind. Sie bieten ausgereifte, hochautomatisierte Infrastrukturen, eine Vielzahl von Services und eine hervorragende Developer Experience. Ihre Plattformen sind ein Synonym für Geschwindigkeit und Skalierbarkeit.
Das Problem liegt nicht in der Qualität, sondern im Modell. Hyperscaler sind geschlossene Ökosysteme, deren primäres Ziel die Integration und Bindung ihrer Kunden ist. Jede zusätzliche Bequemlichkeit bedeutet gleichzeitig eine stärkere Verflechtung.
Was als Komfort beginnt – Managed Databases, Serverless Functions, Machine Learning APIs – wird mit der Zeit zum Käfig. Daten und Workloads sind eng mit proprietären Schnittstellen, Security-Modellen und Service-Implementierungen verbunden. Der Ausstieg wird teuer oder schlicht unmöglich.
Diese Abhängigkeit ist kein Zufall, sondern Teil des Geschäftsmodells.
Europa hat auf diese Entwicklung reagiert, aber die Antwort ist uneinheitlich. Anbieter wie Plusserver, IONOS, Scaleway, Exoscale oder Linode (letztere mittlerweile von Akamai übernommen) bieten souveräne Cloud-Infrastrukturen mit europäischer Rechtshoheit, Open-Source-Komponenten und lokalem Support.
Technologisch sind diese Angebote solide. Sie liefern Compute, Storage, Netzwerk, teilweise auch Managed Services – meist auf Basis von OpenStack, Ceph oder Kubernetes.
Doch ihr größter Nachteil ist strukturell: Sie sind zu klein, um global konkurrenzfähig zu wirken, und zu heterogen, um standardisiert bedienbar zu sein.
Ein Wechsel von IONOS zu Scaleway oder von Plusserver zu Exoscale bedeutet heute noch: andere APIs, andere Interfaces, andere Automatisierung. Was fehlt, ist ein verbindendes Betriebssystem – eine gemeinsame Sprache, die über alle Cloud-Anbieter hinweg funktioniert.
In der öffentlichen Diskussion wird Souveränität oft mit Autarkie verwechselt. Doch wer glaubt, Unabhängigkeit bedeute, keine externen Anbieter zu nutzen, irrt. Souveränität heißt nicht Isolation – sie heißt Wahlfreiheit.
Echte digitale Souveränität entsteht, wenn man sich jederzeit frei entscheiden kann, wo und wie ein System betrieben wird, ohne Funktionalität oder Integrität zu verlieren. Das setzt voraus, dass man die Cloud nicht als monolithischen Anbieter versteht, sondern als austauschbare Ressource.
Damit ändert sich auch die Perspektive auf Cloud-Architektur: Weg von „Wir sind auf Anbieter X" hin zu „Wir orchestrieren über Anbieter hinweg". Genau hier beginnt Cloud Brokering.
Cloud Brokering bedeutet, Infrastruktur nicht mehr zu „kaufen", sondern zu „vermitteln". Ein Broker ist kein Anbieter, sondern eine Abstraktionsschicht – ein technisches und operatives Bindeglied zwischen Workloads und Infrastrukturanbietern.
Das Ziel ist nicht, alle Clouds gleichzeitig zu nutzen, sondern flexibel über sie zu entscheiden. Das kann bedeuten:
Cloud Brokering ist das Gegenteil von Lock-In.
Es bedeutet, Plattformen so zu abstrahieren, dass Infrastruktur zu einem austauschbaren Baustein wird – orchestriert, automatisiert, kontrolliert.
Und der Schlüssel dazu ist längst vorhanden: Kubernetes.
Kubernetes hat in den letzten Jahren eine stille Revolution ausgelöst. Es hat aus Containern ein Betriebssystem gemacht – eine universelle API, die Workloads unabhängig von ihrer Umgebung definiert, startet und verwaltet.
Mit Kubernetes verschiebt sich die Schnittstelle zwischen Anwendung und Infrastruktur. Man spricht nicht mehr mit einzelnen Clouds, sondern mit einem standardisierten Layer, der sich überall betreiben lässt – auf Hyperscalern, auf europäischen Clouds, in Rechenzentren, auf Edge-Geräten.
Das bedeutet: Wer Kubernetes als Fundament nutzt, hat die Hoheit über seine Laufzeitumgebung zurückgewonnen. Und genau hier setzt ayedo mit Loopback an.
Mit Loopback, unserem Managed Kubernetes-Angebot, abstrahieren wir Infrastruktur vollständig. Unternehmen müssen sich nicht mehr entscheiden, wo sie ihre Anwendungen betreiben, sondern können sie dynamisch verteilen.
Loopback fungiert als Cloud-Broker: Es stellt eine Kubernetes-Plattform bereit, die über verschiedene Provider hinweg funktioniert, standardisierte Deployments ermöglicht und portable Workloads verwaltet.
Ein Unternehmen kann damit gleichzeitig auf AWS, IONOS, Scaleway und eigenen Rechenzentren laufen – ohne proprietäre Abhängigkeiten.
Der entscheidende Punkt: ayedo selbst ist kein Lock-In. Wir nutzen keine proprietären APIs, sondern reine Kubernetes-Standards. Wer sich später anders entscheidet, kann seine Workloads über standardisierte Verfahren (z. B. Helm, ArgoCD, GitOps) nahtlos migrieren.
Das ist echte Souveränität: Wahlfreiheit durch Technik, nicht durch Verträge.
Technologie allein schafft keine Unabhängigkeit. Cloud Brokering erfordert ein Umdenken in Unternehmen – weg von Anbietertreue, hin zu Betriebsstrategie.
Die zentrale Frage lautet nicht mehr: „Bei wem hosten wir?", sondern: „Wie orchestrieren wir?"
Teams müssen lernen, Cloud-Umgebungen als austauschbare Ressourcen zu behandeln. Das setzt Automatisierung, einheitliche Observability, standardisierte Deployments und klare Governance-Regeln voraus. Cloud Brokering zwingt Unternehmen, Architekturdisziplin zu entwickeln – und genau das führt langfristig zu Stabilität und Sicherheit.
Ein oft übersehener Vorteil von Cloud Brokering liegt in der Regionalität. Unternehmen können ihre Workloads gezielt nach Standort, Rechtsraum oder Nachhaltigkeitsaspekten verteilen. Ein Datendienst kann in Deutschland laufen, eine Analyseplattform in Frankreich, eine Testumgebung bei einem Hyperscaler.
Diese Flexibilität ist nicht nur eine technische Errungenschaft, sondern eine politische. Sie ermöglicht Datenhoheit ohne Abschottung – und macht regionale Provider wieder relevant.
Die aktuelle Debatte in Deutschland ist von einem künstlichen Gegensatz geprägt:
Entweder man nutzt Hyperscaler und verzichtet auf Souveränität, oder man nutzt europäische Clouds und verzichtet auf Innovation. Beides ist falsch. Mit einem Cloud-Brokering-Ansatz lassen sich beide Welten verbinden: die technologische Reife der Hyperscaler und die rechtliche Sicherheit regionaler Anbieter. Man muss sich nicht entscheiden, wenn man intelligent orchestriert.
Infrastrukturelle Abstraktion war schon immer die Triebkraft technischer Innovation. Virtualisierung hat Hardware abstrahiert. Container haben Betriebssysteme abstrahiert. Kubernetes abstrahiert Infrastruktur.
Cloud Brokering ist der nächste logische Schritt. Es abstrahiert Cloud-Anbieter. Diese Abstraktion schafft keinen Verlust an Kontrolle, sondern das Gegenteil: Sie ermöglicht es, Kontrolle wieder zurückzuholen – durch offene Schnittstellen, Standardisierung und operative Transparenz.
Echte digitale Souveränität entsteht nicht durch Verträge, Marketingbegriffe oder nationale Labels. Sie entsteht durch technische Gestaltung: durch Offenheit, durch Standardisierung und durch die Fähigkeit, sich jederzeit neu zu entscheiden.
Hyperscaler liefern exzellente Technologie, aber keine Unabhängigkeit. Europäische Anbieter liefern rechtliche Sicherheit, aber keine Skalierung. Cloud Brokering verbindet beides – technologisch elegant, politisch relevant.
Mit ayedo und Loopback wird diese Strategie operativ greifbar. Wir helfen Unternehmen, ihre Cloud-Strategie so aufzubauen, dass sie nicht von Anbietern, sondern von Architektur abhängt. Denn Souveränität ist kein Zielzustand, sondern ein kontinuierlicher Prozess – und wer ihn technisch versteht, braucht keine Schlagworte mehr.
Brokering statt Lock-In. Architektur statt Abhängigkeit.
Das trojanische Pferd der „Sovereign Cloud" Warum Europas neue Souveränität oft nur …
Delos Cloud vs. Stackit Workspace – Wölfe im Schafspelz Die Diskussion um digitale Souveränität in …
Microsoft wird seine Kollaborationsplattform Teams ab Dezember 2025 um eine Funktion erweitern, die …