Cloud-Kosten: woher sie kommen und wann ein Exit sich rechnet

Warum die Cloud-Rechnung schneller wächst als die Last

Das Preismodell der Public Cloud ist auf Elastizität ausgelegt: Wer Ressourcen nur stundenweise braucht, zahlt auch nur stundenweise. Der Umkehrschluss stimmt aber nicht. Wer Ressourcen dauerhaft braucht, zahlt dauerhaft den Elastizitätsaufschlag, und genau dort liegt der größte Teil der Unternehmens-Workloads.

Vier Treiber tauchen in fast jeder gewachsenen Cloud-Rechnung auf:

• Datenverkehr. Rechenzeit und Speicher sind kalkulierbar, der Abfluss von Daten ist es nicht. Er wächst mit dem Erfolg der Anwendung, nicht mit der geplanten Kapazität.
• Vorgehaltene Reserve. Instanzen werden nach Lastspitze dimensioniert und laufen rund um die Uhr. Test- und Staging-Umgebungen laufen nachts und am Wochenende mit.
• Nebenposten. Premium-Support-Tiers, Control-Plane-Gebühren verwalteter Dienste, Snapshots, Lastverteiler, Cross-Zonen-Verkehr. Einzeln klein, in Summe ein eigener Kostenblock.
• Rabattmodelle ohne Pflege. Reservierungen und Committed-Use-Verträge geben je nach Anbieter und Laufzeit bis zu 72 bis 75 Prozent Nachlass. Flexera stellte 2026 fest, dass weniger als die Hälfte der Unternehmen je Anbieter überhaupt ein Commitment-Modell nutzt.

Wie schnell das kippt, zeigt sich in der Praxis meist an zwei Posten: Datentransfer und Speicher wachsen mit jedem neuen Dienst, ohne dass jemand die Entscheidung dafür bewusst getroffen hat. Wer die Rechnung nur in Summe liest, bemerkt es erst, wenn sie sich vervielfacht hat.

Die TCO-Rechnung kippt an den Posten, die niemand einträgt

TCO steht für Total Cost of Ownership, also die Gesamtkosten über den gesamten Lebenszyklus statt nur den Rechnungsbetrag des laufenden Monats. Der Begriff wird oft als Argument benutzt und selten als Rechnung geführt. Eine belastbare Aufstellung vergleicht Public Cloud, Private Cloud und eigenes Rechenzentrum über neun Positionen:

1. Rechenzeit
2. Speicher
3. Datenabfluss
4. Personal für Betrieb und Rufbereitschaft
5. Hardware-Abschreibung
6. Strom
7. Colocation- oder Rechenzentrumsmiete
8. Lifecycle-Management der Hardware
9. Control-Plane- und Verwaltungsgebühren

Zwei Positionen entscheiden den Vergleich fast immer. Die erste ist das Personal. Wer eigene Infrastruktur betreibt, braucht echte Rufbereitschaft, und die trägt keine einzelne Person. Rechnungen, die eigene Hardware gegen eine Cloud-Rechnung stellen und die Betriebsmannschaft weglassen, sind unvollständig. Angesichts von 109.000 fehlenden IT-Fachkräften in Deutschland, die der Bitkom 2025 erhoben hat, ist die Frage außerdem nicht nur, was Personal kostet, sondern ob es verfügbar ist.

Die zweite ist der Verwaltungsaufschlag verwalteter Dienste. Ein verwalteter Kubernetes-Dienst kostet unabhängig von der Auslastung rund 0,10 US-Dollar je Stunde und Cluster, also etwa 73 US-Dollar im Monat. Bei einem Cluster ist das eine Fußnote, bei vierzig Clustern eine Position.

Wie groß der Abstand ausfällt, hängt am Profil. Gleichmäßige Grundlast mit viel Speicher und Datentransfer fällt in einer Vergleichsrechnung fast immer zugunsten eigener oder dedizierter Infrastruktur aus; stark schwankende Last mit kurzen Spitzen spricht für die Public Cloud. Belastbar wird die Aussage erst mit den eigenen Zahlen, deshalb steht am Anfang jedes Projekts eine Bestandsaufnahme der tatsächlichen Nutzung.

FinOps heißt: erst zuordnen, dann senken

Der häufigste Fehler beim Sparen ist die Reihenfolge. Es wird an Instanzgrößen geschraubt, bevor überhaupt bekannt ist, welches Team, welches Produkt und welche Umgebung welchen Anteil der Rechnung verursacht. FinOps beschreibt genau diese Disziplin: Cloud-Kosten werden einem Verursacher zugeordnet, sichtbar gemacht und dann gesteuert.

Praktisch besteht das aus drei Schritten. Erstens eine durchgängige Kennzeichnung aller Ressourcen nach Team, Produkt und Umgebung, denn ohne saubere Zuordnung ist jede Maßnahme geraten. Zweitens ein monatliches Kostenmodell, das die Rechnung in Verursacher aufteilt und Abweichungen gegen den Vormonat zeigt. Drittens eine Governance-Regel, die klärt, wer Ressourcen anlegen darf, wer für ihre Kosten geradesteht und wann Ungenutztes automatisch verschwindet.

Der Effekt ist weniger technisch als organisatorisch. Solange die Cloud-Rechnung eine einzige Zahl in der IT-Kostenstelle ist, hat niemand einen Anlass, etwas zu ändern. Sobald sie einem Produkt zugeordnet ist, wird sie Teil der Produktrechnung. Dass hier der größte ungehobene Hebel liegt, zeigt die Flexera-Erhebung 2026: 29 Prozent der Ausgaben für Infrastruktur- und Plattformdienste gelten als verschwendet, 17 Prozent der Unternehmen überschritten ihr Cloud-Budget, und 85 Prozent nennen Kostenmanagement als größte Herausforderung.

Die meisten Hebel wirken, ohne dass eine Maschine umzieht

Ein Anbieterwechsel ist der größte, aber auch der langsamste Hebel. Davor stehen Maßnahmen, die innerhalb weniger Wochen wirken und kein Architekturprojekt auslösen:

• Richtig dimensionieren. Instanzen sind fast immer nach der Lastspitze gewählt und laufen im Alltag bei geringer Auslastung. Messen, dann verkleinern.
• Abschalten, was nicht gebraucht wird. Test- und Entwicklungsumgebungen brauchen selten 24 Stunden am Tag. Ein Zeitplan spart hier ohne Risiko.
• Speicherklassen sortieren. Alte Snapshots, Protokolle und Sicherungen liegen oft auf der teuersten Klasse, obwohl niemand mehr darauf zugreift.
• Datenwege kürzen. Verkehr zwischen Verfügbarkeitszonen und Regionen ist ein eigener Posten. Dienste, die ständig miteinander sprechen, gehören zusammen.
• Rabattmodelle pflegen. Für den Teil der Last, der ohnehin dauerhaft läuft, sind Reservierungen und Commitment-Verträge der direkteste Nachlass. Die Laufzeit sollte kürzer sein als die Halbwertszeit der Architektur.
• Support-Tier prüfen. Premium-Support wird oft einmal aktiviert und nie wieder hinterfragt.

Diese Liste ist bewusst unspektakulär. Sie ist der Grund, warum am Anfang eine Analyse steht und nicht ein Umzug. Erst wenn die Rechnung sauber ist, lässt sich beurteilen, ob der verbleibende Betrag an der Plattform liegt oder am eigenen Umgang mit ihr. Ausführlicher stehen diese Hebel in unseren Artikeln zum Kostenmanagement in der Cloud und zur Kontrolle über die Cloud-Kosten.

Der Exit rechnet sich bei stabiler Grundlast, nicht überall

Nach der Bereinigung bleibt die eigentliche Frage: Liegt dieser Workload am richtigen Ort? Sie wird pro Workload beantwortet und nicht als Grundsatzentscheidung für das ganze Unternehmen. Vier Merkmale sprechen für einen Umzug in eine Private Cloud oder das eigene Rechenzentrum:

• Stabile Grundlast. Die Anwendung läuft rund um die Uhr in ähnlicher Größe. Elastizität wird bezahlt, aber nicht gebraucht.
• Große, bewegte Datenmengen. Der Datenabfluss ist ein spürbarer Teil der Rechnung.
• Lange Lebensdauer. Die Anwendung wird es in fünf Jahren noch geben, eine Investition amortisiert sich also.
• Regulatorische Anforderungen an Standort, Zugriff und Nachweisbarkeit, die ohnehin erfüllt werden müssen.

Dagegen spricht das Gegenbild: stark schwankende oder saisonale Last, kurze Projektlaufzeit, starke Nutzung anbieterspezifischer Dienste ohne Entsprechung außerhalb, oder ein kleines Team ohne Betriebsmannschaft. Wer diese Workloads zurückholt, tauscht ein Kostenproblem gegen ein Betriebsproblem.

Wie groß der Effekt im günstigen Fall ist, zeigt ein Projekt aus unserem eigenen Bestand: Ein Content-Anbieter mit über 50 selbst gebauten Diensten in AWS senkte nach dem Exit die Plattform- und Servicekosten um 75 Prozent bei unveränderter Verfügbarkeit. Das ist der höchste Wert, den wir dokumentiert haben, ein Einzelfall und ausdrücklich kein Richtwert. Die belastbare Aussage ist nicht der Prozentsatz, sondern die Methode: erst rechnen, dann entscheiden.

Egress ist der Preis dafür, dass Daten schwer werden

Egress bezeichnet den Datenabfluss aus der Cloud des Anbieters ins Internet oder zu einem anderen Anbieter. Der Weg hinein ist meist kostenlos, der Weg heraus nicht. Die Listenpreise liegen bei rund 0,09 US-Dollar je Gigabyte bei AWS, rund 0,087 bei Azure und rund 0,12 bei Google Cloud, jeweils für die erste Preisstufe. Bei einigen Terabyte im Monat ist das eine Nebenposition. Bei Petabyte-Beständen entsteht daraus eine fünf- bis sechsstellige Jahressumme, und aus der Summe entsteht ein Effekt, der als Data Gravity beschrieben wird: Je größer der Datenbestand, desto teurer wird jede Bewegung, und desto weniger wahrscheinlich wird der Wechsel.

Regulatorisch hat sich daran etwas geändert. Der EU Data Act ist seit dem 11.01.2024 in Kraft und seit dem 12.09.2025 anwendbar. Er verbietet Gebühren, die allein für den Anbieterwechsel erhoben werden, ab dem 12.01.2027 EU-weit vollständig. AWS, Google und Microsoft haben Wechselgebühren bereits 2024 unter Bedingungen abgeschafft.

Der zweite Teil des Lock-ins ist vertraglich und technisch. BEREC und Beltug fanden in ihrer Erhebung in unter 5 Prozent der Cloud-Verträge brauchbare Exit-Klauseln, und AWS benennt in einem eigenen Whitepaper sechs Dimensionen von Lock-in. Wie tief die Bindung reicht, hängt weniger am Vertrag als an der Architektur: Wer nur virtuelle Maschinen und Objektspeicher nutzt, zieht vergleichsweise leicht um. Wer anbietereigene Datenbanken, Warteschlangen und Funktionsdienste tief eingebaut hat, baut beim Umzug Teile der Anwendung neu. Mehr dazu steht im Pillar zum Lock-in-Effekt.

Ein Ausfall beim Hyperscaler kostet Sie, nicht ihn

Kosten sind nur die eine Hälfte der Rechnung. Die andere ist das Risiko, das mit der Konzentration auf wenige Anbieter entsteht. Drei Vorfälle der letzten Jahre zeigen die Größenordnung: Der Ausfall der AWS-Region US-EAST-1 im Oktober 2025 dauerte rund 15 Stunden und betraf weltweit über 1.000 Dienste. Google Cloud fiel im Juni 2025 über drei Stunden aus. Das fehlerhafte CrowdStrike-Update im Juli 2024 legte rund 8,5 Millionen Windows-Systeme lahm.

Entscheidend ist, was in einem solchen Fall vertraglich passiert. Die Verfügbarkeitszusagen von AWS, Google und Microsoft sind als einzige und ausschließliche Abhilfe formuliert, im Englischen "sole and exclusive remedy". Wer betroffen ist, bekommt eine prozentuale Gutschrift auf künftige Rechnungen. Keine Auszahlung, keine Erstattung des Umsatzausfalls, keine Haftung für Datenverlust oder Reputationsschaden. Wirtschaftlich heißt das: Der Ausfall kostet den Kunden, und er kostet ihn mehr als die Gutschrift wert ist.

Aufsichtsbehörden sehen das inzwischen genauso. Die Bank of England hat AWS, Microsoft, Google Cloud und Oracle am 10.07.2026 als "Critical Third Parties" für den britischen Finanzsektor eingestuft. Für regulierte Unternehmen in der EU stellen NIS2 und DORA ähnliche Fragen nach Ausweichfähigkeit und Wiederanlauf.

Die praktische Konsequenz ist selten "alles raus". Sie ist die Frage, ob es für die Dienste, an denen das Geschäft hängt, einen Wiederanlaufweg gibt, der nicht denselben Anbieter voraussetzt. Genau das ist der Punkt, an dem eine Hybrid- oder Multi-Cloud-Strategie aufhört, ein Schlagwort zu sein, und zu einer Architekturentscheidung mit Preisschild wird.

Cloud Repatriation: was die Zahlen wirklich hergeben

Seit einigen Jahren kursiert die These, die Unternehmen verließen die Public Cloud in großer Zahl. Die Erhebungen dazu widersprechen sich weniger, als es scheint, wenn man liest, was jeweils gezählt wird.

Die Barclays-CIO-Umfrage kommt auf 83 bis 86 Prozent der befragten CIOs, die eine Rückverlagerung planen. Gezählt werden dort Unternehmen, nicht Workloads und nicht Budgets: Ein einziger zurückgeholter Dienst genügt, um in dieser Quote zu landen. Der Branchendienst Channelnomics hält die Zahl deshalb für irreführend. IDC kommt auf 8 bis 9 Prozent der Unternehmen, die eine vollständige Rückverlagerung planen. Gartner nennt Repatriation "die Ausnahme, nicht die Regel" und beobachtet stattdessen Geopatriation, also die Verlagerung in einen bestimmten Rechtsraum statt aus der Cloud heraus. Eine Erhebung von OpenText im Nutanix Enterprise Cloud Index nennt 67 Prozent, die bereits einzelne Workloads zurückgeholt haben, und 87 Prozent, die es für die kommenden 12 bis 24 Monate planen.

Zusammengenommen ergibt das ein klares Bild: Teilweise Rückverlagerung einzelner Workloads ist verbreitet und wächst. Der vollständige Rückzug aus der Public Cloud ist selten und meist auch nicht das Ziel. Gleichzeitig wächst der Public-Cloud-Markt weiter zweistellig. Beides stimmt, weil es unterschiedliche Workloads betrifft.

Für die eigene Entscheidung heißt das: Marktzahlen taugen als Kontext, nicht als Begründung. Die Frage ist nicht, wie viele Unternehmen zurückholen, sondern welche Ihrer eigenen Workloads nach einer ehrlichen Rechnung am falschen Ort liegen.

Von der Vermutung zur Rechnung: ein Assessment vor jeder Migration

Der Weg von "die Rechnung ist zu hoch" zu einer belastbaren Entscheidung besteht aus vier Schritten, und keiner davon ist ein Umzug.

1. Bestand aufnehmen. Welche Workloads laufen, mit welchem Lastprofil, welchem Datenvolumen und welchen Abhängigkeiten von anbietereigenen Diensten. Grundlage sind Messwerte, nicht die Architekturdokumentation.
2. Kosten zuordnen. Die Rechnung wird nach Verursacher aufgeschlüsselt, inklusive der Nebenposten für Datenverkehr, Support und Verwaltung.
3. Szenarien rechnen. Für jeden relevanten Workload werden Public Cloud, Private Cloud und eigenes Rechenzentrum über die neun Kostenpositionen verglichen, mit Personalaufwand und Migrationskosten als eigene Zeilen.
4. Austrittsfähigkeit prüfen. Was kostet der Wechsel technisch und vertraglich: Datenvolumen und Egress, anbieterspezifische Dienste, Restlaufzeiten, Ausstiegsklauseln.

Am Ende steht kein Grundsatzbeschluss, sondern eine Liste: Welcher Workload bleibt, welcher zieht um, welcher wird zuerst nur optimiert, und in welcher Reihenfolge. Genau das ist der Inhalt unseres Cloud-Exit- und TCO-Assessments, das dem Umzug bewusst vorgeschaltet ist. Wie das Assessment abläuft und was danach kommt, steht auf der Lösungsseite Cloud-Migration und Cloud-Exit.

Fällt danach die Entscheidung für eine Migration, läuft sie in fünf Phasen mit einer Go/No-Go-Entscheidung an jedem Übergang: Analyse, Zielbild, Testumgebung, Migration, Betrieb. In den dokumentierten Projekten lagen zwischen erstem Spatenstich und abgeschalteter Altumgebung zwei bis sechs Monate, je nach Landschaft, und der Bestand lief währenddessen weiter.