Fragen Sie zehn Infrastruktur-Teams, ob sie eine Cloud-Exit-Strategie haben, und neun werden Ja sagen. Fragen Sie, woraus sie besteht, und Sie bekommen meist eine Wiki-Seite, die während eines Vendor-Reviews entstanden ist und auflistet, welche Services proprietär und welche portabel sind. Das ist ein Inventar, keine Strategie. Der eigentliche Test ist unbequemer: Wenn Ihr Provider an einem Dienstagmorgen die Preise verdoppelt, die Jurisdiktion wechselt oder Ihren Account sperrt - wie viele Wochen dauert es, bis Sie Traffic woanders bedienen? Und wer in Ihrem Team kann das beantworten, ohne eine Tabelle zu öffnen?
Der regulatorische Druck dabei ist real, aber nicht der interessante Teil. Der Data Act streicht Wechselgebühren, was der Finanzabteilung ihre Ausrede nimmt. Schrems II und der CLOUD Act haben der Rechtsabteilung ihre schon vor Jahren genommen. Was bleibt, ist technische Realität - und keine Richtlinie ändert daran etwas. Ein Regulator kann den Ausstieg auf dem Papier billiger machen; er kann nicht dafür sorgen, dass Ihre Deployment-Pipeline, Ihr Identitätsmodell, Ihre DNS-Einträge und Ihr Restore-Pfad bei einem zweiten Provider funktionieren. Diese Arbeit liegt bei Ihnen, und sie ist die eigentlichen Kosten.
Was eine Cloud-Exit-Strategie tatsächlich ist
Eine Exit-Strategie ist eine messbare Eigenschaft Ihrer Architektur, kein Dokument. Die Messung ist unverblümt: Welcher Anteil Ihres laufenden Bestands ließe sich bei einem anderen Provider aufbauen, mit Tooling, das Sie bereits betreiben, ohne neuen Code zu schreiben? Für die meisten Teams liegt die ehrliche Antwort irgendwo zwischen vierzig und siebzig Prozent - und die Lücke ist nie dort, wo man sie erwartet hat. Selten liegt sie in der Anwendung. Sie liegt in der Managed Database, der Queue, der Objektspeicher-Semantik und den elf kleinen operativen Gewohnheiten, die nie jemand aufgeschrieben hat.
Der Denkfehler ist zu glauben, dass zwei Provider schon etwas beweisen. Viele Unternehmen betreiben Produktion bei einem Hyperscaler und irgendwo ein vergessenes Testprojekt und nennen das Ergebnis dann Multi-Cloud. Optionalität ist nicht das Vorhandensein eines zweiten Accounts - es ist die Fähigkeit, ihn tatsächlich zu nutzen. Solange nicht ein echter Workload - mit Monitoring, Backups, einem On-Call-Plan und einem tatsächlich durchgeführten Restore - bei einem anderen als Ihrem primären Provider läuft, haben Sie eine zweite Rechnung, keine zweite Option.
Die drei Dinge, die den Wechsel schwer machen
Erstens: Data Gravity - unspektakulär und entscheidend zugleich. Bytes zu kopieren ist billig, sie konsistent zu verschieben, während ein System live ist, ist teuer. Sobald Ihre Daten in einem proprietären Managed Service liegen, wird aus dem Exit kein Kopiervorgang mehr, sondern eine Neuentwicklung von allem, was mit ihnen spricht. Deshalb bewahren Teams, die ihren Zustand in etwas halten, das sie selbst betreiben könnten - auch wenn sie sich heute dagegen entscheiden -, Optionen, die Teams auf vollständig verwalteten Stacks über ein paar Jahre still und leise verlieren.
Zweitens: operatives Muskelgedächtnis. Ihr Team kennt das Identitätsmodell eines Providers, eine Firewall-Abstraktion, eine Art, Netzwerke zu benennen, ein Konsolen-Layout um drei Uhr nachts. Wechseln Sie zu einem zweiten Provider, ist all das unter Druck plötzlich fremd. Die Kosten liegen nicht im Migrationswochenende - sie liegen in den folgenden sechs Monaten, in denen Vorfälle etwas langsamer bearbeitet werden, von Leuten, die raten müssen. Das schreibt niemand in eine Migrationsschätzung, dabei ist es meist der größte Posten darin.
Drittens: Kostenzuordnung. Die meisten Teams können heute nicht sagen, was ein einzelner Workload kostet - was einen Providervergleich im Grunde unmöglich macht. Wenn Ihre Rechnung eine Zahl pro Provider ist und Ihre Architektur aus vierzig Services besteht, verkommt das Exit-Gespräch zu Bauchgefühl. Bevor Sie einen Exit beziffern können, brauchen Sie Ausgaben aufgeschlüsselt nach Service, Projekt und Umgebung, über jeden genutzten Provider hinweg - auch die kleinen, die Sie vergessen haben. Das ist unglamouröse Grundlagenarbeit, aber Voraussetzung für jede weitere Entscheidung hier.
Wie Sie Cloud-Vendor-Lock-in in der EU vermeiden
Wer Cloud-Vendor-Lock-in vermeiden will, findet den EU-Markt in besserer Verfassung vor, als die meisten Teams annehmen. Hetzners Preis-Leistung lässt Hyperscaler-Rechnungen wie einen Rundungsfehler in die falsche Richtung aussehen. OVHcloud betreibt eigene Rechenzentren und eigene Glasfaser quer durch Europa. Scaleway liefert aus Frankreich eine wirklich moderne Developer Experience. UpCloud bietet verlässliches Compute aus Finnland. Keiner von ihnen ersetzt jeden Hyperscaler-Service - aber bei Compute, Block-Storage und Networking, wo der Großteil des Infrastrukturbudgets tatsächlich hingeht, sind sie glaubwürdig und unterliegen ausschließlich EU-Recht.
Die ehrliche Grenze liegt bei Managed Services. Wenn Ihr Produkt auf einer proprietären Serverless-Datenbank, einem bestimmten Event-Bus oder einer Machine-Learning-Plattform ohne Entsprechung anderswo aufbaut, ändert daran auch der größte europäische Enthusiasmus innerhalb eines Quartals nichts. Der sinnvolle Schritt ist keine heroische Alles-oder-nichts-Migration. Es geht darum, genau zu wissen, welche Workloads heute portabel sind, einen Teil davon dort laufen zu lassen, wo Jurisdiktion und Preis passen, und den Rest als bewusste, dokumentierte Entscheidung zu behandeln - nicht als historischen Zufall.
Was eine Exit-Probe tatsächlich bedeutet
Behandeln Sie es wie eine Restore-Übung, denn genau das ist es. Wählen Sie einen echten Workload - nicht die Marketing-Website, sondern etwas mit Zustand und einem Runbook. Bauen Sie ihn bei einem zweiten Provider auf. Leiten Sie einen Bruchteil des echten Traffics dorthin. Bringen Sie ihn absichtlich zum Absturz und prüfen Sie, ob Ihr Monitoring, Ihr Zugriffsmodell und Ihr On-Call-Plan dort auch funktionieren. Notieren Sie anschließend die tatsächlich vergangene Zeit und alles, was Sie überrascht hat. Eine Probe ohne Überraschungen bedeutet meist, dass Sie sich etwas zu Einfaches ausgesucht haben.
Dass die meisten Teams so etwas nie proben, liegt nicht an Faulheit, sondern am Tooling. Jeder zusätzliche Provider bedeutet eine weitere Konsole, ein weiteres Credential-Modell, einen weiteren Billing-Export, weitere Eigenheiten, die man lernen muss - und ein kleines Platform-Team kann das nicht pro Cloud einmal wegstecken. Das ist die operative Steuer, die ein Souveränitätsgespräch still und leise Jahr für Jahr zum Problem des nächsten Jahres macht. Und genau das ist das Problem, das eine Control Plane von Ihrem Schreibtisch nehmen soll.
Genau dafür haben wir Sencai gebaut. Eine Control Plane über elf Provider hinweg - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode und Oracle Cloud - plus Ihre eigenen Server über einen Host-Agent. Netzwerke, Firewalls und DNS werden dort verwaltet, wo sie tatsächlich liegen, beim Provider - sodass ein zweiter Provider zur Kachel in derselben Oberfläche wird statt zu einem zweiten Platform-Team. Ausgaben werden pro Organisation mit Obergrenzen erfasst, sodass das Exit-Gespräch Zahlen hat.
Sie können das auf Ihren eigenen Provider-Accounts betreiben oder die Kapazität über uns beziehen und eine einzige Rechnung behalten - beides wird unterstützt, und Sie können die Wahl später jederzeit ändern. So oder so ist das Ergebnis dasselbe, und es ist die einzige Zahl, die es wert ist, nach oben berichtet zu werden: wie lange es dauern würde, bis Sie woanders laufen. Messen Sie es einmal, und es hört auf, eine Befürchtung zu sein. Messen Sie es jedes Quartal, und es wird zum Hebel - in einer Verhandlung, in einem Beschaffungs-Review und an dem Tag, an dem etwas die Frage erzwingt.