Cloud Exit: So holst du Workloads zurück ins eigene Rechenzentrum
Der Rückweg ist teurer als der Hinweg, vor allem wegen der Datenausleitung und der Managed Services, für die du plötzlich selbst Betrieb brauchst. Rechne mit Personal, nicht nur mit Hardware, sonst kippt die Ersparnis im zweiten Jahr.
Warum der Rückweg aus der Public Cloud gerade jetzt auf dem Tisch liegt
Die meisten Cloud-Migrationen der letzten Jahre waren Lift-and-Shift. Virtuelle Maschinen sind umgezogen, die Architektur ist geblieben, und mit ihr die Rechnung für Compute, Block-Storage, Snapshots, NAT-Gateways und Datentransfer. Wenn die Last vorhersehbar und dauerhaft ist, verliert das Argument der Elastizität seine Kraft, denn du zahlst rund um die Uhr für Kapazität, die du auch selbst vorhalten könntest. Dazu kommen regulatorische Fragen aus NIS2, DORA und der Diskussion um Souveränität, die IT-Leitung und Geschäftsführung zwingen, den Ausstiegspfad überhaupt beschreiben zu können.
Der typische Fehler ist, den Cloud Exit als reine Umzugsaufgabe zu behandeln. Der eigentliche Aufwand steckt nicht im Kopieren der VM-Images, sondern in den Managed Services drumherum. Eine RDS-Instanz, ein S3-Bucket mit Lifecycle-Regeln, eine IAM-Struktur, ein Loadbalancer mit verwalteten Zertifikaten und eine zentrale Log-Pipeline haben im eigenen Rechenzentrum kein Gegenstück, das man einfach anklickt. Für jeden dieser Bausteine brauchst du einen Betreiber, ein Backup-Konzept, ein Monitoring und jemanden, der nachts erreichbar ist.
Der zweite Fehler ist die Kostenrechnung, die nur die Cloud-Rechnung gegen den Hardwarepreis stellt. Realistisch gehören Rack, Strom, Kühlung, Netzanbindung, redundante Standorte, Ersatzteile, Wartungsverträge, Lizenzen und vor allem Personal in die Gegenüberstellung. Umgekehrt wird beim Ausstieg oft der einmalige Aufwand unterschätzt: Datenexport, Parallelbetrieb über mehrere Monate und die Umstellung von Deployment-Pipelines, die auf Cloud-APIs gebaut sind. Wer diese Posten offen auf den Tisch legt, kommt am Ende zu einer belastbaren Entscheidung, egal in welche Richtung sie ausfällt.
Cloud Exit in sechs Etappen
- 01 Workloads und Abhängigkeiten erfassen
- 02 Vollkosten beider Seiten rechnen
- 03 Zielarchitektur festlegen
- 04 Plattform aufbauen und automatisieren
- 05 Daten replizieren und in Wellen umschalten
- 06 Betrieb, Backup und Notfallplan schärfen
Der Weg zurück ins eigene Rechenzentrum, Schritt für Schritt
Ein Cloud Exit gelingt, wenn du ihn wie ein Migrationsprojekt mit klarer Zielarchitektur führst und nicht wie eine Kündigung. Diese Punkte bilden das Vorgehen ab, das sich in der Praxis bewährt hat.
Workloads inventarisieren und ehrlich bewerten
Erfasse jede Anwendung mit ihren Abhängigkeiten, ihrem Lastprofil und ihrer Datenmenge. Klassische VMs, Datenbanken mit stabilem Volumen und Batch-Verarbeitung wandern gut zurück. Alles, was stark schwankende Spitzen hat oder tief an proprietären Diensten hängt, gehört auf eine eigene Liste und wird bewusst entschieden, statt aus Prinzip mitgenommen zu werden.
Zielarchitektur festlegen statt Produkt kaufen
Die tragfähige Zielarchitektur besteht aus drei Ebenen: einer Virtualisierungsplattform für die klassischen VMs, einem verteilten Storage für Block, Datei und Objekt sowie einer Container-Plattform für alles, was schon cloud-nativ gebaut ist. Proxmox VE mit Ceph deckt die ersten beiden Ebenen ab, Kubernetes die dritte. Mit KubeVirt kannst du beides zusammenführen und VMs auf derselben Control Plane betreiben wie Container.
Cloud-Dienste durch betreibbare Gegenstücke ersetzen
Für jeden Managed Service brauchst du eine Entscheidung: PostgreSQL oder MariaDB statt RDS, MinIO oder Ceph RGW mit S3-Schnittstelle statt S3, HAProxy oder NGINX statt des verwalteten Loadbalancers, Prometheus, Grafana und Loki statt CloudWatch. Wichtig ist weniger das Produkt als die Frage, wer es patcht, sichert und im Störfall wiederherstellt.
Automatisierung mitnehmen, nicht neu erfinden
Terraform und Ansible funktionieren im eigenen Rechenzentrum genauso wie in der Cloud, nur mit anderen Providern und Inventories. Wenn deine Provisionierung heute schon als Code vorliegt, ist ein großer Teil der Arbeit getan. Fehlt sie, ist der Cloud Exit der richtige Zeitpunkt, sie einzuführen, statt Server wieder von Hand aufzusetzen.
Netz, Datenexport und Egress früh planen
Der Datentransfer ist der Posten, der Zeitpläne kippt. Kläre früh, wie viel Volumen wirklich bewegt werden muss, ob der Anbieter die Egress-Gebühren beim vollständigen Ausstieg erlässt, und ob eine Direktverbindung oder ein physischer Transport sinnvoller ist als der Weg über das Internet. Ein Erstsync mit anschließender Replikation hält die eigentliche Umschaltung kurz.
In Wellen migrieren und den Rückweg offenhalten
Beginne mit einer unkritischen Anwendung, die den kompletten Stack durchläuft, von Deployment über Backup bis Monitoring. Erst wenn eine Welle im Betrieb stabil läuft, folgt die nächste. Halte für jede Welle einen definierten Rollback bereit und kündige die Cloud-Ressourcen erst, wenn der Betrieb vor Ort über einen vollständigen Backup- und Restore-Zyklus getragen hat.
Kurse zu Cloud Exit und On-Premise-Betrieb bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu Cloud Exit und On-Premise-Betrieb
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktLohnt sich ein Cloud Exit finanziell überhaupt?
Welche Workloads sollte man besser in der Cloud lassen?
Was passiert mit den Egress-Kosten beim Rückzug?
Brauche ich im eigenen Rechenzentrum wirklich Kubernetes?
Wie lange dauert eine Rückmigration typischerweise?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Zielarchitektur für deinen Cloud Exit aufbauen
Wenn du die Plattform für den Rückweg selbst betreiben willst, brauchst du Know-how in Virtualisierung, verteiltem Storage und Container-Orchestrierung. Bei cmt findest du dafür passende Kurse, vom Proxmox Grundkurs über den Aufbaukurs zu Cluster, Ceph und High Availability bis zum Kubernetes Grundkurs und der KubeVirt Schulung. Alle Termine laufen wahlweise vor Ort oder Live-Online, und für Inhouse-Schulungen stimmen wir die Themen auf deine geplante Zielarchitektur ab. Melde dich, dann klären wir gemeinsam, welche Reihenfolge für dein Team sinnvoll ist.