Vendor Lock-in in der Public Cloud: Woher er kommt, was der Ausstieg kostet und wie Sie ihn begrenzen

WebDisk Blog · Kategorie: Cloud · Lesezeit: ~8 Minuten

Kurz gefasst:- Vendor Lock-in (Anbieterabhängigkeit) ist eine Situation, in der ein Anbieterwechsel so viel kostet – an Geld, Zeit und Risiko –, dass er keine realistische Option mehr ist. Er entsteht aus geschlossenen Diensten, proprietären Formaten und Gebühren für das Herausführen von Daten.- Lock-in ist nicht immer ein Fehler: Er kann ein bewusster Kompromiss im Tausch gegen Komfort sein. Gefährlich ist der unbewusste – der erst beim ersten Ausstiegsversuch entdeckt wird.- Das wirksame Gegenmittel sind offene Standards: S3 API, Kubernetes, offene Formate und Open-Source-Software. Auf dieser Philosophie – mit Apache CloudStack und Ceph im Fundament – haben wir WebDisk Cloud aufgebaut.

Ein Szenario, das aus so mancher Firma bekannt ist: Die Infrastruktur läuft, das Team ist eingespielt, die Rechnungen sind vorhersehbar. Bis der Anbieter eines Tages eine Änderung des Lizenzmodells ankündigt, die Preise erhöht oder ein Produkt einstellt, auf dem die Hälfte Ihrer Prozesse steht. Sie beginnen, die Kosten des Umzugs zu rechnen – und es stellt sich heraus, dass die Migration lange Monate Arbeit bedeutet und Sie bis zu ihrem Abschluss nach der neuen Preisliste zahlen. So sieht Vendor Lock-in, also die Anbieterabhängigkeit, von innen aus. Die letzten Jahre haben prominente Beispiele geliefert – von den Lizenzänderungen bekannter Virtualisierungsplattformen in den Händen neuer Eigentümer bis hin zur Preispolitik der Datenbankriesen – doch der Mechanismus selbst ist älter als die Cloud und betrifft jede Schicht der IT.

In diesem Artikel nehmen wir ihn auseinander: woher er kommt, woraus sich die Rechnung für den Ausstieg zusammensetzt, wann Lock-in eine bewusste und rationale Entscheidung sein kann – und wie sich das Risiko mit offenen Standards begrenzen lässt. Wir schreiben für alle, die über Infrastruktur entscheiden: vom Administrator bis zur Geschäftsführung, die das IT-Budget kalkuliert.

Warum beginnt die Anbieterabhängigkeit mit Bequemlichkeit?

Sagen wir eines ganz ehrlich: Jedes kommerzielle Produkt wird so entworfen, dass es möglichst unentbehrlich ist. Das ist kein Vorwurf – so funktioniert der Markt, und auch wir möchten, dass unsere Dienste für unsere Kunden wichtig sind. Das Problem beginnt dort, wo Funktionen, die der Organisation die Arbeit erleichtern, so konstruiert werden, dass sie einen einfachen Ausstieg oder Austausch der Software gegen eine andere unmöglich machen.

Die Folgen dieses Phänomens kennen viele Firmen aus der Praxis: steigende Kosten für die Verlängerung des Supports, die Notwendigkeit, sich an plötzlich geänderte Richtlinien oder Visionen des Herstellers anzupassen, und am Ende – eine Trennung, die das Budget und Monate an Arbeit verschlingt. Die Grenze zwischen „dieses Produkt ist nützlich“ und „wir können ohne es nicht mehr funktionieren“ ist mitunter dünn und lässt sich leicht unbemerkt überschreiten. Deshalb lohnt es sich, die Mechanismen zu verstehen, die uns auf dieser zweiten Seite halten.

Woher kommt Vendor Lock-in?

Geschlossene Managed Services. Die größten Public-Cloud-Anbieter bieten weitläufige Plattformen, auf denen sich alles ohne einen einzigen eigenen Server aufbauen lässt. „Wozu brauchen Sie eine Maschine – schicken Sie uns einfach Ihren Code“ ist die Quintessenz des Modells PaaS (Platform as a Service – Plattform als Dienstleistung, bei der der Anbieter die gesamte Laufzeitumgebung verwaltet). Und das ist wirklich bequem. Aber Code, der für geschlossene Dienste geschrieben wurde – Nachrichtenwarteschlangen, Serverless-Funktionen, proprietäre Datenbanken – spricht mit Schnittstellen, die es nur bei diesem einen Anbieter gibt. Der Ausstieg bedeutet dann nicht das Übertragen der Anwendung, sondern ihr Neuschreiben.

Proprietäre Formate und Schnittstellen. Die zweite Quelle der Abhängigkeit sind Daten in Formaten, die nur die Software eines einzigen Herstellers lesen kann: Maschinen-Images, die nur sein Hypervisor startet, Backups, die nur sein System wiederherstellt, Konfigurationen, die sich nicht in brauchbarer Form exportieren lassen. Solange alles läuft, denkt niemand daran – zum Problem wird das Format genau an dem Tag, an dem Sie gehen wollen.

Die Ökonomie des Transfers. Daten in die Cloud hineinzubringen ist in der Regel kostenlos; sie herauszuführen kostet – pro Gigabyte. Das sind die sogenannten Gebühren für Egress (ausgehenden Datenverkehr). In Verbindung mit dem natürlichen Datenzuwachs wirkt das wie Gravitation: Je mehr Daten Sie ansammeln, desto teurer und langwieriger wird es, sie mitzunehmen – und um die Daten herum siedeln sich weitere Dienste an, weil sich ihre Verarbeitung „beim Anbieter“ günstiger rechnet als außerhalb. Das Recht bewegt sich hier in die richtige Richtung: Der EU Data Act, anwendbar seit dem 12. September 2025, begrenzt die Gebühren für den Anbieterwechsel auf die tatsächlichen Kosten und verbietet sie ab dem 12. Januar 2027 vollständig. Räumen wir gleich das häufigste Missverständnis aus: Die Vorschrift betrifft die Gebühren für den reinen Wechsel zu einem anderen Anbieter – nicht den gewöhnlichen ausgehenden Datenverkehr während der normalen Nutzung des Dienstes; dieser kann weiterhin kostenpflichtig sein. Unabhängig von der Regulierung erklären die größten Anbieter seit 2024 den Transfer beim vollständigen Ausstieg aus ihrer Cloud für kostenlos – in der Regel auf Antrag und unter bestimmten Bedingungen. Die Richtung stimmt, ändert aber nichts am Grundsatz: Die Transferkosten sind der am leichtesten zu berechnende, aber selten der größte Posten der Ausstiegsrechnung.

Und die vierte, leisere Quelle: Menschen. Auch die Kompetenzen des Teams, Zertifikate, fertige Automatisierungen und operative Gewohnheiten binden an die Plattform. Das sieht man auf keiner Rechnung, aber bei einer Migration muss all das neu aufgebaut werden.

Was kostet der Ausstieg wirklich?

Die Rechnung für die Trennung von einem Anbieter besteht aus mehreren Posten – und aufstellen sollte man sie vor dem Einstieg, nicht erst beim Ausstieg:

• das Neuschreiben der Integrationen – jedes Stück Code, das geschlossene Schnittstellen nutzt, muss geändert und erneut getestet werden,
• der parallele Betrieb zweier Umgebungen – während der Migration zahlen Sie gleichzeitig für die alte und die neue,
• der Transfer und die Überprüfung der Daten – nicht nur die Gebühren für den Datenverkehr, sondern auch die Kopierzeit und die Kontrolle, dass unterwegs nichts verloren gegangen ist,
• die Schulung des Teams und der Umbau der Automatisierungen,
• das Ausfallrisiko – am schwersten zu beziffern und am schmerzhaftesten.

Je länger die Beziehung zum Anbieter dauert und je tiefer seine Dienste in Ihre Prozesse hineingewachsen sind, desto größer wird jeder dieser Posten. Genau deshalb funktioniert Lock-in: In jedem einzelnen Moment ist es günstiger zu bleiben – selbst wenn sich die Bedingungen verschlechtern.

Ist Vendor Lock-in immer ein Fehler?

Nicht jeder Lock-in ist ein Fehler, und wir raten niemandem, alles selbst auf eigenen Servern zu bauen. Ein geschlossener Managed Service kauft Ihnen Zeit: Das Team arbeitet am Produkt statt an der Infrastruktur. Wenn der einzigartige Dienst eines bestimmten Anbieters einen echten Vorteil verschafft, kann die bewusste Bindung an ihn eine rationale Geschäftsentscheidung sein.

Entscheidend ist das Wort bewusst. Bevor Sie einen kritischen Prozess von jemandem abhängig machen, beantworten Sie drei Fragen:

1. Was genau wird nicht mehr funktionieren, wenn wir gehen müssen – und was kostet es, das anderswo neu aufzubauen?
2. In welchem Format bekommen wir unsere Daten zurück und haben wir ihren Export in der Praxis getestet, nicht nur in den Versprechen des Vertriebs?
3. Wer trifft die Entscheidung über den Ausstieg und auf welcher Grundlage – haben wir überhaupt einen niedergeschriebenen Notfallplan (Exit-Plan)?

Gibt es auf diese Fragen keine Antworten, hört der Kompromiss auf, ein Kompromiss zu sein – er wird zum Glauben, dass der Anbieter niemals Preisliste, Lizenz oder Eigentümer wechseln wird. Die Erfahrung des Marktes legt nahe, dass dieser Glaube zu weit geht.

Wie lässt sich das Vendor-Lock-in-Risiko begrenzen?

Ein besserer Schutz als die Erklärungen des Anbieters ist eine Architektur, die den Ausstieg technisch einfach macht:

• S3 API für die Objektspeicherung. Die S3 API (die Standardschnittstelle zum Schreiben und Lesen von Objekten, hervorgegangen aus dem Dienst Amazon S3) ist zum faktischen Marktstandard geworden – über S3 gespeicherte Daten übertragen Sie mit jedem von Dutzenden Werkzeugen in jeden kompatiblen Speicher. So funktioniert der Object Storage bei WebDisk, aufgebaut auf dem offenen Speicher Ceph.
• Kubernetes für den Betrieb von Anwendungen. Kubernetes (ein offenes System zum Ausführen und Skalieren von Anwendungen in Containern) sorgt dafür, dass eine in Container verpackte und mit seinen Manifesten beschriebene Anwendung ohne Neuschreiben zwischen Clouds umzieht – es wechselt der Betreiber des Clusters, nicht die Architektur. Dabei helfen wir im Rahmen unserer Kubernetes-Support-Leistungen.
• Offene Daten- und Image-Formate. Backups und Maschinen-Images in Formaten, die mehr als ein Hersteller lesen kann, sind der Unterschied zwischen einer Migration und dem Wiederaufbau der Welt von null.
• Infrastruktur als Code und regelmäßige Export-Tests. Eine Konfiguration, die im Repository gepflegt wird, statt im Panel zusammengeklickt zu sein, lässt sich bei einem anderen Betreiber reproduzieren. Und einen Datenexport, der nie geprobt wurde, sollte man behandeln wie ein Backup, das nie wiederhergestellt wurde – also wie eine ungeprüfte Hypothese.

Ein Vorbehalt der Ausgewogenheit halber: Offene Standards senken die Ausstiegskosten, bringen sie aber nicht auf null. Eine Migration ist immer Arbeit – Kompetenzen, Integrationen und der Datentransfer selbst bleiben auf Ihrer Seite. Der Unterschied besteht darin, dass bei einer offenen Architektur Sie entscheiden, wann sie stattfindet – und nicht der Anbieter mit seiner Preisliste.

Die WebDisk-Philosophie: eine Cloud, aus der man aussteigen kann

Bei WebDisk haben wir es uns zur Ehrensache gemacht, dass das oben beschriebene Problem weder uns noch unsere Kunden trifft. Wir haben bei uns selbst angefangen: Der Kern unserer Plattform ist Open-Source-Software – die Orchestrierung der Cloud übernimmt Apache CloudStack, und die Daten speichert der verteilte Speicher Ceph. Das sind Projekte, die jeder herunterladen, untersuchen und im eigenen Serverraum betreiben kann; niemand kann uns (oder mittelbar unseren Kunden) rückwirkend die Lizenz der veröffentlichten Versionen dieses Fundaments ändern – und offenen Code kann man immer unabhängig weiterentwickeln. Wir nutzen auch kommerzielle Lösungen – aber wir halten sie vom Fundament fern. Orchestrierung und Datenspeicher sind offen, daher bedeutet der Austausch eines Werkzeugs darüber nicht den Austausch der Plattform.

Dieselbe Wahl geben wir unseren Kunden:

• Offene Standards dort, wo wir Ihre Daten aufbewahren – ein mit der S3 API kompatibler Objektspeicher, virtuelle Maschinen auf einer offenen Virtualisierungsplattform sowie Kubernetes-Cluster, die wir für unsere Kunden betreiben und pflegen. Wir bauen auf offenen Standards genau deshalb, damit sich Daten in beide Richtungen übertragen lassen.
• Transfer ohne Falle – in WebDisk VM und in der Public Cloud berechnen wir weder ausgehenden noch eingehenden Datenverkehr; im Object Storage ist der Transfer Teil des Tarifs und keine gesonderte Strafe dafür, dass Sie Ihre Daten mitnehmen.
• Der Rückweg ohne Überraschungen. Daten im Object Storage laden Sie selbst herunter, über die S3 API, mit einem beliebigen Werkzeug – auf demselben Weg, auf dem Sie sie hochgeladen haben. Für die übrigen Ressourcen vereinbaren Sie mit uns einen Export vor dem Ende des Abonnements. Mit Bedauern, aber ohne Hindernisse.

Ein guter Glaubwürdigkeitstest für jeden Anbieter: Fragen Sie nicht danach, wie leicht der Einzug bei ihm ist, sondern wie der Rückweg aussieht. Ein Anbieter, der bereitwillig bei der Migration zu sich hilft – zum Beispiel von VMware – aber über den Ausstieg schweigt, hat Ihre Frage soeben beantwortet. Wir antworten direkt: Ein Kunde, der aus freier Wahl bleibt, ist uns mehr wert als ein Kunde in Geiselhaft. Das ist übrigens die natürliche Konsequenz des Ansatzes, den wir im Artikel über die polnische Cloud ausführlicher beschrieben haben – Datensouveränität beginnt damit, dass Sie Ihre Daten jederzeit mitnehmen können.

Häufige Fragen

Was ist Vendor Lock-in in der Cloud? Vendor Lock-in (Anbieterabhängigkeit) ist eine Situation, in der ein Anbieterwechsel so viel kostet – an Geld, Zeit und Risiko –, dass er keine realistische Option mehr ist. Er entsteht aus vier Quellen: geschlossenen Managed Services, proprietären Datenformaten, Gebühren für ausgehenden Datenverkehr sowie Teamkompetenzen, die an eine einzige Plattform gebunden sind. Der Mechanismus selbst ist älter als die Cloud und betrifft jede Schicht der IT.

Garantiert Open Source die Abwesenheit von Lock-in? Nein – und das behaupten wir auch nicht. Operativer Lock-in (Teamkompetenzen, Integrationen, der Migrationsaufwand selbst) existiert bei jeder Technologie, auch bei einer offenen. Auch Lizenzen von Open-Source-Software werden mitunter geändert – die letzten Jahre brachten einige aufsehenerregende Änderungen dieser Art –, aber sie betreffen künftige Versionen. Niemand kann Ihnen rückwirkend die Nutzungsbedingungen für Code ändern, den Sie bereits haben; die Entwicklung eines offenen Projekts lässt sich unabhängig fortsetzen, und eine darauf aufgebaute Plattform kann bei einem anderen Betreiber oder bei Ihnen selbst laufen.

Ist die Nutzung eines geschlossenen PaaS immer ein Fehler? Nein. Es ist ein Tausch von Flexibilität gegen Zeit – oft lohnend, besonders in der frühen Phase eines Produkts. Das Risiko lässt sich durch Architektur begrenzen: die Geschäftslogik in portablem Code halten und geschlossene Dienste mit einer dünnen Schicht eigener Schnittstellen abschirmen, die man im Fall einer Migration an einer einzigen Stelle austauscht statt in der gesamten Anwendung.

Wie bewertet man das Abhängigkeitsrisiko vor der Vertragsunterzeichnung? Vier Fragen an den Anbieter: In welchem Format und mit welchem Mechanismus exportiere ich alle meine Daten; was kostet ausgehender Datenverkehr; welche der von mir genutzten Schnittstellen sind Marktstandard und welche proprietär; kann ich vor der Entscheidung eine Testmigration mit einer Datenstichprobe durchführen. Ausweichende Antworten sind auch eine Antwort.

Verschwinden Egress-Gebühren dank der Regulierung von selbst? Teilweise – und nur an einer einzigen, konkreten Stelle. Der EU Data Act, anwendbar seit dem 12. September 2025, begrenzt die Gebühren für den reinen Wechsel auf die Höhe der tatsächlichen Kosten und schafft sie ab dem 12. Januar 2027 vollständig ab. Die Unterscheidung ist wichtig: Die Vorschrift betrifft die Gebühren für den Anbieterwechsel, nicht den gewöhnlichen ausgehenden Datenverkehr, wenn Sie den Dienst einfach nutzen – dieser kann weiterhin kostenpflichtig sein. Die Regulierung schreibt auch nicht für Sie eine Anwendung neu, die mit geschlossenen Diensten verflochten ist: Die technische Portabilität hängt weiterhin von den Architekturentscheidungen ab, die Sie heute treffen.

Fazit

Vendor Lock-in entsteht nicht aus bösem Willen, sondern aus der Summe kleiner Bequemlichkeiten, von denen jede für sich genommen Sinn ergibt. Auch die Verteidigung erfordert keinen Heroismus: offene Standards, wo immer möglich, ein bewusst durchgerechneter Kompromiss dort, wo sich ein geschlossener Dienst wirklich lohnt, und ein geprobter Exit-Plan – bevor er gebraucht wird. Und falls Sie zwischen einem globalen Giganten und einem lokalen Anbieter abwägen: Dieses Dilemma behandeln wir gesondert im Artikel Hyperscaler oder polnische Cloud. Wenn Sie über eine Architektur sprechen möchten, aus der man im Ernstfall aussteigen kann – oder über den Umzug Ihrer aktuellen Infrastruktur in eine auf offenen Standards aufgebaute Cloud – schreiben Sie uns.