Multi-Cloud-Strategie 2026: Raus aus dem Vendor-Lock-in, rein in die Flexibilität
EU Data Act, Kubernetes und Multi-Cloud: Drei Hebel, mit denen deutsche Unternehmen 2026 die Abhängigkeit von einzelnen Hyperscalern reduzieren.
Vendor-Lock-in war jahrelang der Preis, den Unternehmen für die Bequemlichkeit der Cloud zahlten. 2026 verschiebt sich dieses Machtgefüge: Der EU Data Act bringt regulatorische Hebel, Kubernetes liefert die technische Abstraktion, und zunehmend mehr deutsche Unternehmen bauen ihre Infrastruktur gezielt über mehrere Provider auf.
TL;DR
- Der seit Januar 2024 geltende EU Data Act verpflichtet Cloud-Provider ab September 2025, Datenportabilität und interoperable Schnittstellen zu gewährleisten – ein Meilenstein für die Cloud-Souveränität und ein Paradigmenwechsel für den Vendor-Lock-in.
- Kubernetes hat sich als De-facto-Standard für Cloud-Abstraktion etabliert: Laut CNCF betreiben 84 Prozent der Unternehmen weltweit Container im produktiven Einsatz.
- Deutsche Unternehmen wie Zalando, Deutsche Bahn und Otto Group setzen zunehmend auf Multi-Cloud-Architekturen, um ihre Abhängigkeit von einzelnen Hyperscalern zu reduzieren.
- Multi-Cloud verbessert die Verhandlungsposition bei den Preisen – erhöht aber auch die operationale Komplexität. Die Gesamtkosteneffekte hängen maßgeblich von der Governance-Reife und der FinOps-Expertise ab.
- Die größte Hürde ist nicht technologisch, sondern organisatorisch: Multi-Cloud erfordert einheitliche Governance, plattformübergreifendes Skill-Management und ein zentralisiertes FinOps-Team.
Die Rechnung ist einfach: Wer seine gesamte Infrastruktur bei einem einzigen Hyperscaler betreibt, profitiert von Integration und Bequemlichkeit – zahlt dafür aber mit Verhandlungsmacht, Portabilität und im Extremfall mit dem Zugriff auf die eigenen Daten. Laut dem Flexera State of the Cloud Report 2025 führen 70 Prozent der befragten IT-Entscheider den Vendor-Lock-in unter ihren Top-3-Cloud-Risiken auf. Dennoch tun sich viele Unternehmen noch schwer mit dem Ausstieg – denn proprietäre Services, provider-spezifische APIs und gewachsene Abhängigkeiten machen Migrationen teuer und komplex.
EU Data Act: Regulatorischer Rückenwind
Der EU Data Act, seit Januar 2024 in Kraft, gilt ab September 2025 vollumfänglich für Cloud-Services. Die Kernforderungen:
Cloud-Provider müssen funktionale Äquivalenz garantieren – Kunden müssen also Workloads ohne grundlegende Re-Engineering-Aufwendungen zu einem anderen Provider migrieren können. Wechselgebühren – die beim Providerwechsel anfallenden Kosten – werden abgeschafft: Ab September 2025 dürfen nur noch direkte Kosten des Wechselprozesses berechnet werden, ab Januar 2027 entfallen sämtliche Wechselgebühren. Provider müssen zudem offene Schnittstellen anbieten, über die sich sowohl Daten als auch Konfigurationen exportieren lassen.
Für deutsche Unternehmen ist das eine strategische Chance. Wer bisher vor dem Aufwand einer Multi-Cloud-Migration zurückschreckte, bekommt jetzt regulatorische Hebel an die Hand, um in Verhandlungen mit Hyperscalern mehr Druck aufzubauen. Gleichzeitig senkt das Verbot von Wechselgebühren die wirtschaftliche Hürde für Teil-Migrationen.
Der Data Act ist allerdings kein Patentrezept. Die Definition „funktionaler Äquivalenz“ ist bewusst vage gehalten – und es wird Jahre dauern, bis Durchführungsverordnungen jedes Detail klären. Wer jetzt handelt, sichert sich einen Wettbewerbsvorteil – sollte aber nicht allein auf die Regulierung warten. Vielmehr muss er parallel die technischen Grundlagen schaffen.
Kubernetes als Abstraktionsschicht
Die technologische Antwort auf den Lock-in lautet Abstraktion – und Kubernetes ist das Werkzeug, das diese Abstraktion in der Praxis liefert. Die Container-Orchestrierungsplattform ermöglicht Deployment und Betrieb von Workloads unabhängig vom zugrunde liegenden Infrastruktur-Provider.
Laut CNCF Annual Survey 2024 betreiben 84 Prozent der befragten Unternehmen Container im produktiven Einsatz. In Deutschland liegt die Verbreitung bei Unternehmen mit mehr als 500 Beschäftigten bei 67 Prozent (Bitkom) – ein Plus von 15 Prozentpunkten gegenüber dem Vorjahr.
Kubernetes allein löst das Lock-in-Problem jedoch nicht vollständig. Managed-Kubernetes-Services wie EKS (AWS), AKS (Azure) oder GKE (Google) integrieren häufig provider-spezifische Features – Load Balancer, Storage-Klassen, Identity Management -, die die Portabilitätsvorteile teilweise wieder aufheben.
Entscheidend sind also bewusste architektonische Entscheidungen: Welche Kubernetes-Features nutze ich plattformübergreifend? Welche proprietären Services akzeptiere ich – und wo ziehe ich die Grenze? Unternehmen wie Zalando haben diese Entscheidungen systematisch getroffen und betreiben ihre E-Commerce-Plattform auf einer Kubernetes-Architektur, die sich zwischen AWS und dem eigenen Rechenzentrum portieren lässt.
In der Praxis: Deutsche Unternehmen setzen auf Multi-Cloud
Zalando: Die Berliner E-Commerce-Gruppe hat früh auf eine infrastrukturagnostische Kubernetes-Plattform gesetzt. Die Infrastruktur läuft zwar primär auf AWS, ist aber so abstrahiert, dass einzelne Services theoretisch auch auf anderen Plattformen laufen könnten. Der strategische Mehrwert? Verhandlungsmacht gegenüber AWS in Preisgesprächen.
Deutsche Bahn: DB Systel, die IT-Tochter der Deutschen Bahn, betreibt eine Multi-Cloud-Plattform auf Basis von AWS und Azure. Passagier-Apps laufen auf AWS, während interne SAP-Workloads auf Azure migriert wurden. Ein zentrales Plattform-Team stellt sicher, dass Sicherheitspolicies und Compliance-Anforderungen in beiden Clouds einheitlich durchgesetzt werden.
Otto Group: Der Hamburger Handelskonzern nutzt die Google Cloud als primäre Plattform, ergänzt durch On-Premises-Infrastruktur für Legacy-Systeme. Die Multi-Cloud-Strategie ist hier weniger technisch als organisatorisch motiviert: Verschiedene Konzerngesellschaften dürfen ihre bevorzugte Cloud-Plattform wählen – solange sie die zentralen Governance-Standards einhalten.
Die organisatorische Basis
Multi-Cloud ist in erster Linie eine organisatorische Entscheidung. Technologie allein reicht nicht aus – Unternehmen brauchen drei Dinge:
Einheitliche Governance: Wer entscheidet, welcher Workload auf welcher Plattform läuft? Welche Services dürfen proprietär sein – und welche müssen portabel bleiben? Ohne ein zentrales Governance-Gremium – sei es ein Cloud Center of Excellence oder ein Architecture Board – ersetzt Multi-Cloud-Chaos die Multi-Cloud-Strategie.
Plattformübergreifendes FinOps: Multi-Cloud ohne zentrales Cost-Monitoring ist ein Rezept für Budget-Explosionen. Jeder Provider hat eigene Preismodelle, Rabattstrukturen (Reserved Instances, Committed Use Discounts, Savings Plans) und Abrechnungslogiken. Ein FinOps-Team mit Sichtbarkeit über alle Plattformen hinweg ist keine Optionalität, sondern Pflicht.
Skill-Management: AWS, Azure und Google Cloud sind drei eigenständige Ökosysteme – jeweils mit eigenen Zertifizierungen, Best Practices und Mental Models. Der Fachkräftemangel verschärft diese Herausforderung. Unternehmen müssen entscheiden, ob sie T-Shape-Teams aufbauen – mit breitem Grundlagenwissen und tiefer Expertise in einer Plattform – oder spezialisierte Teams pro Cloud einsetzen und die Integration zentral orchestrieren.
Unternehmen, die Multi-Cloud erfolgreich betreiben, haben eines gemeinsam: Sie verstehen die Cloud-Strategie nicht als IT-Projekt, sondern als unternehmensweite Entscheidung. Die CIO-Ebene definiert die Guardrails, die Engineering-Teams setzen sie um.
Häufige Fragen
Wann tritt der EU Data Act für Cloud-Services in Kraft?
Der EU Data Act ist im Januar 2024 in Kraft getreten. Die spezifischen Regelungen zu Cloud-Wechsel und Datenportabilität gelten ab September 2025. Für bestehende Verträge haben Cloud-Provider eine 40-monatige Übergangsfrist.
Ist Multi-Cloud immer günstiger als Single-Cloud?
Nicht automatisch. Multi-Cloud kann Kosten durch verbesserte Verhandlungsposition und Workload-Optimierung senken – der Betrieb mehrerer Plattformen verursacht aber höhere Komplexitätskosten. Der Netto-Effekt hängt von Skalierung, Governance-Reife und FinOps-Expertise ab.
Verhindert Kubernetes allein den Vendor-Lock-in?
Nein. Kubernetes abstrahiert die Compute-Ebene – Anwendungen nutzen aber häufig provider-spezifische Services wie Datenbanken, Message Queues oder Identity Provider. Bewusste architektonische Entscheidungen – welche Services portabel sein müssen und welche proprietär bleiben dürfen – sind unerlässlich.
- Cloud-Talente: Warum Deutschland beim Upskilling aufholt – cloudmagazin
- SaaS-Konsolidierung: Wie CIOs den Tool-Dschungel bändigen – cloudmagazin
- Edge Computing und Industrie 4.0 – cloudmagazin
Weitere Artikel aus dem MBF Media Network
Header-Bildquelle: Pexels / Panumas Nikhomkhai
