Cloud agnostisch: Bedeutung und praktische Umsetzung

„Cloud agnostisch" gehört zu den Begriffen, die in Architektur-Reviews und Technologiediskussionen regelmäßig fallen, ohne dass jemand genau erklärt, was damit gemeint ist. Dabei ist die Idee dahinter weder kompliziert noch abstrakt. Es geht darum, Softwarearchitektur und Infrastruktur so zu gestalten, dass sie nicht von einem bestimmten Cloud-Anbieter abhängen. Wer cloud agnostisch baut, kann seinen Workload auf AWS, Google Cloud, Azure oder einer eigenen Infrastruktur betreiben, ohne die Codebasis grundlegend ändern zu müssen.

Relevant ist das aus einem einfachen Grund. Wer einmal tief in die Dienste eines einzelnen Anbieters investiert hat, zahlt beim Wechsel. Nicht nur mit Geld, sondern auch mit Zeit, Regressionstests und umgeschriebenen Integrationen.

Was „cloud agnostisch" konkret bedeutet

Cloud agnostisch beschreibt eine Designphilosophie. Es ist kein Produkt, kein Tool und keine magische Schicht, die alles löst, sondern eine Entscheidung, die bei jedem Architekturschritt neu getroffen wird. Setze ich auf einen Standard, der überall funktioniert, oder auf einen Managed Service, den nur ein Anbieter so anbietet?

Konkret bedeutet das den Einsatz von Containern statt anbieterspezifischer Laufzeitumgebungen, von standardisierten Datenbanken statt DynamoDB oder Firestore und von offenen Message-Brokern statt SQS oder Pub/Sub. Das liegt nicht daran, dass die proprietären Dienste schlecht wären, oft sind sie sogar bequemer. Es liegt daran, dass jeder Schritt in diese Richtung eine Abhängigkeit schafft, die sich irgendwann rächt.

Der Unterschied zwischen cloud agnostisch und multi-cloud

Die Begriffe werden häufig verwechselt oder synonym verwendet, sind es aber nicht.

Multi-cloud bedeutet, dass ein Unternehmen mehrere Cloud-Anbieter gleichzeitig nutzt, zum Beispiel AWS für Rechenleistung, GCP für Machine Learning und Azure für Microsoft-Workloads. Das kann aus verschiedenen Gründen passieren, etwa wegen besserer Preise, geografischer Verfügbarkeit oder der technischen Stärken einzelner Anbieter.

Cloud agnostisch ist die Voraussetzung dafür, dass Multi-cloud überhaupt reibungslos funktioniert. Eine cloud-agnostische Architektur lässt sich problemlos auf mehreren Anbietern deployen. Eine Architektur, die tief in AWS-spezifische Dienste integriert ist, ist nicht cloud agnostisch, auch wenn sie theoretisch auf mehrere Regionen verteilt wird.

Kurz gesagt ist Multi-cloud ein Betriebsmodell, während cloud agnostisch ein Designprinzip ist.

Wo Vendor Lock-in wirklich entsteht

Lock-in entsteht selten durch eine einzelne große Entscheidung. Meistens schleicht er sich durch kleine, pragmatische Schritte ein, die jeder einzeln vernünftig wirken, in der Summe aber ein Problem darstellen.

Die offensichtlichsten Quellen sind anbieterspezifische Managed Services wie AWS RDS mit Aurora-spezifischen Features, Google Cloud Spanner oder Azure Cosmos DB. Wer einmal auf Spanner aufbaut, wird das nicht mal eben auf einem anderen Anbieter nachbilden können.

Weniger offensichtlich, aber genauso kritisch sind weitere Bereiche. Serverless-Funktionen wie AWS Lambda, Google Cloud Functions und Azure Functions haben zwar ähnliche Konzepte, aber unterschiedliche Trigger-Systeme, Konfigurationsformate und Laufzeitumgebungen, sodass sich Code oft nicht 1:1 übertragen lässt. Auch IAM und Berechtigungsmodelle sind ein heikler Punkt, denn wer sein gesamtes Zugriffsmanagement auf AWS IAM aufbaut, steht bei einem Wechsel vor der Aufgabe, ein komplett neues Berechtigungsmodell zu entwickeln. Hinzu kommen proprietäre Netzwerkdienste, deren VPC-spezifische Konfigurationen, Load-Balancer-Setups und DNS-Management sich zwischen Anbietern erheblich unterscheiden. Ebenso betroffen ist Monitoring und Logging, denn wer tief in CloudWatch, Stackdriver oder Azure Monitor investiert, migriert das nicht mal eben mit.

Die unsichtbaren Lock-in-Fallen

Manche Dienste wirken auf den ersten Blick neutral, schaffen aber trotzdem Abhängigkeiten. Objektspeicher ist ein gutes Beispiel. S3 ist de facto der Standard, aber S3-kompatible APIs haben subtile Unterschiede. Wer auf S3-spezifische Features wie bestimmte Event-Typen oder Lifecycle-Policies aufbaut, merkt das erst bei der Migration. Wer MinIO durch eine lizenzrechtlich saubere Alternative ersetzen will, stößt genau auf diese Kompatibilitätsfragen.

Ähnliches gilt für Kubernetes-Distributionen. EKS, GKE und AKS sind alle Kubernetes, aber mit unterschiedlichen Add-ons, Netzwerk-Plugins und Storage-Klassen. Wer sich auf diese anbieterspezifischen Details verlässt, hat de facto keinen portablen Workload, auch wenn Kubernetes darunter liegt.

Kubernetes als Fundament für cloud-agnostische Architekturen

Kubernetes hat sich als der praktischste gemeinsame Nenner für cloud-agnostische Infrastruktur durchgesetzt. Das liegt nicht nur daran, dass es auf jedem Anbieter läuft, sondern daran, dass das Kubernetes-API selbst der Standard ist. Ein Deployment, ein Service oder eine ConfigMap funktionieren auf EKS genauso wie auf GKE, auf einem Bare-Metal-Cluster in einem deutschen Rechenzentrum oder auf einem lokalen kind-Cluster.

Das bedeutet, dass die Portabilität weitgehend gegeben ist, wenn Workloads konsequent als Kubernetes-Ressourcen definiert sind und keine anbieterspezifischen Annotations oder Custom Resources außerhalb des Kubernetes-Standards verwenden.

Werkzeuge, die Portabilität ermöglichen

Kubernetes allein reicht nicht. Für eine vollständig cloud-agnostische Infrastruktur braucht es einen Stack, der auch die Infrastruktur selbst abstrahiert.

Terraform ist der Standard für Infrastructure as Code, das anbieterübergreifend funktioniert. Mit dem gleichen Workflow lassen sich AWS-, GCP- und Azure-Ressourcen provisionieren, auch wenn die Provider-Module sich unterscheiden.

Helm und Kustomize standardisieren das Deployment von Kubernetes-Anwendungen. Einmal als Helm-Chart verpackt, ist eine Anwendung auf jedem Cluster deploybar.

Crossplane geht einen Schritt weiter und bringt Cloud-Ressourcen wie Datenbanken oder Object Storage als Kubernetes-Custom-Resources ins Cluster, wobei es den Anbieter abstrahiert. Wer heute eine PostgreSQL-Instanz über Crossplane auf AWS betreibt, kann dieselbe Ressource morgen auf einem anderen Anbieter provisionieren, ohne die Anwendungslogik zu ändern.

Der Container Storage Interface (CSI) Standard sorgt dafür, dass Storage-Volumes unabhängig vom Anbieter eingebunden werden können. Gleiches gilt für das Open Container Initiative (OCI) Format für Container-Images.

Wo cloud-agnostische Architekturen an Grenzen stoßen

Portabilität ist nicht kostenlos. Wer konsequent cloud agnostisch baut, verzichtet oft auf Optimierungen, die ein bestimmter Anbieter bietet.

Das konkreteste Beispiel ist AWS Aurora, das für bestimmte Workloads deutlich schneller ist als eine Standard-PostgreSQL auf RDS. Wer Aurora nicht nutzt, um cloud agnostisch zu bleiben, lässt Performance auf dem Tisch liegen. Ähnliches gilt für Googles BigQuery, denn wer auf Standard-OLAP-Werkzeuge setzt, hat nicht automatisch dieselbe Skalierung und Performance.

Der Trade-off ist real und sollte bewusst getroffen werden. Für die meisten Anwendungsfälle ist der Unterschied marginal. Für sehr spezifische, hochoptimierte Workloads kann er relevant sein.

Eine andere Einschränkung ist der Abstraktionsaufwand, der nicht trivial ist. Ein gut konfiguriertes Crossplane-Setup, eine saubere Helm-Chart-Bibliothek und konsistentes IaC über mehrere Anbieter kosten Aufwand beim Aufbau und beim Betrieb. Für ein Startup in der frühen Phase, das primär auf Time-to-market optimiert, ist das oft nicht der richtige Fokus. Cloud agnostisch zu sein ist eine Investition, die sich langfristig auszahlt.

Datensouveränität als Treiber, besonders in Europa

Für europäische Unternehmen hat cloud-agnostische Architektur eine zweite, zunehmend wichtige Dimension, nämlich die Datensouveränität.

Die DSGVO und branchenspezifische Regularien wie KRITIS oder die NIS2-Richtlinie stellen klare Anforderungen daran, wo Daten gespeichert und verarbeitet werden dürfen. Wer tief in die Infrastruktur eines US-amerikanischen Hyperscalers integriert ist, hat wenig Spielraum, wenn neue Anforderungen eine andere Lösung erzwingen.

Cloud-agnostische Architekturen geben diesen Spielraum zurück. Wenn eine Anwendung auf einem standardisierten Kubernetes-Stack läuft und keine proprietären Abhängigkeiten zu einem bestimmten Anbieter hat, ist der Wechsel zu einem europäischen oder souveränen Cloud-Anbieter keine Cloud Exit Strategie, sondern ein Deployment auf einem neuen Cluster.

Das ist besonders relevant für Unternehmen aus dem Finanz-, Gesundheits- und öffentlichen Sektor, aber auch für alle, die ihre Infrastruktur langfristig unabhängig von politischen und regulatorischen Entwicklungen in den USA halten wollen. Wie Kubernetes und digitale Souveränität zusammenwirken, zeigt sich dabei besonders deutlich.

Wie eine PaaS-Plattform Anbieterunabhängigkeit in die Praxis bringt

Die Idee hinter cloud-agnostischer Architektur ist überzeugend, aber die Umsetzung kostet Zeit und Expertise. Wer kein dediziertes Plattform-Engineering-Team hat, das Crossplane, Terraform und Kubernetes-Betrieb gleichzeitig meistert, stößt schnell an Kapazitätsgrenzen.

Hier setzt eine Kubernetes-basierte PaaS-Plattform wie lowcloud an. Die Plattform abstrahiert den darunterliegenden Cloud-Anbieter und gibt Entwicklungsteams eine einheitliche Schnittstelle, unabhängig davon, ob der Workload auf einem deutschen Rechenzentrum, einem souveränen Cloud-Anbieter oder einem Hyperscaler läuft. Deployments, Monitoring, Skalierung und Netzwerk-Konfiguration funktionieren identisch.

Das Ergebnis ist, dass Teams mit Kubernetes-nativen Workflows arbeiten, ohne sich mit anbieterspezifischen Details auseinandersetzen zu müssen. Und wenn sich die Anforderungen ändern, sei es regulatorisch, wirtschaftlich oder technisch, ist der Wechsel des Anbieters eine operative Entscheidung und keine Architekturkrise.