Der Broadcom Private Cloud Outlook 2025 — eine Umfrage des Anbieters, der VMware verkauft, also mit entsprechender Vorsicht zu lesen — ergab, dass 69 % der Organisationen Cloud Repatriation prüfen und 53 % Private Cloud für neue Workloads bevorzugen. Die Gründe variieren — ausufernde Kosten, regulatorischer Druck, Datenresidenz für KI, planbare Performance —, die architektonische Arbeit ist aber dieselbe: die richtigen Workloads für den Umzug bestimmen, den Umzug durchführen, ohne die Anwendung zu zerbrechen, und am Ende eine Plattform haben, die Sie tatsächlich betreiben können.
Ænix übernimmt das technische Projekt, das „wir müssen AWS / Azure / GCP verlassen“ von einer Aussage im Vorstand in einen funktionierenden Plan verwandelt — mit priorisierten Workloads, modellierten Kosten und einer Zielarchitektur, die die Public Cloud nicht auf die falsche Weise nachbaut.
Passt zu der Ænix-Plattform, die zum Ziel passt: Private Cloud Platform, wenn Sie die Kapazität für Ihre eigenen Geschäftsbereiche betreiben, Public Cloud Platform, wenn Sie sie weiterverkaufen, AI Platform, wenn die zurückgeholten Workloads GPU-gebunden sind. Kostenloses Cloud-Repatriation-TCO-Worksheet →. CTOs, die die Entscheidung abwägen: siehe den CTO-Leitfaden.
Für wen sich Repatriation wirklich eignet
Repatriation ist nicht für jeden. Die Teams, die am meisten davon profitieren, haben ein gemeinsames Profil:
- Hohe Public-Cloud-Rechnungen — jährliche Ausgaben im siebenstelligen Bereich, und die Kurve bis zur nächsten Verlängerung steigt steiler als der Umsatz.
- Planbare, dauerhafte Workloads — nicht die elastischen Lastspitzen, für die Hyperscaler gebaut wurden.
- Sensible Daten mit Souveränitätsrisiko — Daten aus Finanzwesen, Gesundheitswesen, öffentlichem Sektor oder regulierten Branchen, die zunehmend regulatorischen Druck auf sich ziehen.
- KI-/ML-Workloads mit Sorgen um Egress- und Inferenzkosten — Model Serving und Training, bei denen die Hyperscaler-Ökonomie im großen Maßstab nicht mehr aufgeht.
- Eine interne Platform-Engineering-Funktion (bestehend oder im Aufbau) — nach der Repatriation muss jemand die Zielplattform betreiben.
Treffen mindestens drei dieser Punkte zu, verdient Repatriation eine strukturierte Prüfung. Betreibt ein kleines IT-Team nur eine Handvoll Services, lautet die Antwort fast immer: „in der Public Cloud bleiben und die Ausgaben optimieren“.
Vier Gründe, warum Teams 2026 Workloads zurückholen
1. Planbare Kosten für dauerhafte Workloads Die Hyperscaler-Ökonomie belohnt Elastizität. Für Workloads, die rund um die Uhr bei planbarer Auslastung laufen, sind die Stückkosten On-Premises oder in der Private Cloud oft deutlich besser — sobald Egress, ungenutzte Ressourcen und untergenutzte Commitments ehrlich eingerechnet werden. Wie viel besser, hängt von Ihren Workloads ab; der TCO-Rechner hilft beim Durchrechnen.
2. Regulatorischer Druck und Souveränität DORA (in Kraft seit Januar 2025), NIS2, DSGVO, branchenspezifische Regeln zur Datenresidenz und Souveränitätsvorgaben in der öffentlichen Beschaffung mehrerer Länder zwingen kritische Workloads zunehmend in eine Umgebung, die die Organisation selbst kontrolliert.
3. KI und Analytik auf sensiblen Daten GenAI-, Inferenz- und Analytik-Workloads auf regulierten Datenklassen stehen an zwei Fronten unter Druck: Die Datenverarbeitungsbedingungen der Modellanbieter sind nicht akzeptabel, und die Egress-Kosten der Inferenz machen die Hyperscaler-Ökonomie im großen Maßstab untragbar.
4. Betriebliche und architektonische Kontrolle Proprietäre Hyperscaler-Services binden die Architektur an die Roadmap eines einzigen Anbieters. Repatriation gibt dem Plattform-Team die Möglichkeit zurück, die zugrunde liegenden Komponenten selbst zu wählen, weiterzuentwickeln und zu prüfen.
Woran die meisten Repatriation-Projekte scheitern
Das TCO-Modell ist Wunschdenken statt ehrlich Hardwarekosten sind leicht zu beziffern. Netzwerk, Rechenzentrum, Storage-Tiering, Observability, Identity, Backup, DR und die laufende Platform-Engineering-Kapazität fehlen meist oder werden unterschätzt. Das Ergebnis: Repatriation wirkt günstiger, als sie ist, und enttäuscht den CFO nach 18 Monaten.
Die Zielarchitektur wird auf später verschoben Workloads landen auf „einem On-Prem-Cluster“, ohne echte Plattform darunter. Das Team baut in schlechterer Form nach, was die Hyperscaler in einem Jahrzehnt entwickelt haben. Self-Service funktioniert nicht mehr, die Geschwindigkeit sinkt, und die Repatriation bekommt die Schuld.
Datengravitation wird als Formalie abgehakt „Die Datenbank ziehen wir zuletzt um“ — ohne echten Plan, wie 50 TB Produktionsdaten über das Netzwerk kommen, wie das Cutover-Fenster aussieht, wie der Rollback funktioniert und wo die Backups während des Umzugs liegen.
Der Ausstieg ist vollständig, wo selektiv richtig wäre Die meisten Repatriationen sind keine Alles-oder-nichts-Entscheidung. Das richtige Ergebnis ist meist ein Teil der Workloads On-Premises (die dauerhaften, regulierten oder teuren), während der Rest in der Public Cloud bleibt (die elastischen, latenzkritischen oder nur beim Hyperscaler verfügbaren). Wer Repatriation als binäre Entscheidung behandelt, zerstört den wirtschaftlichen Business Case.
Diese Fehlermuster hängen nicht von Cloud-Anbieter, Hersteller oder Zielplattform ab — sie entstehen, wenn Repatriation als Tabellenkalkulation statt als Platform-Engineering-Programm betrieben wird.
Wie Ænix hilft
Das Repatriation-Projekt läuft als Teil unseres Platform Readiness Assessment mit dem Arbeitsstrang Kosten und Cloud-Ausgaben als Schwerpunkt. Das 14- oder 28-tägige Projekt liefert:
- Ehrliches TCO-Modell — aktuelle Public-Cloud-Ausgaben (inklusive Egress, untergenutzter Commitments und versteckter Kosten) gegenüber realistischen Zielkosten in Private Cloud oder Hybrid.
- Repatriation-Ranking der Workloads — jeder Workload eingestuft als „jetzt verlagern / später verlagern / in der Cloud bleiben“, sortiert nach ROI und Risiko.
- Zielarchitektur — wie die Plattform aussieht, auf der die Workloads landen: Compute, Storage, Netzwerk, Identity, Observability, DR und die Platform-Engineering-Funktion, die sie betreibt.
- Cutover-Reihenfolge — Repatriation-Wellen, die den Ablauf der Commitments berücksichtigen und Datenbewegungen zwischen den Umgebungen minimieren.
- Umsetzungs-Roadmap für Phase 2 — was eine von Ænix umgesetzte Phase 2 leisten würde, in welcher Reihenfolge und mit welchem Aufwand.
Geliefert von Ænix-Ingenieuren, die Produktionsplattformen für Service-Provider, eine Bank und KI-Betreiber gebaut haben (siehe die Fallstudien). Der Bericht empfiehlt, wofür wir technisch geradestehen können.
Warum gerade Ænix
- Keine Hyperscaler-Bindung. Repatriation-Beratung der Big Four ist von deren Hyperscaler-Partnerschaften geprägt. Unsere Empfehlungen sind kommerziell weder an AWS, Azure, GCP noch an einen anderen Anbieter gebunden — wir sagen „in der Public Cloud bleiben“, wenn das die Antwort ist, und „vollständig On-Premises“, wenn das die Antwort ist.
- Ingenieure statt Berater. Die Ingenieure, die das Repatriation-Projekt durchführen, bauen danach die Produktionsplattformen. Die Aufwandsschätzungen im Bericht sind an Arbeit kalibriert, die wir tatsächlich ausgeliefert haben — nicht an Branchen-Benchmarks.
- Open-Source-Zielplattform. Wir haben Cozystack entwickelt und pflegen es gemeinsam mit Maintainern anderer Unternehmen — eine quelloffene, Kubernetes-native Cloud-Plattform (CNCF-Sandbox-Projekt, CNCF Certified Kubernetes Distribution). Wo Cozystack besser zur Zielarchitektur passt als die Alternative, begründet der Bericht das mit konkret benannten architektonischen Eigenschaften. Wo nicht, sagen wir es.
Wie das Projekt abläuft
Tag 0 ist ein kostenloses 30-minütiges Discovery-Gespräch, in dem der Umfang festgelegt wird. An den Tagen 1–13 (bzw. 1–27) laufen vier parallele Arbeitsstränge mit Schwerpunkt auf Kosten und Cloud-Ausgaben, begleitet von täglichen asynchronen Updates und drei Abstimmungsterminen mit dem Sponsor. An Tag 14 (bzw. 28) folgt ein 60- bis 90-minütiger Executive-Readout zum schriftlichen Bericht — Workload-Ranking, TCO-Modell, Zielarchitektur, Cutover-Reihenfolge und Roadmap für Phase 2. Die vollständige Methodik Tag für Tag: Platform Readiness Assessment.
Unternehmen, die Plattformen mit Ænix betreiben
Hosting-Anbieter, die Ænix Public Cloud Platform in Produktion betreiben
Hosting-Anbieter, die die Ænix Public Cloud Platform produktiv betreiben. Projekte mit Bezug zur Repatriation sind auf der Seite mit den Fallstudien beschrieben, zum Beispiel ein Umzug von Proxmox auf Kubernetes auf Bare Metal und GPU-Inferenz auf eigener Hardware.
Preise und Projektumfang
Das Repatriation-Projekt läuft als Platform Readiness Assessment.
14 Tage (fokussiert auf TCO und Repatriation)
TCO-Modellierung in der Tiefe, Ranking des Workload-Portfolios, Optionen für die Zielarchitektur, Cutover-Reihenfolge für die Workloads mit höchster Priorität. Auf Anfrage
28 Tage (vollständiges Repatriation-Programm)
Zusätzlich Anbieter-Shortlist (Compute / Storage / Netzwerk / Observability), Zuschnitt eines Proof of Concept für 1–2 priorisierte Workloads, Stakeholder-Interviews über mehrere Geschäftsbereiche, vollständige Umsetzungs-Roadmap für Phase 2. Auf Anfrage
Festpreis. Eine Rechnung. Gegenseitige NDA zum Projektstart. Kosten der Umsetzung in Phase 2: Das Assessment-Honorar wird je nach Umfang angerechnet.
Wir nehmen RFI und RFP über die üblichen Beschaffungskanäle an; EU-Verträge laufen über die AENIX s.r.o. (Tschechien).
Beginnen Sie mit einem 30-minütigen Discovery-Gespräch
Wir prüfen die Passung, bestimmen die Workloads, deren Umzug sich lohnt, und benennen die passende Variante — 14 oder 28 Tage.
Oder lesen Sie weiter:
- Leitfaden zur Reverse Cloud Migration — der ausführliche Leitfaden
- Cloud-Kostenoptimierung — der angrenzende FinOps-Auslöser
- Platform Readiness Assessment — die Methodik des Projekts
- Cozystack — die Plattform, die wir typischerweise als Ziel einer Repatriation empfehlen
Ænix hat Cozystack entwickelt — ein CNCF-Sandbox-Projekt, eine CNCF Certified Kubernetes Distribution mit OpenSSF Best Practices — und pflegt es gemeinsam mit Maintainern anderer Unternehmen. Wir führen Repatriation-Projekte und Platform-Engineering-Programme durch.




