Cloud-Repatriation: Workloads zurück ins eigene RZ holen

Den größten Teil der vergangenen fünfzehn Jahre war die Richtung in der IT offensichtlich und einspurig: Alles wandert in die Public Cloud. Verlagern, modernisieren, wiederholen. Daher überrascht es, dass eine erhebliche Zahl von Organisationen Workloads inzwischen in die Gegenrichtung bewegt — zurück von den Hyperscalern in eigene oder für sie betriebene Infrastruktur. Das ist Cloud-Repatriation, und es ist keine Absage an das Cloud-Betriebsmodell. Es ist dessen Reifung.

Repatriation bedeutet selten, die Public Cloud vollständig aufzugeben. Häufiger bedeutet es, Workloads richtig zu platzieren: jene, die echt von Elastizität profitieren, in der Public Cloud zu belassen und jene, die berechenbar, teuer oder sensibel geworden sind, zurückzuholen. Dieser Artikel betrachtet, warum Organisationen repatriieren, wie man den Business Case aufbaut und wie der Umzug ohne jenen Schmerz gelingt, der die Leute überhaupt erst in die Cloud trieb.

Warum das Pendel zurückschwingt

Das ursprüngliche Versprechen der Public Cloud war überzeugend: keine Investitionsausgaben, unbegrenzte Elastizität, nur das bezahlen, was man nutzt. Für unvorhersehbare, stoßweise oder frühe Workloads gilt dieses Versprechen weiterhin. Das Problem ist, dass sehr viele Produktiv-Workloads überhaupt nicht unvorhersehbar sind. Sie laufen rund um die Uhr auf einer stetigen, gut verstandenen Grundlast — und für diese ist das Mietmodell die teuerste Art, Rechenleistung zu beziehen.

Die Erkenntnis kommt meist allmählich und dann plötzlich. Eine Cloud-Rechnung kriecht Jahr für Jahr nach oben, Egress-Gebühren häufen sich, und eines Tages fragt die Finanzabteilung, warum eine stabile, berechenbare Anwendung ein Mehrfaches dessen kostet, was gleichwertige eigene Hardware über ihre Lebensdauer kosten würde. Diese Frage ist der Startschuss für die meisten Repatriation-Projekte.

Die Kostentreiber, die man im Auge behalten sollte

Die Kosten sind der dominierende Antrieb, daher lohnt es sich zu wissen, welche Posten am häufigsten den Ausschlag geben.

Gleichbleibende Rechenlast

Läuft ein Workload mit annähernd konstanter Auslastung, zahlen Sie einen Aufschlag für Elastizität, die Sie nie nutzen. Eigene oder dedizierte Infrastruktur, über drei bis fünf Jahre abgeschrieben, ist für dieses Profil je Recheneinheit häufig deutlich günstiger.

Datenausgang und -transfer

Egress-Gebühren sind der stille Budgetkiller. Datenintensive Anwendungen — Analytik, Medien, Sicherungen, alles, was große Mengen aus dem Anbieter herausbewegt — sammeln Transferkosten, die mit der Rechenrechnung selbst konkurrieren können, und sie wachsen mit dem Erfolg, statt abzuflachen.

Speicher im großen Maßstab

Langlebige, wachsende Datenbestände auf hochwertigen verwalteten Speicher-Tiers werden auf eine Weise teuer, die von Monat zu Monat leicht zu übersehen, über ein Jahr aber deutlich ist. Verteilter Speicher wie Ceph auf eigener Hardware verändert diese Rechnung erheblich.

Jenseits der Kosten: die anderen Treiber

Geld ist die Schlagzeile, aber selten der einzige Grund. Datensouveränität ist zu einem wichtigen Motiv geworden, besonders in Europa: regulierte oder sensible Daten unter heimischer rechtlicher Kontrolle zu halten, frei von extraterritorialem Zugriff, ist unter der DSGVO und Branchenregeln wie DORA und NIS2 zunehmend eine Anforderung der Vorstandsetage.

Auch Leistung und Latenz zählen. Workloads, die nah an On-Premise-Systemen, Fertigungsanlagen oder bestimmten Netzwerken liegen müssen, laufen auf lokaler Infrastruktur oft besser und berechenbarer. Und dann ist da die Kontrolle: Organisationen, die sich an plötzlichen Preisänderungen oder eingestellten Funktionen die Finger verbrannt haben, wollen ihre kritischen Systeme auf einem Fundament, dessen Bedingungen sie selbst bestimmen. Die Broadcom-VMware-Episode hat diesen Instinkt in der ganzen Branche geschärft.

Den Business Case aufbauen

Ein glaubwürdiger Repatriation-Fall ruht auf ehrlichen Gesamtkosten, nicht auf einem Vergleich auf dem Bierdeckel. Erfassen Sie auf beiden Seiten das vollständige Bild.

Auf der Cloud-Seite sammeln Sie ein volles Jahr tatsächlicher Ausgaben — Compute, Speicher, Egress, verwaltete Dienste, Support —, nicht den Listenpreis der Instanzen. Auf der privaten Seite berücksichtigen Sie Hardware über ihre reale Lebensdauer abgeschrieben, Rechenzentrums- oder Colocation-Kosten, Netzwerk, Software und die oft unterschätzten Kosten für Betriebspersonal oder einen Managed-Service-Partner. Der ehrliche Vergleich zeigt meist, dass Repatriation für gleichbleibende Workloads klar gewinnt und für echt elastische verliert — genau deshalb lautet die Antwort Portfolio und nicht ein pauschaler Umzug in die eine oder andere Richtung.

Vergessen Sie weder die Migrationskosten selbst noch den Zeitwert der Einsparungen: Ein Projekt, das sich in zwölf bis achtzehn Monaten amortisiert, ist etwas ganz anderes als eines, das vier Jahre braucht.

Eine Entscheidungs-Checkliste

Bevor Sie sich festlegen, schicken Sie jeden Kandidaten-Workload durch einige Fragen. Ist seine Auslastung stetig und berechenbar oder echt stoßweise? Ist er datenintensiv genug, dass Egress die Rechnung dominiert? Trägt er Souveränitäts- oder Compliance-Sensibilität? Wie eng ist er an anbieterspezifische verwaltete Dienste gekoppelt, die ersetzt werden müssten? Und hat Ihre Organisation die Betriebsfähigkeit, ihn nach der Rückholung gut zu betreiben, oder kann sie sie beschaffen? Workloads, die mit stetig, datenintensiv, sensibel, lose gekoppelt und ja antworten, sind erstklassige Repatriation-Kandidaten. Jene, die das Gegenteil antworten, sollten wohl bleiben.

Wie man ohne Schmerz repatriiert

Die Angst, die Organisationen vom Repatriieren abhält, ist die Erinnerung daran, wie hart die ursprüngliche Migration war. Der Schlüssel ist, Repatriation als diszipliniertes Programm zu behandeln statt als heldenhaftes Wochenende.

Beginnen Sie damit, Abhängigkeiten gründlich zu kartieren — die versteckten, die verwaltete Datenbank, auf die sich drei andere Dienste still verlassen, sind es, die Projekte entgleisen lassen. Wählen Sie einen unkritischen Workload zum ersten Umzug und beweisen Sie das Muster von Anfang bis Ende. Zielen Sie wo immer möglich auf ein offenes, standardbasiertes Ziel, damit Sie nicht einfach einen Lock-in gegen den nächsten tauschen: Eine Private Cloud auf Basis von OpenStack, KVM und Ceph gibt Ihnen cloud-artige APIs und Self-Service ohne proprietäre Verstrickung. Stellen Sie anbieterspezifische Dienste auf offene Entsprechungen um — verwaltetes Postgres wird zu Postgres, das Sie betreiben, proprietäre Queues werden zu Standard-Queues — und validieren Sie Leistung und Sicherungen, bevor Sie die Produktion umschalten. Dann ziehen Sie in Wellen um und lernen unterwegs.

Die Rolle einer verwalteten Private Cloud

Der größte Einwand gegen Repatriation ist betrieblich: Wer betreibt die Infrastruktur, sobald sie nach Hause kommt? Nicht jede Organisation will ein Plattform-Engineering-Team neu aufbauen, um eine Private Cloud zu betreiben, und dieses Zögern ist verständlich. Hier verändert eine verwaltete souveräne Plattform die Rechnung.

clouditiv existiert genau für dieses Szenario. Wir liefern eine souveräne, OpenStack-basierte Private Cloud als verwaltete Plattform — OpenStack 2025.2 auf Ubuntu 24.04 LTS, mit KVM, Ceph-Speicher und OVN-Netzwerk, eine vollständige Private Cloud automatisch in unter einer Stunde provisioniert, mit einem SLA von 99,9 % Verfügbarkeit betrieben und Daten, die in Deutschland bleiben. Die starke Nachfrage rund um die VMware-zu-OpenStack-Migration nach dem Broadcom-Lizenzbeben überlappt stark mit Repatriation: In beiden Fällen wollen Organisationen berechenbare Kosten, echte Kontrolle und ein Ziel, in das sie nicht eingesperrt sind. Die Rückholung auf eine verwaltete Private Cloud lässt Sie die Wirtschaftlichkeit und die Souveränität zurückgewinnen, ohne die volle Betriebslast selbst zu schultern.

Repatriation als Portfoliomanagement

Am nützlichsten denkt man über Repatriation nicht als Umkehr der Cloud-Strategie nach, sondern als deren nächste Stufe. Die frühen Jahre drehten sich darum, alles rasch in die Cloud zu bringen; die reife Phase dreht sich darum, jeden Workload dorthin zu stellen, wo er wirklich hingehört. Elastische und experimentelle Workloads gedeihen auf Hyperscalern. Stetige, datenintensive und souveränitätssensible gehören zunehmend auf private Infrastruktur, die Sie kontrollieren. Mit einer klaren TCO-Analyse und einem disziplinierten Migrationsplan ist Repatriation kein Rückzug — sie ist schlicht gutes Portfoliomanagement, und für eine wachsende Zahl europäischer Organisationen ist sie der Schritt, der die Cloud-Rechnung und die Daten endlich wieder unter Kontrolle bringt.