Veröffentlicht am
Zuletzt geändert
Die Workload-Landkarte: Cloud pro Anwendung entscheiden
71 Prozent holen Workloads zurück, aber nur 8 bis 9 Prozent alles. Die richtige Cloud-Entscheidung wird pro Anwendung getroffen – mit Blick auf Latenz, Datenklasse, Lastprofil und Regulierung.

Warum die richtige Cloud-Entscheidung nicht auf Unternehmensebene, sondern für jeden Workload einzeln fällt.
Zwei Zahlen aus dem laufenden Jahr stehen scheinbar im Widerspruch. Nach Erhebungen von IDC haben 71 Prozent der Unternehmen bereits Workloads aus der Public Cloud zurückgeholt. Gleichzeitig planen nur 8 bis 9 Prozent eine vollständige Rückverlagerung. Wer die erste Zahl allein liest, sieht eine Massenflucht. Wer beide liest, sieht etwas Nützlicheres: Die Entscheidung fällt nicht auf Unternehmensebene, sondern pro Anwendung.
Die Zahlen widersprechen sich nur scheinbar
Eine Umfrage von Barclays kommt zu dem Ergebnis, dass 86 Prozent der befragten CIOs mindestens Teile ihrer Workloads zurückverlagern wollen. Das Wort „Teile“ trägt die eigentliche Information.
Am deutlichsten zeigt sich das bei KI-Workloads. Dort haben 93 Prozent der Unternehmen bereits zurückverlagert, tun es aktiv oder prüfen es formal. Bei anderen Anwendungsklassen ist die Bewegung deutlich schwächer. Es geht also nicht um Cloud Computing oder kein Cloud Computing, sondern darum, welche Last wo günstiger, schneller oder rechtssicherer läuft.
Dass gerade KI heraussticht, hat einen strukturellen Grund. Training und Inferenz erzeugen über längere Zeiträume eine hohe, gut vorhersehbare Grundlast, und genau dort verliert das nutzungsabhängige Preismodell seinen Vorteil. Eine skalierbare Cloud ist wertvoll, wenn die Last schwankt. Läuft sie durch, wird sie zur teuersten Variante einer planbaren Position. Dazu kommen große Datenmengen, die zwischen Speicher und Rechenleistung mehrfach bewegt werden, und Modelle oder Trainingsdaten, die häufig zu den schützenswertesten Beständen eines Unternehmens gehören.
Das Zielbild der meisten Unternehmen ist entsprechend gemischt: regulatorisch kritische und kostenintensive Workloads auf eigener oder dedizierter Infrastruktur, variable und global verteilte Lasten in der Public Cloud.
Was tatsächlich zurückkommt, und warum
Die Treiber sind erhoben und in dieser Reihenfolge gewichtet: Kosten mit 54 Prozent, Performance mit 31 Prozent, Datensouveränität mit 27 Prozent.
Kosten stehen vorn, und das hat einen nachvollziehbaren Grund. Nach IDC haben 59 Prozent der Organisationen im Jahr 2024 mehr für Cloud ausgegeben als budgetiert. Eine Abweichung dieser Größenordnung löst Prüfaufträge aus, und Prüfaufträge landen bei der Infrastruktur.
Performance an zweiter Stelle verweist auf Latenz und Datenvolumen. Wo ein Steuersignal oder eine Auswertung in Millisekunden gebraucht wird oder wo große Datenmengen mehrfach bewegt werden, verliert die geografische Entfernung ihre Unschuld.
Souveränität an dritter Stelle ist der jüngste der drei Treiber und derjenige, der am seltensten kurzfristig zur Migration führt, aber am häufigsten in Vertragsverhandlungen auftaucht.
Die Rechnung, die meistens fehlt
Hier lohnt ein Gegenpunkt, der in der Repatriation-Debatte häufig fehlt: Die Hardwarekosten steigen 2026 um 15 bis 25 Prozent und damit schneller als die 5 bis 10 Prozent Cloud-Preissteigerung, die die Diskussion überhaupt ausgelöst hat. Wer allein wegen der Cloud-Rechnung zurückbaut, kauft womöglich das teurere Ende.
Belastbar wird die Entscheidung erst mit einer Vollkostenrechnung. Serverpreise sind darin der leichteste Posten. Dazu gehören Personal für Betrieb, Einkauf und Installation, Softwarelizenzen, Fläche und Miete, Strom sowie Notstrom und Klimatisierung.
Der letzte Punkt wird regelmäßig unterschätzt. Ein zu einem Fünftel gefüllter Serverraum braucht dieselbe Absicherung wie ein voller: Notstrom, Kühlung und Batterien richten sich nach der Auslegung, nicht nach der Belegung. Wer zurückverlagert, ohne die Fläche auszunutzen, verteilt dieselben Fixkosten auf weniger Last. Genau dort kippt eine Rechnung, die auf dem Papier funktioniert hat.
Auf der anderen Seite steht ein Vorteil, der ebenfalls selten beziffert wird: Vorhersehbarkeit. Eine feste monatliche Position ist für die Planung leichter zu handhaben als eine verbrauchsabhängige, die 59 Prozent der Organisationen über Budget geführt hat. Das ist kein Kostenargument, sondern ein Steuerungsargument, und es gehört getrennt bewertet.
Auf der Cloud-Seite gehört der Ausstieg in die Rechnung. Bislang machten Egress-Gebühren einen Wechsel oft unwirtschaftlich und führten zu einer faktischen Bindung. Das ändert sich zu einem festen Datum. Der EU Data Act schafft die Wechselentgelte schrittweise ab: Bis zum 12. Januar 2027 dürfen Anbieter nur noch die Kosten berechnen, die unmittelbar mit dem Wechsel zusammenhängen, ab diesem Datum gar keine mehr. Die Entgelte für das Herausziehen der Daten zählen ausdrücklich dazu. Unabhängig davon müssen Cloud-Verträge bereits seit September 2025 einen geregelten Wechselprozess vorsehen, mit einer Ankündigungsfrist von höchstens zwei Monaten und einer anschließenden Übergangsphase, die im Regelfall 30 Kalendertage nicht überschreitet.
Was der Stichtag nicht abschafft, ist die Bindung insgesamt. Standarddienstentgelte, Mindestlaufzeiten und Vertragsstrafen bei vorzeitiger Kündigung bleiben zulässig, ebenso Entgelte für Leistungen oberhalb der gesetzlichen Mindestpflichten, etwa eine Formatkonvertierung oder eine beschleunigte Migration. Auch die Übergangsphase ist keine Garantie: Ist der Wechsel aus technischen Gründen nicht in 30 Tagen zu vollziehen, darf der Anbieter das begründet anzeigen und eine längere Frist ansetzen.
Für laufende Verhandlungen verschiebt sich die Ausgangslage trotzdem, und zwar zugunsten der Kunden. Wer jetzt Verträge über dieses Datum hinaus verlängert, sollte die Wechselklauseln so aufmerksam lesen wie die Preisliste und prüfen, ob der Anbieter den Ausgang technisch offenhält: über offene Schnittstellen, Standardformate und die Frage, ob die Anwendung beim Zielanbieter funktional dasselbe leistet. Ein vertragliches Wechselrecht ohne technische Wechselfähigkeit ist wenig wert.
Vier Workload-Typen und die jeweilige Richtung
Für die Einordnung genügen vier Fragen pro Anwendung: Wie empfindlich ist sie gegenüber Latenz? Welche Datenklasse verarbeitet sie, und welche Anforderungen an die Datensicherheit folgen daraus? Wie schwankt ihre Last? Welche Regulierung greift?
Daraus ergeben sich vier typische Muster:
Stabile Grundlast mit sensiblen Daten. Vorhersehbarer Bedarf, hohe Schutzanforderung. Läuft wirtschaftlich auf dedizierter oder souveräner Infrastruktur, weil der Elastizitätsvorteil der Public Cloud hier nicht zum Tragen kommt.
Stark schwankende Last ohne besondere Schutzanforderung. Kampagnenspitzen, Testumgebungen, saisonale Verarbeitung. Genau der Fall, für den Public Cloud gebaut wurde.
Latenzkritische Verarbeitung am Entstehungsort. Fertigung, Logistik, Echtzeitauswertung. Gehört nah an die Quelle, unabhängig davon, was der Preisvergleich sagt.
Standardsoftware als Dienst. Office, Kollaboration, CRM. Wird bezogen und nicht selbst betrieben. Hier eine eigene Lösung zu bauen, ist in den meisten Fällen die teuerste Variante.
Cloud Services lassen sich mit diesem Raster einzeln bewerten, statt sie als Paket zu betrachten. Cloud-Lösungen unterscheiden sich in ihrer Eignung eben nicht global, sondern je Anwendungsfall. Souveräne Infrastruktur passt sauber in den ersten und dritten Fall und trägt den zweiten mit, wenn die Elastizität ausreicht. Für den vierten Fall ist sie das falsche Werkzeug, und ein Anbieter, der das nicht sagt, hat das Raster nicht verstanden. Yorizon liefert die IaaS-Basis bis zur Hypervisor-Oberkante; alles darüber bauen Partner oder das eigene Team.
Eine einzige Frage macht den Reifegrad sichtbar: Welcher der eigenen Workloads wäre in zwei Monaten woanders lauffähig? Wo die Antwort unklar ist, liegt kein Kostenproblem, sondern ein Abhängigkeitsproblem.
Fazit
Die 71 Prozent zeigen Bewegung, die 8 bis 9 Prozent zeigen ihre Grenze. Zurück kommt, was schlecht platziert war, nicht alles. Wer jede Anwendung einmal nach Latenz, Datenklasse, Lastprofil und Regulierung einordnet und danach mit Vollkosten rechnet, braucht die Grundsatzdebatte nicht mehr zu führen.
Quellen
Verordnungstext zu Art. 29 Data Act
https://data-act-law.eu/article/29/Cloud-Repatriation: Zurück aus der Public Cloud
https://www.digital-chiefs.de/cloud-repatriation-2026-public-cloud-hybrid-cios/Cloud Repatriation für den Mittelstand: wann sie sich rechnet, TCO und Egress
https://www.plextec.de/wissen/cloud-repatriation-mittelstand-2026-tco-egressCloud Repatriation 2026 is a statistical illusion
https://www.digital-chiefs.de/en/cloud-repatriation-2026-statistical-illusion/EU Data Act: Cloud-Portabilität wird Pflicht
https://www.cloudmagazin.com/2026/07/15/eu-data-act-cloud-portabilitaet-wechsel-pflicht-2027/EU Data Act: Cloud-Wechsel ohne Egress-Gebühren ab 2027
https://www.webhostone.de/blog/artikel/eu-data-act-cloud-wechsel-ohne-egress-gebuehren-ab-2027EU Data Act: Switching-Pflichten für Cloud-Portfolios
https://www.digital-chiefs.de/eu-data-act-switching-pflichten-fuer-cloud-portfolios/


