Vendor-Lock-in vermeiden: Wie ihr Cloud-Anwendungen wechselfähig baut
Vendor-Lock-in vermeidet ihr nicht mit einem einzelnen Tool, sondern mit Architekturentscheidungen: Container und Kubernetes statt proprietärer Compute-Dienste, S3-kompatibler Object Storage, PostgreSQL statt herstellergebundener Datenbanken und Infrastructure as Code mit Terraform oder OpenTofu. Der EU Data Act entschärft die Lage rechtlich – Wechselentgelte beim Anbieterwechsel dürfen seit dem 12.9.2025 nur noch kostendeckend sein und sind ab dem 12.1.2027 komplett verboten. Aber: Das Verbot gilt nur für den Wechsel selbst, nicht für den laufenden Betriebs-Egress. Die Rechnung dafür schreibt weiterhin eure Architektur. Wer heute neu baut oder migriert, sollte Wechselfähigkeit deshalb als Designziel behandeln, nicht als Notfallplan.
TL;DR
- Die zwei größten Lock-in-Treiber sind proprietäre Managed-Dienste und Egress-Kosten: 1 TB Internet-Egress kostet bei AWS rund 90 USD (~0,09 $/GB für die ersten 10 TB/Monat), bei Hetzner sind 20 TB bei Cloud-Servern inklusive – Faktor ~90.
- EU Data Act: Wechselentgelte sind seit 12.9.2025 auf kostendeckende Höhe begrenzt, ab 12.1.2027 komplett verboten. Das gilt aber nur für Exit-Entgelte, nicht für laufenden Betriebs-Egress.
- Technische Hebel: Container/Kubernetes, S3-kompatibler Object Storage, PostgreSQL und offene Standards, Terraform/OpenTofu für reproduzierbare Umgebungen.
- Abstraktion mit Bedacht: Crossplane und Multi-Cloud-Frameworks lohnen sich nur bei echtem Multi-Cloud-Bedarf.
- Kostenkontext: Laut Flexera 2026 (753 Befragte) gelten 29 % der Cloud-Ausgaben als verschwendet, und weniger als die Hälfte der Unternehmen nutzt Commitment-Rabatte.
- EU-Alternativen sind real: Hetzner ~14,3x Compute-Wert pro Euro gegenüber AWS, Scaleway ~4,8x, IONOS mit 2 TB freiem Egress pro Monat.
Was ist Vendor-Lock-in – und wo entsteht er wirklich?
Vendor-Lock-in heißt: Der Wechsel zu einem anderen Anbieter ist technisch oder wirtschaftlich so teuer, dass er faktisch nicht stattfindet. In der Cloud entsteht das selten durch böse Absicht und fast immer durch zwei Mechanismen.
Erstens: proprietäre Managed-Dienste. Wer seine Anwendung direkt gegen die herstellerspezifischen APIs eines Hyperscalers baut – Compute, Datenbank, Queues, Auth –, schreibt Code, der nur dort läuft. Jeder dieser Dienste ist für sich genommen bequem. In Summe entsteht eine Anwendung, die ohne Re-Engineering nirgendwo anders lauffähig ist.
Zweitens: Egress-Kosten. Daten in die Cloud hinein sind günstig, Daten heraus sind teuer. Bei AWS kostet Internet-Egress rund 0,09 $/GB für die ersten 10 TB pro Monat – 1 TB Egress schlägt also mit etwa 90 USD zu Buche. Bei Hetzner sind 20 TB bei Cloud-Servern schlicht inklusive. Das ist ein Faktor von rund 90. Je mehr Daten ihr ansammelt, desto teurer wird jeder Weg nach draußen – egal ob zum neuen Anbieter, zu euren Kunden oder zu einem externen System. Diese „Datengravitation” ist der leise, aber wirksamste Lock-in-Mechanismus.
Was ändert der EU Data Act – und was nicht?
Der EU Data Act ist seit dem 12.9.2025 anwendbar und nimmt sich genau dieses Problem vor – allerdings nur teilweise. Konkret:
- Bis zum 12.1.2027 dürfen Wechselentgelte beim Anbieterwechsel nur noch kostendeckend sein. Der Anbieter darf am Exit also nichts mehr verdienen.
- Ab dem 12.1.2027 sind Wechselentgelte komplett verboten. Der Datenexport beim Anbieterwechsel darf dann nicht mehr berechnet werden.
Das ist eine echte Entschärfung – aber mit einer wichtigen Einschränkung: Das Verbot gilt nur für Wechsel- und Exit-Entgelte, nicht für den laufenden Betriebs-Egress. Wer im Normalbetrieb Daten an Nutzer, Partner oder andere Systeme ausliefert, zahlt dafür weiterhin die regulären Egress-Preise des Anbieters. Der Data Act macht den Auszug günstiger, nicht die Miete.
Daraus folgt eine nüchterne Einordnung: Die Rechtslage hilft euch beim Exit, aber die Architektur bleibt der größere Hebel – sie entscheidet, ob ein Wechsel überhaupt technisch realistisch ist und was der laufende Betrieb kostet. Und wie bei jeder jungen Regulierung gilt: Viele Detailfragen zur Auslegung klären sich erst in der Praxis. Dieser Artikel ist eine technische Einordnung, keine Rechtsberatung.
Welche technischen Hebel machen euch wechselfähig?
Wechselfähigkeit ist kein Alles-oder-nichts. Es geht darum, an den richtigen Stellen auf offene Standards zu setzen, damit der Kern eurer Anwendung portabel bleibt.
| Baustein | Lock-in-Variante | Wechselfähige Alternative |
|---|---|---|
| Compute | proprietäre Compute-/Serverless-Dienste | Container + Kubernetes |
| Object Storage | herstellerspezifische Storage-APIs | S3-kompatibler Object Storage |
| Datenbank | proprietäre DB-Dienste | PostgreSQL |
| Identität/Login | proprietäre Auth-Dienste | OpenID Connect |
| Provisionierung | Klick-Setups in der Konsole | Terraform/OpenTofu |
Container und Kubernetes statt proprietärer Compute-Dienste. Was als Container läuft, läuft grundsätzlich bei jedem Anbieter, der Kubernetes anbietet – und das sind heute praktisch alle. Ein ehrlicher Hinweis dazu: Kubernetes löst das Portabilitätsproblem, nicht das Kostenproblem. Laut Cast AI liegt 2026 die durchschnittliche CPU-Auslastung in Kubernetes-Clustern bei nur 8 %. Wer K8s einführt, sollte Rightsizing von Anfang an mitdenken, sonst tauscht ihr Lock-in-Kosten gegen Überprovisionierungs-Kosten.
S3-kompatibler Object Storage. Die S3-API ist der De-facto-Standard für Object Storage und wird von fast allen EU-Anbietern unterstützt. Wer seinen Code gegen die S3-API schreibt statt gegen herstellerspezifische Erweiterungen, kann den Storage-Anbieter wechseln, ohne die Anwendung anzufassen.
Offene Standards bei Datenbank und Identität. PostgreSQL statt eines proprietären Datenbank-Dienstes bedeutet: Dump, Restore, fertig – bei jedem Anbieter. OpenID Connect statt eines herstellergebundenen Auth-Dienstes bedeutet: Der Login-Flow funktioniert überall gleich.
Infrastructure as Code mit Terraform oder OpenTofu. Wenn eure gesamte Umgebung als Code beschrieben ist, ist sie reproduzierbar – beim selben Anbieter (Disaster Recovery, Staging) und als Grundlage für einen Wechsel. Eine Infrastruktur, die nur als Sammlung von Konsolen-Klicks existiert, kann niemand verlässlich woanders nachbauen.
Wann lohnt sich Abstraktion – und wann ist sie Overkill?
Hier müssen wir ehrlich sein, denn an dieser Stelle wird oft über das Ziel hinausgeschossen: Nicht jede Abstraktionsschicht lohnt sich. Jede zusätzliche Schicht – sei es ein Multi-Cloud-Framework wie Crossplane oder eine selbstgebaute Adapter-Ebene über allen Cloud-APIs – kostet Entwicklungszeit, Komplexität und oft Funktionalität, weil ihr euch auf den kleinsten gemeinsamen Nenner beschränkt.
Unsere Faustregel: Crossplane und Multi-Cloud-Frameworks nur bei echtem Multi-Cloud-Bedarf. Wenn ihr tatsächlich parallel bei mehreren Anbietern betreiben müsst, kann sich das rechnen. Für die meisten Mittelständler ist das Ziel aber nicht „läuft überall gleichzeitig”, sondern „kann mit vertretbarem Aufwand umziehen”. Dafür reichen die Standards aus dem vorigen Abschnitt – Container, S3-API, PostgreSQL, OIDC, IaC – völlig aus, ohne dass ihr eine zusätzliche Plattform pflegen müsst.
Was kostet Lock-in – und was kosten die Alternativen?
Lock-in ist nicht nur ein Risiko für den Wechselfall, sondern ein laufender Kostenfaktor: Wer nicht wechseln kann, hat keine Verhandlungsposition. Der Kontext dazu aus der Flexera-Studie 2026 (753 Befragte): 29 % der Cloud-Ausgaben gelten als verschwendet, und weniger als die Hälfte der Unternehmen nutzt Commitment-Rabatte. Viele zahlen also Premium-Preise, ohne die Gegenleistung auszuschöpfen.
Dabei sind die europäischen Alternativen preislich bemerkenswert – ein paar verifizierte Eckdaten (Stand Juni 2026, „–” = keine verifizierte Zahl vorliegend):
| Anbieter | Internet-Egress | Compute-Preis-Leistung ggü. AWS |
|---|---|---|
| AWS | ~0,09 $/GB (erste 10 TB/Monat); 1 TB ≈ 90 USD | Referenz |
| Hetzner | 20 TB bei Cloud-Servern inklusive | ~14,3x Wert pro Euro (Callista-Benchmark, Feb. 2026) |
| Scaleway | – | ~4,8x Preis-Leistung |
| IONOS | erste 2 TB/Monat frei | – |
Zur Ehrlichkeit gehört auch: Hetzner hat zum 1.4.2026 die Preise um 30–37 % erhöht (DRAM-Krise) – der CX23 mit 2 vCPU/4 GB stieg von 2,99 auf 3,99 EUR/Monat. Selbst nach dieser Erhöhung liegt der Compute-Wert pro Euro laut Callista-Benchmark bei rund dem 14,3-Fachen von AWS. Der Punkt ist nicht „Hyperscaler sind böse” – sie bieten Dienste, die es woanders nicht gibt. Der Punkt ist: Wer wechselfähig baut, kann diese Preisunterschiede überhaupt erst nutzen, Workload für Workload.
Wie geht ihr pragmatisch vor?
Wechselfähigkeit muss kein Großprojekt sein. Ein realistischer Fahrplan:
- Bestandsaufnahme. Welche proprietären Dienste nutzt ihr heute, und welche davon sind tief in den Code verdrahtet? Das ist eure Lock-in-Landkarte.
- Exit-Kosten je Workload bewerten. Nicht jede Anwendung muss portabel sein. Ein internes Tool mit wenigen Nutzern darf gebunden bleiben; das Kernsystem mit euren Daten eher nicht.
- Neue Projekte standardmäßig portabel bauen. Container, S3-API, PostgreSQL, OpenID Connect – das kostet bei einem Neubau kaum Mehraufwand, spart aber später Re-Engineering.
- Infrastructure as Code einführen. Terraform oder OpenTofu für alles Neue, schrittweise Nachdokumentation für das Bestehende.
- Rightsizing mitdenken. Gerade bei Kubernetes: Bei durchschnittlich 8 % CPU-Auslastung in Clustern ist Überprovisionierung der stille Kostentreiber.
Bei Rocket-Monkeys bauen wir Cloud-Anwendungen genau nach diesem Prinzip: offene Standards im Kern, proprietäre Dienste nur dort, wo sie einen klaren, bewussten Mehrwert bringen – und mit dokumentiertem Exit-Pfad. Wie das Thema in das größere Bild aus Data Act, EU-Anbietern und digitaler Souveränität passt, haben wir auf unserer Übersichtsseite zur Cloud-Souveränität zusammengefasst.
Unverbindlich drüber reden?
Wenn ihr wissen wollt, wie stark eure aktuelle Architektur gebunden ist und was ein realistischer Weg zu mehr Wechselfähigkeit kostet, schaut euch das mit uns an. In einem unverbindlichen Erstgespräch gehen wir eure Workloads durch, identifizieren die größten Lock-in-Punkte und ordnen ein, wo sich Portabilität für euch wirklich lohnt – und wo nicht. Schreibt uns einfach an info@rocket-monkeys.com.