Cloud-Repatriation: Was bei der Rückverlagerung wirklich hängen bleibt

Acht von zehn Unternehmen wollen mindestens eine Workload aus der Cloud zurückholen. Wer das als großes Cloud-Aus liest, sitzt einer statistischen Illusion auf – denn zurück kommt, was sich rechnet. Architekten und IT-Leiter müssen jetzt sortieren, welcher Workload-Typ wirklich profitiert und welcher genau dort bleibt, wo er ist.

Das Wichtigste in Kürze

• Selektiv, nicht flächendeckend: IDC-Zahlen schwanken zwischen 71 und 86 Prozent je Definition. Repatriation ist eine punktuelle Entscheidung, kein strategischer Wendekreis.
• Drei Treiber, nicht einer: Konstante GPU-Inferenzlast, Compliance-Druck und Data Gravity bestimmen, was zurückkommt. Wer alle drei in einen Topf wirft, verliert Trennschärfe.
• Lohnt sich: Auslastungsstetige KI-Inferenz, regulatorisch kritische Datenbanken, datenintensive Pipelines. Lohnt sich nicht: schwankende Web-Frontends, kleine Services ohne Regulatorik.
• Versteckte Kosten: Observability, Licensing-Verriegelungen durch Managed Services und die Skill-Lücke zwischen Cloud-native und On-Prem-OPS bleiben bei der Rechnung oft außen vor.

Verwandt:FinOps: 30 Prozent Cloud-Kosten realistisch senken  /  AWS und Azure unter EU-Aufsicht: Der Lock-in wackelt

Warum 86 Prozent nicht das bedeuten, was sie klingen

Die Headlines sind eindeutig: 86 Prozent der CIOs planen, Workloads aus der Public Cloud zurückzuholen. Das klingt nach Exodus. Wer die Studien genau liest, merkt schnell, dass diese Zahl eine Spanne ist, kein harter Fakt. Je nachdem, was als „Repatriation“ zählt – komplette Workload-Rückverlagerung, punktuelle Anpassung oder nur hybride Neuausrichtung – schwankt der Wert zwischen 71 und 86 Prozent.

Ein Artikel des EVM-Schwestermagazins Digital Chiefs nennt die Headlines deshalb eine statistische Illusion. Die Kernaussage: Statt einer flächendeckenden Bewegung zurück zur eigenen Hardware geht es um eine selektive Entscheidung für einzelne Workload-Typen. Die meisten Firmen bleiben hybrid – sie verlagern gezielt, was sich im eigenen Rechenzentrum günstiger oder sicherer betreiben lässt. Behalten in der Cloud bleibt, was dort besser aufgehoben ist.

Für Architekten und IT-Leiter im Mittelstand lautet die Frage also: Welche Workload wohin? Und dafür braucht es eine Trennung nach Treibern statt nach Stimmung.

Drei Treiber sauber trennen – und wo jeder greift

Die Debatte um Repatriation vermengt oft drei völlig unterschiedliche Motive. Wer sie gedanklich nicht auseinanderhält, trifft Fehlentscheidungen für die eigene Infrastruktur.

Erster Treiber: GPU- und AI-Inferenz. Die FinOps Foundation beziffert den Anteil der KI-Cloud-Ausgaben, der auf die Inferenz- und nicht auf die Trainingsphase entfällt, auf 80 bis 90 Prozent. Im laufenden Betrieb liegt die GPU-Auslastung laut denselben Erhebungen oft nur bei 15 bis 30 Prozent. Wer 24/7 inferiert, zahlt Cloud-Premium für ungenutzte Kapazität. Hier wird das eigene GPU-Cluster wirtschaftlich interessant.

Zweiter Treiber: Compliance und Data Sovereignty. 64 Prozent der Cloud-Nutzer fühlen sich laut Bitkom Cloud Report durch die Politik der US-Regierung zu einem Strategiewechsel gezwungen, 85 Prozent halten Deutschland für zu US-abhängig. Gartner prägt dafür den Begriff Geopatriation – die Verlagerung in souveräne oder lokale Umgebungen. Der Treiber ist politisch-regulatorisch, nicht rein wirtschaftlich.

Dritter Treiber: Data Gravity und Latenz. Wenn riesige Datenmengen eine physikalische Anziehungskraft entwickeln, wird Cloud-Egress teurer als der Betrieb am Datenstandort. Pipelines, die Terabytes bewegen, kehren dorthin zurück, wo die Daten liegen.

Welche Workload-Typen sich lohnen – und welche nicht

Nach diesen drei Treibern lässt sich eine klare Matrix aufstellen. Die Faustregel: Was konstant läuft, regulatorisch kritisch ist oder datenintensiv pendelt, ist ein Kandidat für die Rückkehr. Was schwankt, klein und regulierungsfrei bleibt, bleibt besser in der Cloud.

Lohnt sich in der Regel: Konstant laufende KI-Inferenz (GPU-Auslastung im eigenen Rack ab etwa 60 Prozent wirtschaftlich relevanter Dauerlast), Compliance-kritische Datenbanken mit DACH-Verarbeitungsanforderungen und datenintensive Pipeline-Schritte, bei denen Cloud-Egress die On-Prem-Betriebskosten übersteigt.

Lohnt sich nicht: Schwankende Web-Frontends, bei denen der Skalierungsvorteil der Cloud erhalten bleibt. Kleine Services ohne Regulatorik, bei denen die Migrationskosten die Laufzeitersparnis auffressen. Stark Cloud-native Dienste, die an proprietäre Managed Services wie AWS Lambda oder Kinesis gekoppelt sind – hier frisst das Re-Engineering die vermeintliche Ersparnis.

Was bei der Rückverlagerung technisch hängen bleibt

Die Entscheidung ist nur die halbe Miete. Was Architekten unterschätzen, sind die technischen Kosten, die im Business Case oft fehlen.

Cloud-native Services wie Lambda, Kinesis oder BigQuery sind Architektur-Entscheidungen, keine austauschbaren Produkte. Wer sie zurückholt, muss sie mit Open-Source-Äquivalenten wie OpenWhisk, Kafka oder Trino nachbauen. Das kostet Engineering-Zeit. Das neue System ist selten 1:1 funktionsgleich. Licensing-Verriegelungen durch Managed Services sind der häufigste Grund, warum Rechnungen zurückschnappen, sobald die erste Euphorie verflogen ist.

Hinzu kommen Observability, Netzwerk- und Storage-Latenz sowie die Skill-Lücke zwischen Cloud-native- und On-Prem-OPS. Ein Team, das drei Jahre lang Infrastructure-as-Code in der Cloud betrieben hat, muss Terraform-Module nicht zwingend auf Bare Metal übersetzen können. Das ist kein Argument gegen Repatriation – aber ein Posten, der in der Wirtschaftlichkeitsrechnung auftauchen muss.

Wie Architekten jetzt entscheiden – ohne Modereflex

Der saubere Entscheidungsrahmen läuft über drei Fragen pro Workload: Wie konstant ist die Last? Wie stark ist der Datenbezug lokal? Wie hoch ist der Compliance-Druck? Wer alle drei mit „hoch“ beantwortet, hat einen Repatriations-Kandidaten. Bei zwei „nein“ bleibt die Cloud die richtige Antwort.

Das Rechenbeispiel: Eine GPU-reserved-Instanz on-prem rechnet sich gegenüber Cloud-On-Demand bei 24/7-Inferenz ab etwa 60 Prozent Auslastung über einen TCO-Horizont von 18 bis 36 Monaten. Darunter bleibt die Cloud elastisch genug, um Lastspitzen ohne Überkapazität abzufangen. Die Entscheidung fällt also mathematisch aus statt ideologisch – und genau das macht sie operationalisierbar.

Wer jetzt eine Workload zurückholt, sollte sie als Pilot betrachten, nicht als Blaupause für alles. Eine erfolgreiche Repatriation einer Inferenz-Pipeline beweist Wirtschaftlichkeit, aber sie überträgt sich nicht automatisch auf das Web-Frontend. Selektiv zu bleiben ist Disziplin, kein Halten aus Unsicherheit.

Häufige Fragen