Cloud: Kosten über Compute, Storage und Datenpipelines steuern
13. Oktober 2026
Bei 64 Prozent der Unternehmen in Deutschland sind die Betriebskosten für Cloud-Lösungen im vergangenen Jahr gestiegen, bei 19 Prozent stark. Für 2026 rechnen 14 Prozent mit stark und 40 Prozent mit leicht steigenden Ausgaben, wie der Bitkom Cloud Report 2026 zeigt. Gleichzeitig verfolgen 67 Prozent der Unternehmen mit der Cloud das Ziel der Kostenreduzierung.
In verteilten Architekturen entstehen Kosten an vielen Stellen gleichzeitig: in Compute-Instanzen mit ungenutzter Kapazität, in Speicher ohne Löschfristen und in Datenpipelines, die bei jedem Lauf mehr Daten bewegen als nötig. Cloud FinOps bündelt diese Kostentreiber in einem Steuerungsmodell, das Engineering, Finanzen und Fachbereiche gemeinsam verantworten.
Was Cloud-Kostenkontrolle umfasst
Cloud-Kostenkontrolle verbindet Finanzsteuerung mit dem Betrieb variabler Cloud-Ressourcen. Klassisches IT-Kostenmanagement plant Budgets im Jahresrhythmus und ordnet Kosten festen Kostenstellen zu. In der Cloud entstehen Kosten laufend, ausgelöst durch Deployments, Skalierungsregeln und Datenvolumen. Die Kostenverantwortung liegt deshalb dort, wo Ressourcen entstehen: in den Teams, die Infrastruktur bereitstellen und Anwendungen betreiben.
Die Steuerung folgt einem wiederkehrenden Zyklus aus drei Schritten. Im ersten Schritt entsteht Transparenz darüber, welche Kosten welchem Team, Produkt oder Kunden zuzuordnen sind. Im zweiten werden Ressourcen angepasst und Abrechnungsmodelle gewählt. Im dritten werden die Ergebnisse als Regeln, Budgets und Automatisierungen im Betrieb verankert. Dashboards und Kostenmanagement-Tools decken vor allem den ersten Schritt ab. Die Wirkung auf die Rechnung entsteht in den beiden folgenden.
Compute: Kapazität am tatsächlichen Bedarf ausrichten
Compute-Kosten folgen drei Entscheidungen: Instanzgröße, Laufzeit und Abrechnungsmodell. Rightsizing vergleicht die tatsächliche Auslastung über mehrere Wochen mit der bereitgestellten Kapazität und passt Instanzen schrittweise an. Entwicklungs- und Testumgebungen lassen sich außerhalb der Arbeitszeiten automatisch herunterfahren. Für die Grundlast senken Reservierungen oder Savings Plans die Stückkosten, für unterbrechbare Batch-Jobs eignen sich Spot-Instanzen.
Der Trade-off liegt in der Bindung. Reservierungen gelten über feste Laufzeiten und binden an einen Anbieter, eine Region oder eine Instanzfamilie. Wer Workloads später verlagern oder in eine souveräne Umgebung überführen will, richtet Laufzeit und Umfang der Verpflichtungen an der eigenen Plattformstrategie aus.
In Kubernetes-Umgebungen bestimmen Requests und Limits, wie dicht Pods auf Nodes verteilt werden. Zu großzügige Requests reservieren Kapazität, die bezahlt und nicht genutzt wird. Autoscaler auf Pod- und Cluster-Ebene passen die Kapazität an die Last an. Eine Kostenzuordnung pro Namespace macht sichtbar, welches Team welche Ressourcen beansprucht.
Storage: Daten nach Zugriff und Lebenszyklus ablegen
Speicherkosten wachsen mit jeder Datei, die niemand löscht: Snapshots, Logs, verwaiste Volumes und Backups ohne Ablaufdatum. Ein zentraler Hebel ist die Zuordnung von Daten zu Speicherklassen nach Zugriffshäufigkeit. Häufig genutzte Daten liegen in schnellen Klassen, selten genutzte Daten wandern über Lifecycle Policies automatisch in günstigere Klassen oder ins Archiv. Löschfristen leiten sich aus gesetzlichen und internen Aufbewahrungsvorgaben ab.
Archivklassen sind günstig in der Ablage und teurer sowie langsamer beim Abruf. Datenabflüsse aus der Cloud, sogenannte Egress-Kosten, fallen bei Migrationen und Anbieterwechseln an. Hier überschneiden sich Kosten- und Souveränitätsfragen: 59 Prozent der Unternehmen nennen Lock-In-Effekte wie schwierige Datenexporte als größtes Hindernis für einen Anbieterwechsel. Exportpfade und Datenformate gehören deshalb in die Storage-Architektur, bevor große Datenmengen entstehen.
Datenpipelines: Kosten pro Lauf sichtbar machen
Datenpipelines verursachen Kosten in Compute, Storage und Netzwerk zugleich. In Kostenberichten pro Ressource lassen sie sich deshalb schwer zuordnen. Aussagekräftiger ist eine Kennzahl pro Pipeline-Lauf oder pro Datenprodukt.
Inkrementelle Verarbeitung lädt nur geänderte Datensätze und ersetzt vollständige Neuladungen. Partitionierung und spaltenorientierte Formate wie Parquet reduzieren die gescannte Datenmenge, was bei abfragebasierten Abrechnungsmodellen direkt auf die Kosten wirkt. Zwischenergebnisse erhalten ein Ablaufdatum, Zeitpläne richten sich nach dem tatsächlichen Bedarf der Abnehmer. Data Contracts legen fest, welche Daten in welcher Frequenz und Qualität geliefert werden, und begrenzen so unnötige Verarbeitung.
KI-Workloads erhöhen den Druck auf diese Pipelines. 42 Prozent der Unternehmen nutzen heute KI-Dienste aus der Cloud, in fünf Jahren wollen es 69 Prozent sein. Training, Feature-Berechnung und Inferenz greifen auf dieselben Datenflüsse zu und erhöhen deren Volumen, wenn sie ohne gemeinsame Planung betrieben werden.
Betriebsmodelle für Cloud-Kostenkontrolle im Vergleich
Wie die Kostenkontrolle organisatorisch verankert wird, hängt von Größe, Cloud-Reife und vorhandenen Kompetenzen ab. Drei Modelle lassen sich unterscheiden.
| Kriterium | Zentrales Team | Föderiertes Modell | Managed FinOps |
| Verantwortung | Ein Team steuert die Kosten für alle Bereiche | Zentrale Standards, Umsetzung in den Produktteams | Externer Partner übernimmt Analyse und Optimierung |
| Stärke | Einheitliche Regeln, schnelle Transparenz | Kostenverantwortung nah an der Technik | Sofort verfügbare Expertise und Tooling |
| Grenze | Abstand zu den Teams, die Kosten verursachen | Höherer Abstimmungsaufwand | Internes Wissen wächst langsamer |
| Voraussetzungen | Budget für ein dediziertes Team | Tagging-Standards, geschulte Teams | Klare Schnittstellen, Zugriffsrechte, Reporting |
| Souveränität | Kosten- und Nutzungsdaten bleiben intern | Daten bleiben intern, Zugriffe sind verteilt | Datenzugriff, Standort und Rechtsraum des Partners regeln |
| Geeignet für | Einstieg, wenige Cloud-Plattformen | Mehrere Produktteams, Multi-Cloud | Begrenzte interne Kapazitäten, schneller Start |
Die Modelle lassen sich kombinieren. Ein zentrales Team legt Standards fest, ein Partner liefert Analysen und Automatisierung, die Produktteams tragen die Kostenverantwortung für ihre Workloads. 38 Prozent der Unternehmen setzen auf Multi-Cloud. In solchen Umgebungen braucht FinOps einheitliche Kostendaten über alle Anbieter hinweg.
Cloud-Kosten reduzieren: drei Prinzipien
01 Kosten zuordnen, bevor optimiert wird.
Verbindliche Tags für Team, Produkt, Umgebung und Kostenstelle sind die Basis jeder Auswertung. Showback macht Kosten für Teams sichtbar, Chargeback verrechnet sie intern. Der Weg führt in der Regel zuerst über Showback, weil Teams lernen müssen, ihre Kosten zu lesen.
02 Kosten pro Leistungseinheit messen.
Gesamtkosten steigen, wenn ein Geschäft wächst. Aussagekräftiger sind Kosten pro Transaktion, pro Kunde oder pro Pipeline-Lauf. Sinkende Stückkosten bei steigenden Gesamtkosten zeigen eine effiziente Skalierung.
03 Regeln automatisieren.
Budgets mit Schwellenwerten, Policies as Code für zulässige Instanztypen, automatische Abschaltzeiten und Lifecycle Policies wirken ohne manuelles Eingreifen. Cloud Automation verankert Kostenregeln direkt in Infrastructure-as-Code-Vorlagen und Deployment-Pipelines.
Kostensteuerung als Teil der Plattformarchitektur
Cloud FinOps entfaltet seine Wirkung, wenn Kostensteuerung in Architektur, Betrieb und Datenplattformen verankert ist. Ausgangspunkt ist Kostentransparenz über Compute, Storage und Datenpipelines hinweg. Darauf bauen Tagging-Standards, Kennzahlen pro Leistungseinheit und automatisierte Regeln auf, die in bestehende Plattformen und Deployment-Prozesse integriert werden. Welches Betriebsmodell passt, hängt von Cloud-Reife, Teamstruktur und Souveränitätsanforderungen ab. Weitere Hebel der Cloud-Kostenoptimierung setzen auf diesen Grundlagen auf.
