Die Monatsrechnung kommt für Cloud-Services zu spät

Cloud-Services wirken im Einkauf oft bequem. Ein Team bucht Rechenleistung, Speicher, Datenbanken oder Analysefunktionen, ohne auf neue Hardware zu warten. Im Servicebetrieb zeigt sich die Kehrseite später auf der Rechnung. Dann ist das Geld bereits verbraucht, die Fachseite fragt nach dem Nutzen und der IT muss erklären, warum ein Service teurer wurde, obwohl kein großes Projekt sichtbar war.

Kurz gesagt FinOps verbindet Finanzsicht, Technik und Betrieb für Cloud-Ausgaben. Es geht nicht nur um Sparen, sondern um die Frage, ob Kosten, Nutzung und geschäftlicher Wert zusammenpassen. Für ITSM ist FinOps deshalb kein reines Controlling-Thema. Es hilft, Cloud-Services so zu führen, dass Service Owner, Produktteams, Einkauf und Betrieb dieselbe Lage sehen.

Die FinOps Foundation beschreibt FinOps als operative Praxis, die Teams dabei unterstützt, den geschäftlichen Wert der Cloud zu maximieren. Dazu gehören Transparenz, gemeinsame Verantwortung und laufende Optimierung. Auch die großen Cloud-Anbieter betonen in ihren Kostenleitfäden, dass Kosten nicht erst nachträglich geprüft werden sollten. AWS ordnet Kostenoptimierung als eigenen Pfeiler im Well-Architected Framework ein. Google Cloud beschreibt Kostenoptimierung ebenfalls als dauerhafte Architektur- und Betriebsaufgabe. Für ITSM-Generalisten ist daran vor allem wichtig: Cloud-Kosten sind ein Service-Signal, kein Buchhaltungsrest.

Warum die Rechnung zu spät kommt

Eine Monatsrechnung zeigt, was passiert ist. Sie sagt aber selten sofort, welcher Service die Kosten ausgelöst hat, ob die Ausgaben fachlich gewollt waren und wer gegensteuern darf. Ein einzelner Datenexport, eine Testumgebung ohne Ablaufdatum, ein zu groß gewählter Datenbanktarif oder ein nicht gelöschter Speicherbereich kann klein beginnen und später spürbar werden. Wenn diese Kosten erst im Finanzbericht auftauchen, fehlen oft die technischen Zusammenhänge.

Im klassischen ITSM wird ein Service über Zweck, Besitzer, Support, Verfügbarkeit, Risiken und Änderungen beschrieben. Genau dort gehört auch die Kostensicht hin. Nicht als komplizierte Finanzrechnung, sondern als verständliche Betriebsinformation: Welche Cloud-Ressourcen gehören zu diesem Service? Welche Nutzung treibt die Kosten? Welche Schwellen gelten als normal? Wer wird informiert, wenn der Trend kippt? Welche Änderung darf ein Team sofort vornehmen, welche braucht Abstimmung?

Der Servicekatalog braucht eine Kostenspur

Der Servicekatalog ist ein guter Ort, um Cloud-Kosten alltagstauglich zu machen. Ein Eintrag muss nicht jede Einzelposition aus der Cloud-Konsole abbilden. Er sollte aber erklären, welche Kostenarten für den Service relevant sind. Bei einem Kundenportal können das zum Beispiel Datenbankkapazität, ausgehender Datenverkehr, Suchdienste und Backup-Aufbewahrung sein. Bei einer Analyseplattform zählen eher Rechenläufe, Speicherklassen und Datenabrufe.

Diese Kostenspur hilft in drei Situationen. Erstens macht sie Gespräche mit der Fachseite konkreter, weil nicht nur eine Gesamtsumme im Raum steht. Zweitens unterstützt sie Changes, weil ein Release auch eine Kostenwirkung haben kann. Drittens hilft sie im Incident- und Problem-Management, wenn ein technischer Fehler plötzlich ungewöhnliche Nutzung erzeugt. Ein Service, der doppelt so viele Jobs startet wie geplant, kann nicht nur langsamer werden, sondern auch teurer.

Service Owner brauchen verständliche Schwellen

Cloud-Kosten werden steuerbar, wenn Service Owner nicht nur rückblickend informiert werden. Sie brauchen einfache Schwellen und klare Ereignisse. Das kann ein Monatsbudget sein, ein Verbrauchstrend, eine auffällige Abweichung zur Vorwoche oder ein neuer Kostentreiber nach einem Release. Wichtig ist, dass diese Schwellen nicht nur im Finanzsystem stehen. Sie müssen in Betriebsroutinen auftauchen, etwa im Service Review, im Change Advisory Board, im Produkt-Backlog oder im regelmäßigen Gespräch zwischen IT und Fachbereich.

Dabei sollte die IT nicht jede Kostensenkung als Erfolg verkaufen. Manchmal kostet ein Service mehr, weil er mehr Wert liefert, mehr Kunden erreicht oder bessere Verfügbarkeit braucht. FinOps bedeutet dann nicht pauschal kürzen, sondern bewusst entscheiden. Ein teurer, aber geschäftskritischer Service braucht andere Regeln als eine vergessene Testumgebung. Genau diese Unterscheidung ist ITSM-Arbeit.

Tags und Besitzer machen die Daten brauchbar

Technisch beginnt vieles mit sauberer Kennzeichnung. Cloud-Ressourcen brauchen Tags oder Labels für Service, Umgebung, Besitzer, Kostenstelle und Kritikalität. Ohne diese Metadaten bleibt die Auswertung ungenau. Dann streiten Teams über Summen, statt über Entscheidungen zu sprechen. Mit brauchbaren Kennzeichnungen lässt sich dagegen erkennen, welche Services Kosten treiben und wo eine Änderung wirklich ansetzen muss.

Tags allein lösen das Problem aber nicht. Sie müssen gepflegt, geprüft und in Prozesse eingebunden werden. Neue Ressourcen sollten ohne Mindestkennzeichnung nicht produktiv gehen. Abweichungen gehören in einen Betriebscheck. Verantwortliche müssen wissen, was passiert, wenn eine Ressource keinem Service zugeordnet ist. Sonst wird aus FinOps nur ein weiteres Dashboard, das zwar bunte Kurven zeigt, aber keine Handlung auslöst.

Was ITSM konkret tun kann

Ein praxistauglicher Einstieg besteht aus wenigen Schritten. Zuerst werden die wichtigsten Cloud-Services identifiziert, nicht alle Ressourcen auf einmal. Danach bekommt jeder Service einen Besitzer, eine grobe Kostenlogik und zwei bis drei verständliche Kennzahlen. Anschließend wird festgelegt, wo diese Zahlen besprochen werden. Service Reviews, Change-Freigaben und Problem-Analysen sind bessere Orte als ein isolierter Monatsbericht.

Zusätzlich sollte jedes Team eine kleine Kostenfrage in seine Änderungen aufnehmen: Verändert dieser Change Verbrauch, Speicher, Datenverkehr oder Laufzeit? Wenn ja, wer prüft den Effekt nach dem Go-live? Diese Frage kostet wenig Zeit, verhindert aber blinde Flecken. Sie bringt FinOps aus der Spezialistenrunde in den normalen Servicealltag.

Fazit

Cloud-Kosten sind kein störender Nachtrag zur Technik. Sie zeigen, wie ein Service wirklich genutzt, betrieben und verantwortet wird. Wer sie erst in der Monatsrechnung sieht, reagiert zu spät. ITSM kann aus Kosten ein frühes Betriebssignal machen, wenn Servicekatalog, Owner, Tags, Schwellen und Reviews zusammenarbeiten. Dann geht es nicht um Sparreflexe, sondern um bessere Entscheidungen für jeden Cloud-Service.

Quellen und Stand Quellenprüfung am 20.06.2026: FinOps Foundation zu FinOps und Fähigkeiten, AWS Well-Architected Cost Optimization, Google Cloud Architecture Framework zu Kostenoptimierung.