Vendor-Lock-in: Auch Cloud ist eine Falle
CMS-Lock-in versteht jeder. Cloud-Lock-in ist subtiler und teurer. Wie man von Anfang an portabel baut, statt später Millionen für die Migration zu zahlen.
Die unterschätzte Bindung
Cloud-Lock-in ist keine technische Frage, sondern eine wirtschaftliche
Wer denkt, AWS sei nur „ein Hoster mit vielen Diensten“, hat den eigentlichen Bindungs-Hebel noch nicht verstanden.
Der Trick mit den Managed Services
EC2 kann man migrieren. DynamoDB, Cognito, Step Functions, EventBridge, SQS, Kinesis und Lambda mit AWS-spezifischen Triggern eher nicht. Jede dieser Komponenten ersetzt einen Standard durch eine proprietäre API. Ein Jahr später ist die Anwendung ohne AWS nicht mehr lauffähig - nicht weil es technisch unmöglich wäre, sondern weil eine Migration einem Rewrite gleichkommt. Genau das ist die Lock-in-Mechanik, und sie ist nicht zufällig so gebaut.
Egress-Gebühren als Migrationsbremse
AWS, Azure und GCP rechnen den Daten-Abfluss nach außen separat ab. Bei 50 TB Bestand reden wir je nach Region über fünfstellige Beträge - nur um die Daten zum nächsten Anbieter zu bringen. Zufluss ist kostenlos, Abfluss ist teuer. Das ist kein Versehen, sondern ein Geschäftsmodell. Wer das früh kennt, baut den Daten-Pfad anders auf.
Was wirklich teuer wird
Die Stellen, an denen man sich am stärksten festnagelt
Drei Schichten sind besonders kritisch: Identität, Daten und Workflow-Orchestrierung. Wer hier proprietäre Dienste einsetzt, baut die teuerste Form von Lock-in ein.
Identitäts-Lock: Cognito, Azure AD B2C, Firebase Auth
Wer Login und Session-Handling an Cognito, Azure AD B2C oder Firebase Auth hängt, exportiert seine Nutzer-Datenbank nur noch eingeschränkt. Passwort-Hashes bleiben drin, Refresh-Token-Schemas sind proprietär, MFA-Setups sind anbieter-spezifisch. Wir setzen lieber auf Keycloak, Authentik oder selbst gebaute OAuth-2-Setups auf Laravel-Basis - portabel, auditierbar, kein Migrations-Albtraum.
Datenbank-Lock: DynamoDB, Cosmos DB, Bigtable
Proprietäre NoSQL-Dienste bieten Skalierung in einem Klick und binden im Gegenzug die gesamte Daten-Schicht an einen Anbieter. DynamoDB-Streams, Single-Table-Designs und Cosmos-DB-Partition-Keys lassen sich nicht 1:1 nach PostgreSQL übertragen. Wir bauen Daten-Modelle auf PostgreSQL oder MySQL mit klaren Domain-Grenzen. Das skaliert für 99 Prozent der Anwendungen ausreichend - und läuft überall.
Workflow-Lock: Step Functions, Logic Apps, Cloud Workflows
Visuelle Workflow-Engines der Hyperscaler sind verlockend für Architekten, die schnell Diagramme zeigen wollen. Sie sind aber komplett anbieter-spezifisch - ihre JSON- oder YAML-Definitionen sind nicht standardisiert. Wer ernsthaft portabel bleiben will, nutzt Temporal, Camunda oder schlicht Laravel-Jobs mit klaren Queue-Workern. Das ist weniger glamourös, lässt sich aber in zwei Wochen statt in zwei Quartalen migrieren.
Cloud-Audit gefällig?
Wir prüfen Ihr Setup auf Lock-in-Risiken und zeigen, was eine Migration heute realistisch kostet.
Portabilität als Design-Prinzip
Wie man portabel baut, ohne Multi-Cloud-Theater
Portabel heißt nicht: alles auf drei Clouds parallel. Es heißt: jederzeit umziehbar sein, falls nötig. Das ist eine Architektur-Haltung, keine Tool-Auswahl.
Open Standards als Default
Wir bauen auf Standard-Linux-Servern, S3-kompatiblem Object-Storage (MinIO, Hetzner Object Storage, Cloudflare R2), PostgreSQL und standardisierten Message-Queues wie Redis oder RabbitMQ. Jede dieser Komponenten läuft auf jedem Cloud-Anbieter und genauso auf Bare-Metal in einem Hetzner-Rechenzentrum. Wenn wir morgen umziehen müssen, ist das eine Frage von Tagen, nicht von Quartalen.
Cloud-Native ja, Cloud-Vendor nein
Cloud-Native bedeutet zwölf-Faktor-Apps, Container-Workloads, deklarative Infrastruktur. Cloud-Vendor-Native bedeutet AWS Lambda + DynamoDB + EventBridge in einer engen Verflechtung. Das eine ist ein Architektur-Pattern, das überall läuft. Das andere ist ein goldener Käfig. Wir nehmen Pattern A und lassen B den Beratern, die nach Stunden abrechnen.
Infrastructure-as-Code, anbieter-unabhängig
Terraform oder OpenTofu beschreibt Infrastruktur deklarativ und kann sowohl AWS als auch Hetzner Cloud, Azure und GCP ansteuern. Wer hier Provider-spezifische Konstrukte vermeidet, erspart sich später viel Aufräumarbeit. Ansible, NixOS und einfache shell-basierte Bootstrap-Skripte halten die Server-Vorbereitung ebenfalls portabel. Klingt nach Aufwand - ist aber nach dem ersten Setup Routine.
Was wir empfehlen
Multi-Cloud als Exit-Option, nicht als Dauerzustand
Echte parallele Multi-Cloud-Setups sind selten sinnvoll. Wir empfehlen Mono-Cloud mit dokumentierter Exit-Strategie - getestet, nicht nur als Folie.
Mono-Cloud spart Komplexität
Ein Anbieter, ein Identity-System, ein Billing, ein Monitoring. Multi-Cloud sieht auf Folien gut aus, kostet aber in der Praxis doppelte Tooling-Lizenzen, doppeltes Wissen im Team und eine Latenz-Hölle, sobald Dienste über Anbieter-Grenzen kommunizieren. Wir empfehlen einen Hauptanbieter - bevorzugt Hetzner oder Laravel Cloud im EU-Kontext - und einen ausgemachten Backup-Pfad.
Migrations-Drill, einmal im Jahr
Exit-Strategien, die nie getestet wurden, sind keine Strategien. Wir empfehlen einmal jährlich einen Migrations-Drill: Ein nicht-produktives Sub-System wird komplett auf einen anderen Anbieter umgezogen. Was dabei knirscht, ist die eigentliche Lock-in-Schwachstelle. Die wird dokumentiert und im nächsten Sprint adressiert. So bleibt Portabilität ein lebender Zustand, nicht ein Wunsch im Lasten-Heft.
Verträge mit Exit-Klauseln verhandeln
Cloud-Lock-in ist auch ein juristisches Thema. In Enterprise-Verträgen lohnen Klauseln zu Daten-Export-Pflichten, Egress-Kosten-Caps bei Vertragsende und Mindest-Migrations-Fenstern. Das verhandeln viele Einkaufs-Abteilungen heute schon - Engineering und Legal sollten dabei am selben Tisch sitzen. Wir liefern auf Wunsch die technische Anforderungs-Liste dafür.
Artikel teilen
Wie fest sitzt Ihr Stack im Käfig?
Wir machen einen ehrlichen Cloud-Lock-in-Check für Ihr Setup - mit konkreten Migrations-Aufwänden in Stunden, nicht in Powerpoint-Folien.
Keine generische Beratung, sondern eine Liste der drei teuersten Bindungs-Punkte in Ihrer Architektur und ein Vorschlag, wie Sie sie in den nächsten zwei Quartalen abbauen. Ohne Religionskrieg gegen die Hyperscaler, sondern mit klaren Zahlen.