7 Min. Lesezeit – Stand April 2026

Cloud Repatriation klingt 2026 wie ein Rückwärtsgang, ist aber nur die Rechnung, die nach drei Jahren Hyperscaler-Betrieb fällig wird. Die Frage ist nicht „zurück aus der Cloud“, sondern: ab welchem Workload-Profil wird Co-Location plus Kubernetes rechnerisch attraktiver als AWS oder Azure. Wer das Modell nicht durchrechnet, spart entweder Geld in einer teuren Cloud oder verbrennt es in einem schlecht dimensionierten Rack.

VerwandtKI-Inference-Kosten 2026: FinOps für GPU-Workloads  /  Platform Engineering 2026: Internal Developer Platforms

Die Diskussion läuft seit 37signals 2023 öffentlich vorgerechnet hat, dass sie mit eigenen Servern siebenstellig sparen. Danach kamen viele Meinungsstücke, wenige Zahlen. Was im Enterprise-Kontext fehlt, ist ein ehrliches TCO-Gerüst: nicht für den Laptop-Backend-Service, sondern für Workloads mit echter Lastkurve, Compliance-Anforderungen und Betriebsverantwortung.

Dieser Artikel liefert das Gerüst. Keine Ideologie, keine Hyperscaler-Schelte. Nur die Stellschrauben, die den Unterschied machen. Plus eine Rechnung, die man auf einem A4-Blatt nachvollziehen kann.

Wann der Rückweg rechnerisch Sinn ergibt

Die meisten Repatriation-Cases scheitern nicht an der Technik, sondern am Profil der eigenen Workloads. Hyperscaler verkaufen Elastizität. Dafür ist ein Aufschlag auf die Baremetal-Kosten fair. Unfair wird es, wenn man die Elastizität nie nutzt. Eine rund um die Uhr laufende Analyse-Pipeline, die jeden Tag ungefähr die gleiche Ressourcenkurve zeigt, ist der Lehrbuchfall für Co-Location. Ein Webshop mit Black-Friday-Peak eher nicht.

Der zweite Faktor, den viele ignorieren, ist Egress. Bei AWS kosten Datenausgänge ab dem ersten Terabyte ernsthaft Geld. Bei Azure sieht es ähnlich aus. Workloads, die große Datenmengen rauspusten – Video-Transcoding, Backup-Ziele, ML-Training mit externem Dataset – tragen ihren Hyperscaler-Aufenthalt zu einem nicht kleinen Teil über Traffic, nicht über Compute.

Als Faustregel für den ersten Filter: Wenn die durchschnittliche CPU-Auslastung eurer Instanzen im Monatsschnitt über 60 Prozent liegt und der Egress-Anteil an der Cloud-Rechnung zweistellig prozentual beiträgt, lohnt sich das Rechenmodell. Liegt ihr darunter, bleibt beim Hyperscaler und macht FinOps. Das ist billiger als ein Migrationsprojekt.

Quelle: TCO-Modellrechnung cloudmagazin, Annahmen im folgenden Abschnitt

Das Rechenmodell, das auf eine Serviette passt

Um nicht im Vagen zu bleiben: Nehmen wir einen realistischen Workload. Hundert Compute-Knoten, Äquivalent zu grob AWS m7i.4xlarge (16 vCPU, 64 GB RAM). In der Cloud on-demand rund 0,80 Euro pro Stunde je Instanz, mit 1-Jahres-Reserved-Instances etwa 0,48 Euro. Storage und Netzwerk lassen wir bewusst separat, weil sie vom Workload abhängen.

Auf der Cloud-Seite landet man bei Reserved Instances bei circa 420.000 Euro pro Jahr Compute-Only, on-demand bei rund 700.000 Euro. Egress-Kosten bei typischen ein bis zwei Terabyte Outbound pro Tag kommen mit grob 60.000 bis 120.000 Euro dazu. Realistische Jahresrechnung für den Workload allein: eine halbe bis knapp eine Million Euro.

Auf der Co-Location-Seite sieht die Rechnung anders aus. Zwei Racks in einem DACH-Rechenzentrum mit Power und Kühlung, Gegenwert etwa 48.000 bis 72.000 Euro pro Jahr. Hardware-Abschreibung für einhundert Dell- oder Supermicro-Knoten über fünf Jahre bei rund 10.000 bis 14.000 Euro Listenpreis pro Knoten, also 200.000 bis 280.000 Euro pro Jahr. Netzwerk-Uplink mit 10 Gbit redundant: 20.000 bis 35.000 Euro. Zwei dedizierte SRE mit Betriebsverantwortung für Kubernetes und Hardware: vollkostenbetrachtet rund 220.000 Euro. Puffer für Spare Parts, Remote Hands, Provider-Wechsel: 40.000 Euro.

Summe: zwischen 528.000 und 647.000 Euro pro Jahr. Gegen die Cloud-Rechnung von 480.000 bis knapp einer Million ist das kein Silver Bullet, sondern ein Korridor, in dem die Entscheidung anhand von Lastprofil und Egress fällt. Spannend wird es nicht bei hundert Knoten, sondern bei 300 oder 500, wo die Hardware-Kosten degressiv wirken, Personal und Racks aber nicht linear mitwachsen.

Was Kubernetes im Co-Lo wirklich verändert

2019 war Repatriation operativ kein Spaß. Bare-metal-Server mit Ansible und handgepflegten LB-Configs sind eine Zeitreise, die keiner machen will. 2026 sieht die Sache anders aus. Kubernetes auf eigener Hardware ist kein exotisches Setup mehr, sondern eine Plattform-Default-Option: Cluster-API für Lifecycle, Rancher oder OpenShift für Betrieb, Flux oder ArgoCD für GitOps, Cilium für Netzwerk sowie Longhorn oder Ceph für Storage.

Was den Unterschied macht, ist die Abstraktion. Entwickler sehen weiter eine Kubernetes-API, egal ob darunter EKS, AKS oder ein Cluster im Frankfurter Co-Lo läuft. Das ist der eigentliche Hebel: Repatriation wird zum Backend-Swap, nicht zum Application-Rewrite.

Kritisch sind drei Stellen, an denen die Abstraktion leakt. Erstens Storage: Ein EBS-Volume verhält sich anders als ein Longhorn- oder Ceph-RBD-Volume, gerade unter Latenz-Druck. Zweitens Networking: AWS Load Balancer Controller und Cilium-LB auf MetalLB-Basis liefern ähnliche Funktionen, aber die Failover-Zeiten und die Konfigurationslogik sind eigen. Drittens Identity: IRSA-artige Federation auf eigener Hardware ist machbar, braucht aber SPIRE oder eine vergleichbare Workload-Identity-Schicht, die operativ gepflegt werden will.

Wer diese drei Themen nicht vor dem Go-Live gelöst hat, wird sie danach im produktiven Incident-Betrieb lösen müssen. Das ist der teurere Weg. Gleichzeitig ist die Community 2026 weit genug, dass Runbooks, Helm-Charts und Referenzarchitekturen für genau diese Stellen offen verfügbar sind. SUSE, Red Hat und SUSE-Kunden-Communities liefern hier Vorlagen, die man nicht mehr bei Null aufbauen muss.

Das ändert den Charakter des Projekts. Repatriation 2019 war ein Neubau auf der grünen Wiese. Repatriation 2026 ist ein strukturierter Swap mit guter Tool-Chain, solider Doku und einer Community, die die meisten Fallstricke schon durchgespielt hat.

So sieht ein realistischer Migrationspfad aus

1. Workload-Inventur mit ehrlichen Zahlen. CPU-Auslastung p95 über 90 Tage, Speicherbedarf, Netzwerk-Egress, Abhängigkeiten zu Managed Services wie RDS oder Cosmos DB. Kandidaten sind stabile, State-arme Services mit hoher Grundlast.
2. Landing Zone im Co-Lo aufbauen, bevor ein einziger Workload umzieht. Zwei Racks, Kubernetes via Cluster-API, Identity-Anbindung an den bestehenden IdP, Logs und Metrics an denselben Stack wie Cloud-Seite. Ziel: operativ austauschbar.
3. Pilot-Workload umziehen, der wehtut, wenn er fällt. Keine internen Tools als erstes. Wenn Betrieb und Deploy-Pipeline den produktiven Druck nicht halten, ist die Architektur nicht fertig.
4. Datenbanken zuletzt – und nur mit klarem Plan. Managed Postgres oder Cosmos DB sind oft der Hebel, der in der Cloud bleibt. Eigener Postgres-Cluster ist machbar, verlangt aber reale DBA-Zeit und saubere Backup-Strategie.
5. Exit-Kriterien vor Start definieren. Ab welchem Incident, welcher MTTR-Verschlechterung oder welchem Budget-Drift wird der Rückzug zum Rückweg. Das auf Papier, nicht im Kopf.

Die ehrlichen Trade-offs

Jede Architektur hat Kosten, die erst im Betrieb sichtbar werden. Bei Co-Location sind das nicht die offensichtlichen Hardware-Posten, sondern die weichen Faktoren. Hier der Vergleich ohne Beschönigung:

Wer diese Liste liest und das Gefühl hat, die rechte Spalte wiegt schwerer: vermutlich richtig eingeschätzt. Co-Location gewinnt nicht gegen Hyperscaler, weil die Cloud teuer ist. Sie gewinnt, wenn Workload-Profil, Kostenstruktur und Team-Setup zusammenpassen.

Wo die Hybrid-Linie 2026 realistisch liegt

Die meisten Projekte, die ich in den letzten zwölf Monaten näher gesehen habe, landen nicht bei „alles raus“. Sie landen bei einer Hybrid-Architektur, in der 60 bis 80 Prozent der Compute-Last im Co-Lo liegt. Die Cloud bleibt dann für drei Dinge: Managed Databases, die man operativ nicht stemmen will, Peak-Kapazität über Kubernetes-Cluster-Federation sowie Edge- oder Global-Services, für die ein Co-Lo-Standort nicht reicht.

Der Rückweg ist kein Ausstieg aus der Cloud. Er ist die Entscheidung, welche 60 bis 80 Prozent der eigenen Compute-Last sich nicht mehr elastisch verhalten – und deshalb auch nicht elastisch bezahlt werden sollten.

Diese Linie ist kein Kompromiss, sondern die ehrliche Antwort auf eine Rechnung, die nur ein Teil der Workloads besteht. Wer das akzeptiert, hat den halben Weg schon hinter sich. Wer „alles oder nichts“ fordert, landet wieder im Ideologie-Graben, den die Debatte seit 2023 zu oft hatte.

Was die Zielarchitektur zusätzlich interessant macht: Sie entkoppelt Einkauf und Betrieb. Hardware-Abschreibung läuft über fünf Jahre, Colo-Verträge über 24 bis 36 Monate. Cloud-Verträge lassen sich im Zweifel in Wochen drehen. Diese Mischung aus CAPEX und OPEX ist für CFOs lesbarer als eine Cloud-Rechnung, die jeden Monat anders aussieht. Wer mit seinem Finance-Team einmal eine sauber gebaute Hybrid-Kalkulation durchgeht, merkt: der vermeintlich altmodische Hardware-Invest ist das planbarste Stück der gesamten Infrastruktur-Roadmap.

Der Preis dafür ist Disziplin im Capacity-Planning. Wer im Co-Lo 30 Prozent Headroom dauerhaft freihält, verliert einen Teil des Kostenvorteils. Wer zu knapp dimensioniert, bestellt in sechs Monaten nach und verliert Zeit. Die besten Teams, die ich gesehen habe, arbeiten mit rollierenden 12-Monats-Forecasts und einer Cloud-Burst-Option für genau die Peaks, die sie nicht sicher prognostizieren können.

Fazit

Cloud Repatriation 2026 ist kein Rückzug, sondern Reifeprozess. Die Technik ist bereit. Kubernetes im eigenen Rack ist kein Forschungsprojekt mehr. Die Entscheidung bleibt trotzdem kaufmännisch: durchschnittliche Auslastung, Egress-Anteil, Team-Kapazität. Wer diese drei Zahlen nicht kennt, sollte vom Repatriation-Gedanken erst einmal Abstand nehmen und FinOps nachholen. Wer sie kennt und der Korridor stimmt, bekommt am Ende ein Setup, das planbar läuft – und einen CFO, der nicht mehr jeden Monat zuckt, wenn die Cloud-Rechnung reinkommt.

Häufige Fragen

Ab welcher Cloud-Rechnung lohnt sich Repatriation überhaupt anzuschauen?

Unterhalb von grob 300.000 Euro Cloud-Kosten pro Jahr frisst der organisatorische Aufwand die Ersparnis. Ab etwa einer halben Million Euro beginnt das Rechenmodell interessant zu werden, vorausgesetzt das Lastprofil passt. Darunter ist FinOps fast immer der bessere Hebel.

Brauche ich zwingend zwei Co-Lo-Standorte für Redundanz?

Für produktive Workloads mit SLA-Zusagen: ja, zwei Standorte oder ein Cloud-Failover-Pfad. Ein einzelnes Rechenzentrum ist Single Point of Failure. Die meisten Hybrid-Setups lösen das, indem sie die Cloud als DR-Ziel behalten, nicht als Primärbetrieb.

Was kostet ein Kubernetes-Cluster im Co-Lo im Jahr realistisch im Betrieb?

Ohne Hardware, nur Betrieb: zwei bis drei SRE-Vollzeitstellen für einen Cluster mit 100 bis 200 Knoten, plus Lizenzen für Observability-Stack und gegebenenfalls Rancher oder OpenShift. Realistisch sind 300.000 bis 450.000 Euro jährlich. Wer denkt, eine halbe Stelle reicht, unterschätzt Incident-Betrieb und Lifecycle.

Gehen Managed Services wie RDS oder Cosmos DB mit?

Nein, nicht ohne weiteres. Selbst betreibbare Äquivalente existieren (CloudNativePG, CrunchyData, YugabyteDB), erfordern aber DBA-Zeit und saubere Backup-Prozesse. In vielen Hybrid-Setups bleiben die Datenbanken deshalb bewusst in der Cloud, auch wenn der Compute-Teil umzieht.

Wie lange dauert eine realistische Teil-Repatriation?

Von der Entscheidung bis zum Abschluss des ersten Workload-Umzugs: sechs bis neun Monate. Die Landing-Zone-Phase allein, also Co-Lo, Kubernetes, Identity, Observability, braucht drei bis vier Monate. Wer in drei Monaten durch sein will, hat entweder schon alles parat oder setzt das Projekt in den Sand.

Was ist der häufigste Fehler in Repatriation-Projekten?

Die Hardware-Investition wird sauber gerechnet, die Personalkosten werden schöngerechnet. Zwei SRE werden zu 1,5 SRE, der dann auch noch woanders mithilft. Acht Monate später ist das Team überlastet. Die Betriebsqualität sinkt unter das Niveau, das man vorher in der Cloud hatte. Das ist der Klassiker, vor dem man sich schützen muss.

Quelle Titelbild: Pexels / Brett Sayles (px:5480781)