Souveräne Alternativen zu Hyperscalern – muss es immer eine andere "Cloud" sein?
Die Diskussion um Souveränität in der Cloud wird in Europa oft entlang der Frage geführt: Brauchen wir unsere eigenen Hyperscaler, um unabhängig zu sein? Viele sehen die Lösung in einer „europäischen Cloud", die AWS, Azure oder Google Cloud ersetzen soll. Aber die Realität ist deutlich komplexer – und in vielerlei Hinsicht pragmatischer. Denn die meisten Dienste, die Hyperscaler anbieten, basieren ohnehin auf bekannten Open-Source-Projekten. Der Unterschied liegt im Branding, in der Integration und im Pricing. Wer wirklich Souveränität anstrebt, muss nicht unbedingt einen neuen Hyperscaler bauen. Die eigentliche Alternative liegt näher: Kubernetes als Basis und offene Werkzeuge statt proprietärer „Cloud-Services".
Die Diskussion um Souveränität in der Cloud wird in Europa oft entlang der Frage geführt: Brauchen wir unsere eigenen Hyperscaler, um unabhängig zu sein? Viele sehen die Lösung in einer „europäischen Cloud", die AWS, Azure oder Google Cloud ersetzen soll. Aber die Realität ist deutlich komplexer – und in vielerlei Hinsicht pragmatischer. Denn die meisten Dienste, die Hyperscaler anbieten, basieren ohnehin auf bekannten Open-Source-Projekten. Der Unterschied liegt im Branding, in der Integration und im Pricing. Wer wirklich Souveränität anstrebt, muss nicht unbedingt einen neuen Hyperscaler bauen. Die eigentliche Alternative liegt näher: Kubernetes als Basis und offene Werkzeuge statt proprietärer „Cloud-Services".
Hyperscaler-Services sind oft nur Open Source mit Branding
Ein Großteil der Hyperscaler-Produktpalette besteht aus Open-Source-Werkzeugen, die unter einem eigenen Namen neu verpackt und mit einem Preisschild versehen werden. Beispiele:
Amazon RDS basiert auf PostgreSQL oder MySQL.
Azure Cosmos DB bietet auch PostgreSQL-kompatible Schnittstellen.
Google Cloud SQL ist schlicht ein gemanagter PostgreSQL- oder MySQL-Dienst.
Die Innovation liegt weniger in der eigentlichen Software, sondern in der Integration in das jeweilige Ökosystem des Hyperscalers: IAM-Integration, Monitoring, Autoscaling und Abrechnung sind nahtlos eingebunden. Das macht es bequem – aber nicht souverän.
Europäische Clouds: Vanilla Open Source mit eigenem Label
Viele europäische Cloud-Anbieter gehen einen anderen Weg: Sie bieten die offizielle Community-Version von Open-Source-Projekten wie PostgreSQL, MariaDB oder Kubernetes an – meist mit einem eigenen Branding und oft mit intransparentem Pricing. Der Vorteil: Keine Forks, keine proprietären APIs. Der Nachteil: Weniger tiefe Integration und teilweise ein „Reseller"-Gefühl – am Ende betreibt man nur ein PostgreSQL, das im Frontend einen anderen Namen trägt.
Das führt zu einer paradoxen Situation: Europäische Clouds wirken manchmal weniger innovativ als amerikanische Hyperscaler, die die gleichen Tools so tief integrieren, dass ihre Mehrkosten zumindest technisch nachvollziehbar erscheinen.
Die Realität: VMs mit Software oben drauf
Wer genau hinsieht, erkennt: Viele Cloud-Angebote sind letztlich nur „Virtuelle Maschinen mit vorinstallierter Software". Das mag für kleinere Projekte praktisch sein, wird aber schnell unattraktiv, wenn es um Performance, Isolation und Kosten geht. Shared-Systeme sind keine Seltenheit, und „Noisy-Neighbor"-Probleme – also Performance-Einbußen durch überlastete Nachbarsysteme – treten selbst bei Premium-Anbietern auf.
Die Frage ist also: Warum einen teuren Umweg über Hyperscaler oder Second-Tier-Clouds gehen, wenn man ohnehin nur Software auf VMs ausführt? Warum nicht gleich Kubernetes nutzen und dort die gleichen Open-Source-Tools souverän betreiben?
Kubernetes als Fundament für Souveränität
Kubernetes bietet alles, was nötig ist, um eine souveräne Infrastruktur aufzubauen:
Eingebaute Hochverfügbarkeit: Pods und Deployments sind per se fehlertolerant und werden automatisch neugestartet.
Self-Healing: Knoten oder Container, die ausfallen, werden automatisch ersetzt.
Skalierbarkeit: Workloads können horizontal und vertikal skaliert werden – unabhängig vom Businessmodell eines Cloud-Anbieters.
Portabilität: Kubernetes läuft auf AWS, Azure, GCP, Oracle, aber auch on-premise oder in europäischen Clouds. Wer Kubernetes beherrscht, ist nicht an einen Anbieter gebunden.
Ökosystem: Operators, CRDs und eine Vielzahl an Open-Source-Projekten machen es möglich, komplexe Systeme souverän zu betreiben.
Mit Kubernetes wird die Cloud nicht ersetzt, sondern entzaubert: Aus dem „Cloud-Magic" wird ein Set an Werkzeugen, das auf jeder Infrastruktur laufen kann.
Basierend auf der Vergleichstabelle zu AWS, Azure, GCP und Oracle lassen sich einige Kernservices genauer betrachten. Für jeden dieser Services existieren in Kubernetes ausgereifte Open-Source-Alternativen.
PostgreSQL-Datenbanken: CNPG statt RDS & Co.
Amazon RDS, Google Cloud SQL oder Azure Database for PostgreSQL sind populäre Managed-Services. Doch am Ende steckt auch hier „nur" PostgreSQL dahinter – mit einer proprietären Managementschicht.
Eine souveräne Alternative bietet CloudNativePG (CNPG):
Point-in-Time Recovery (PITR): Zeitgenaue Wiederherstellung, wie man es von Enterprise-Datenbanken kennt.
Metrics-Integration: Native Prometheus/Grafana-Integration für Monitoring.
Dashboards: Übersichtliche Dashboards für Cluster-Status und Performance.
Clustering & Hochverfügbarkeit: Mehrknoten-Setups mit automatischem Failover.
CNPG ist ein Kubernetes-Operator, der PostgreSQL-Cluster vollständig in Kubernetes integriert. Der Betrieb bleibt bei den Nutzern – aber mit deutlich mehr Transparenz und Souveränität als bei Hyperscalern.
Object Storage: S3 vs. Rook-Ceph
S3 ist zum Quasi-Standard für Object Storage geworden. AWS hat den Begriff geprägt, Azure und Google bieten entsprechende APIs, und selbst europäische Anbieter setzen auf „S3-kompatiblen Storage".
In Kubernetes-Umgebungen bietet sich Rook-Ceph an:
Self-Managed Storage: Vollständige Kontrolle über Daten und Architektur.
Skalierbarkeit: Horizontal und vertikal erweiterbar.
S3-Kompatibilität: Anwendungen, die heute S3 nutzen, funktionieren nahtlos.
Flexibilität: Neben Object Storage auch Block- und File-Storage.
Damit entfällt die Abhängigkeit von AWS & Co. – und zugleich die Gefahr von Vendor-Lock-in.
Monitoring: VictoriaMetrics vs. Cloud Monitoring
Monitoring ist einer der am meisten unterschätzten Kostenfaktoren bei Hyperscalern. Google Cloud Monitoring oder AWS CloudWatch werden oft nach Metriken oder Zeitreihen abgerechnet – was bei großen Installationen astronomische Kosten verursachen kann.
Ein Kubernetes-natives Setup mit VictoriaMetrics bietet enorme Vorteile:
Kostenreduktion: Bis zu 1000 % weniger Betriebskosten im Vergleich zu Hyperscaler-Pricing.
Kompatibilität: Prometheus-kompatibel, damit einfach integrierbar.
Effizienz: Hochperformante Speicherung von Millionen von Metriken.
In Verbindung mit Grafana entsteht ein vollständiges, souveränes Monitoring-Setup ohne die Kostenfalle.
Identity Provider: Keycloak vs. Cloud IAM
Identitäts- und Benutzerverwaltung ist ein weiteres Feld, in dem Hyperscaler hohe Kosten verursachen. AWS IAM, Azure Active Directory oder Google Identity rechnen oft pro Nutzer oder pro Authentifizierung ab.
Ein souveräner Gegenentwurf ist Keycloak:
Skalierbarkeit: Eine Instanz kann Millionen von Nutzern verwalten.
Open Source: Keine Lizenzkosten, volle Kontrolle.
Flexibilität: Unterstützung für OIDC, SAML, LDAP und Social Logins.
Kostenvorteil: Kein user-based Billing – riesige Einsparungen für Plattformen mit vielen Nutzern.
Keycloak läuft nativ in Kubernetes und ermöglicht Unternehmen, ihre eigene IAM-Lösung souverän und kosteneffizient zu betreiben.
Fazit: Souveränität bedeutet nicht „eigene Hyperscaler bauen"
Die Diskussion um europäische Souveränität in der Cloud wird oft zu eng geführt. Es geht nicht darum, AWS oder Google Cloud durch einen „europäischen Hyperscaler" zu ersetzen. Souveränität entsteht vielmehr durch die Fähigkeit, offene Werkzeuge auf eigener Infrastruktur zu betreiben und damit Abhängigkeiten zu reduzieren.
Kubernetes ist dabei der Schlüssel: Es macht Workloads portabel, skalierbar und resilient – und ermöglicht die Nutzung derselben Open-Source-Werkzeuge, auf die auch Hyperscaler zurückgreifen. Wer Kubernetes beherrscht, ist frei, die Cloud-Provider nur noch als Lieferanten von Rechenressourcen zu betrachten – nicht als Betreiber des gesamten Ökosystems.
Die Frage ist also nicht: Brauchen wir europäische Hyperscaler? – sondern: Wie nutzen wir Kubernetes, um uns unabhängig von Hyperscaler-Businessmodellen zu machen?
Bei ayedo arbeiten wir genau an diesem Punkt: Souveräne Kubernetes-Infrastrukturen, die Unternehmen in die Lage versetzen, Cloud-Services selbstbestimmt und effizient zu betreiben. Die Werkzeuge sind vorhanden – man muss sie nur konsequent nutzen.
Hosten Sie Ihre Apps bei ayedo
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
Noch Fragen? Melden Sie sich!
Unsere DevOps-Experten antworten in der Regel innerhalb einer Stunde.
Zu Gen-Z für E-Mail? Einfach mal Discord versuchen. Unter +49 800 000 3706 können Sie unter Angabe Ihrer Kontaktdaten auch einen Rückruf vereinbaren. Bitte beachten Sie, dass es keine Möglichkeit gibt, uns telefonisch direkt zu erreichen. Bitte gar nicht erst versuchen. Sollten Sie dennoch Interesse an synchroner Verfügbarkeit via Telefon haben, empfehlen wir Ihnen unseren Priority Support.