Was ist Vendor-Lock-in in der Cloud?

Vendor-Lock-in in der Cloud ist eine so tiefe Abhängigkeit von einem Anbieter, dass ein Wechsel mehr Geld, Zeit und Risiko kosten würde als das Bleiben. Niemand entscheidet sich bewusst dafür; er wächst heran – ein proprietärer Dienst, ein Terabyte, eine Spezialistenstelle nach der anderen –, bis der Ausstiegspreis eine Zahl ist, die niemand in einem Meeting laut aussprechen möchte.

Das Wichtigste in Kürze

Der Preis des Ausstiegs in Zahlen

Lock-in bleibt abstrakt, bis er auf einer Rechnung steht:

# Die Ausstiegsmaut allein für Daten (klassische Egress-Preise)
50 TB gespeichert, Abfluss zu ~0,09 US-$/GB:
  50.000 GB × 0,09 US-$  ≈  4.500 US-$ — pro Kopie, pro Versuch

# Im echten Maßstab, laut Börsenprospekten und Engineering-Blogs:
  große Streaming- und Social-Plattformen meldeten
  20–50 Mio. US-$ pro Jahr allein für Egress

Und die Code-Seite der Maut: Eine App, die gegen proprietäre APIs geschrieben ist, zahlt in Neuschreibungen, was die Daten an Egress zahlen. Das Gegenmuster ist Code, der den Anbieter als Implementierungsdetail behandelt:

// JavaScript / Node.js — Back4app JS SDK
// The whole "migration": point the SDK at any Parse Server you run
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // hosted today
// Parse.serverURL = 'https://api.yourcompany.com/parse'; // self-hosted tomorrow
// Every query, ACL, and Cloud Function call stays identical.

// Flutter / Dart — Back4app Flutter SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
await Parse().initialize(
  'APP_ID',
  'https://parseapi.back4app.com', // or https://api.yourcompany.com/parse
  clientKey: 'CLIENT_KEY',
);

// iOS / Swift — Back4app Swift SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
ParseSwift.initialize(
  applicationId: "APP_ID",
  clientKey: "CLIENT_KEY",
  serverURL: URL(string: "https://parseapi.back4app.com")! // or your own server
)

// Android / Kotlin — Back4app Android SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
Parse.initialize(
  Parse.Configuration.Builder(context)
    .applicationId("APP_ID")
    .clientKey("CLIENT_KEY")
    .server("https://parseapi.back4app.com") // or https://api.yourcompany.com/parse
    .build()
)

Wie sich Lock-in aufschaukelt

Die fünf Arten von Lock-in

Die Zuordnung, die der ersten Zeile die Schärfe nimmt: Für die meisten proprietären Dienste gibt es eine offene Entsprechung – verwaltete Datenbank → PostgreSQL-kompatibel; proprietäre Queue → Kafka oder RabbitMQ; proprietäre Funktionen → offene Runtimes wie Knative oder OpenFaaS; proprietäres Backend → Parse Server. Die Open-Source-kompatible Variante eines verwalteten Dienstes zu wählen kostet bei der Einführung wenig und verändert den Preis des gesamten Ausstiegs.

Gebundene vs. portable Architektur

Die regulatorische Wende

Die Ökonomie des Lock-ins hat sich per Gesetz geändert. Der EU Data Act – anwendbar seit September 2025 – begrenzt die Entgelte, die Anbieter Kunden für einen Wechsel berechnen dürfen, auf die direkten Kosten, und ab Januar 2027 sind Wechselentgelte für Cloud-Dienste, die Kunden in der EU bedienen, vollständig verboten. Große Anbieter kamen dem 2024 zuvor und verzichten seither auf Egress-Gebühren für Kunden, die komplett abwandern. Das Kleingedruckte zählt: Diese Verzichte gelten in der Regel für den Ausstieg, nicht für routinemäßige Datenbewegungen zwischen mehreren Clouds – und gegen proprietäre APIs oder Know-how-Bindung unternimmt das Gesetz nichts. Die Regulierung hat die Maut gesenkt; ob es die Straße überhaupt gibt, entscheidet weiterhin die Architektur.

Typische Anwendungsfälle

• Verwaltete Dienste bewusst auswählen. Jede “bequeme” proprietäre Einführung wird gegen ihre Open-Source-kompatible Alternative abgewogen – die günstigste Lock-in-Entscheidung ist die, die bei der Einführung getroffen wird.
• Ausstiegsstrategie planen. Compliance-Vorgaben und Aufsichtsgremien verlangen zunehmend dokumentierte, getestete Cloud-Ausstiegspläne; die Aufstellung in der Tabelle oben ist die Vorlage.
• Vertragsverhandlungen. Wer seine tatsächlichen Wechselkosten kennt, hat bei der Verlängerung ein Druckmittel – Anbieter kalkulieren ihre Angebote gegen Ihren Ausstiegspreis.
• Fusionen und Konsolidierung. Bei der Cloud-Konsolidierung nach einer Übernahme werden ungetestete Ausstiege zu sehr teuren Überraschungen.
• Plattformwahl für neue Produkte. Der Moment mit der größten Wahlfreiheit und den geringsten Kosten – in dem Plattformen auf Open-Source-Basis den Lock-in von einer Falle in eine Präferenz verwandeln.

Sollten Sie gegen Lock-in optimieren? Eine Entscheidungsmatrix

Die Synthese: Tiefe ist in Ordnung, Blindheit nicht. Nehmen Sie das Tempo eines einzelnen Anbieters mit – mit Open-Source-kompatiblen Diensten, wo es sie gibt, einem Exportweg, den Sie tatsächlich durchgespielt haben, und einem Ausstiegspreis, den Sie laut nennen können.

Grenzen und Trade-offs

• Auch Portabilität hat ihren Preis. Abstraktionsschichten, Multi-Cloud-Werkzeuge und Dienstauswahl auf dem kleinsten gemeinsamen Nenner kosten echte Entwicklungszeit – investiert in den Schutz vor einer Migration, die vielleicht nie kommt.
• Multi-Cloud ist kein Allheilmittel. Zwei Anbieter können zwei halb beherrschte Plattformen bedeuten, eine doppelt so große Integrationsfläche und Daten, die auf zwei Gravitationszentren verteilt sind.
• Open Source verlagert das Risiko, statt es zu beseitigen. Wer einen offenen Stack selbst hostet, tauscht die Abhängigkeit vom Anbieter gegen Betriebsaufwand; der Ausstieg ist real, aber nicht kostenlos.
• Verträge überdauern Architekturen. Auch die sauberste containerisierte Landschaft bleibt gebunden, wenn für den Rabatt eine dreijährige Verpflichtung unterschrieben wurde.
• Der Teil, der sich nicht entschärfen lässt: Was einen Anbieter wirklich unterscheidet, bietet per Definition sonst niemand. Nutzen Sie es – bewusst, an einer Stelle, hinter einer Schnittstelle, die Ihnen gehört.

Vendor-Lock-in mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Lock-in-Analyse fällt ungewöhnlich kurz aus: Der gesamte Stack ist Open Source, sodass dasselbe Backend – Daten, SDK-Aufrufe, Funktionen, ACLs – selbst gehostet auf jeder Infrastruktur läuft. Die in den Code-Tabs oben gezeigte Migration ist eine Änderung der URL, kein Neuschreiben. Damit wird der übliche BaaS-Trade-off (größter Komfort, stärkster Lock-in) zu verwaltetem Komfort mit einem jederzeit verfügbaren, erprobbaren Ausstieg – Abhängigkeit als Entscheidung, die Sie immer wieder neu treffen, statt als Tür, die hinter Ihnen ins Schloss gefallen ist.