FinOps für Cloud Services: Transparenz als erster Schritt

FinOps verspricht, den Cloud-Mehrwert zu steigern – Kosten-Nutzen-Transparenz ist Grundlage und Voraussetzung dafür.

(Teil 2)

Cloud Financial Management

© Andranik Hakobyan, gettyimages via Canva

Der erste Teil dieses Beitrags erklärt, warum sich FinOps als bewährte Methode für das Kostenmanagement von Cloud Services anbietet, wo herkömmliche Ansätze teilweise versagen.
Ohne Transparenz und Verständnis ist keine Steuerung möglich, so ist es auch bei Cloud-Kosten. Dementsprechend ist "informieren" die erste Phase des FinOps Lifecycle. Nur wenn ein gemeinsames Verständnis für das Thema Kosten vorhanden ist, kann eine Optimierung greifen.

Aber ist die Auslagerung in die Cloud nicht per se schon eine Kostenoptimierung? Nicht unbedingt – denn die Kosten für Cloud Services sind zu einem gewaltigen Faktor geworden. Die Analysten von Gartner erwarten für 2025 weltweite Ausgaben von 917 Milliarden US-Dollar – also mehr als das Bruttoinlandsprodukt der Niederlande. Die Optimierung dieses Kostenblocks hat also großes Potenzial.
Hinzu kommt, dass in sehr vielen Cloud-Projekten das ursprüngliche Ziel Nummer eins – niedrigere Kosten – nicht erreicht wird. Gleichwohl werden die vermeidbaren Cloud-Kosten auf über 30 % geschätzt. Die Potenziale bleiben anscheinend zumindest teilweise ungenutzt.

Einfache Services, komplexe Kostenstrukturen

Im Vergleich zu internen IT-Services versprechen Cloud Services sehr einfache Kostenstrukturen. Die Grundformel lautet:

Spend=Usage*Rat
Ausgaben=Nutzung*Gebühr

Es gibt keine Mindestabnahmemengen, keine Mengenbänder, keine sinkenden Einzelpreise mit steigenden Mengen und so weiter. Ein sehr übersichtliches Preismodell. Leider nur auf den ersten Blick. Denn die Nutzungsmerkmale, die die Cloud als Bereitstellungsmerkmal so attraktiv machen, sorgen auf Kostenseite für erhebliche Komplexität:

On Demand Self-Service: Jeder im Unternehmen kann Cloud-Leistungen bestellen, egal ob von IT- oder Fachbereich. Zentraler Vorteil: schnelle Bereitstellung für jedermann ohne lange Vorlaufzeiten. Das Risiko - im Worst Case: Wildwuchs und Chaos, im Idealfall. Es sind Strukturen und Prozesse, Landingpage etc. (also eine Governance und Rahmenbedingungen) dafür aufzusetzen.

Broad Network Access: Zugriff über das Internet ohne separat anzumietende und zu steuernde Netzwerkanbindungen – eine attraktive Vereinfachung der Infrastruktur. Das Problem dabei: Wenn das ganze Rechenzentrum in die Cloud wandert, weiß niemand, wie viel Netzwerk-Traffic von welcher Applikation anfallen wird. Natürlich aber lässt sich der Cloud-Dienstleister seine Netzwerk-Leistungen vergüten, und nicht vorhergesehener Traffic führt zu ungeplanten Kosten, deren Zuordnung oft nicht möglich ist. Dadurch entstehen Gemeinkosten, die auf interne Nutzer verteilt werden müssen.

Rapid Elasticity: schnelle Reduktion oder Erweiterung der Nutzung. Diese Flexibilität ist neu und in den meisten Unternehmen noch nicht verankert. Entsprechend wenig Erfahrungswerte zu den Auswirkungen sind vorhanden. Also müssen erst Nutzungsdaten ausgewertet werden, um die Kosten nachhaltig einschätzen zu können.

Neben diesen inhärenten Cloud-Merkmalen gibt es weitere Kostenfaktoren, die gern übersehen werden. So erfolgt die Abrechnung wie erwähnt üblicherweise nach Nutzung, also Nutzungseinheit * Preis. Die Messgröße für die Nutzung (also die Nutzungseinheit) kann aber je Cloud Service unterschiedlich sein. Es gibt eine Vielzahl verschiedener Zählmetriken. Da sich ein Business-Service (Leistung für den Endkunden) oft aus mehreren Cloud Services zusammensetzt, gibt es für die aggregierten Kosten immer auch Kostentreiber – also die Nutzung, die den größten Kostenanteil beisteuert.

Wer trägt die Gemeinkosten der Cloud?

Anders als durch manche Cloud-Anbieter suggeriert, ist es also keineswegs trivial zu erkennen, welche Kosten tatsächlich entstehen.

Grundsätzlich gilt das Prinzip "pay as you go". Bezahlt wird nur, was auch genutzt wird. Sinkt die Nutzung, sinken auch die Kosten und umgekehrt. Preisstaffeln wie bei manchen Managed Services gibt es nicht. Das bedeutet aber auch: Wenn zum Monatsende die Nutzung aufgrund des Monatsabschlusses steigt, oder wenn im Vorweihnachtsgeschäft die Zugriffe im Online-Shop hochgehen, steigen auch die Kosten.

Die allgemeinen Cloud-Kosten entstehen, damit andere Produkte/Kostenstellen die Cloud überhaupt nutzen können. Es können Basis-Services sein, die bei der Betrachtung von einzelnen Use Cases gerne vergessen werden, aber Voraussetzung sind oder durch die Nutzung anderer Leistungen entstehen. Ein typischer Fall sind Kosten für die Netzwerk-Infrastruktur.

Wo entstehen welche Kosten?

Auch bei Cloud-Kosten gibt es unterschiedliche Sichtweisen/Betrachtungsweisen auf Kosten.

  • Die von einem Projekt oder von einer Kostenstelle direkt verursachten Kosten. Sie können 1 zu 1 zugeordnet werden.
  • Plattform-Kosten: Cloud-Kosten, die von einem Teil der Cloud-Nutzer (also mehreren Kostenstellen bzw. Projekten, die Cloud Services gemeinsam nutzen) verursacht werden. Hier spricht man von einer 1-zu-n-Beziehung.
  • Allgemeine Kosten wie Netzwerk oder Security. Die allgemeinen Kosten werden von mehreren Kostenstellen verursacht. (1-zu-n-Beziehung)
  • Weitere Kostenelemente wie Reservierungen, Rabatte, Gutschriften oder kostenfreie Nutzungen. Sie können 1 zu 1 oder 1 zu n zugeordnet sein.


Darüber hinaus sind Bezieher und Verursacher der Kosten nicht immer deckungsgleich. So kommt es vor, dass beispielsweise eine IT-Einheit einen Cloud Service bezieht und für eine Fachabteilung veredelt. Der eigentliche Verursacher der Kosten ist dann die Business-Einheit, nicht die IT.

Tagging schafft Transparenz

Klar ist also, dass eine Auswertung der Kosten keine simple Angelegenheit ist, sondern mindestens die oben genannten Perspektiven berücksichtigen muss. Dazu stehen Unternehmen verschiedene Optionen zur Verfügung:

  • "Klassisch" per Export nach Excel. Das kann bei einem kleinen Cloud-Projekt noch machbar sein, ist aber bei größeren Vorhaben nicht mehr praktikabel und wirtschaftlich. Unter anderem müssen dazu unterschiedliche Formate der Dienstleister zusammengeführt werden, der manuelle Aufwand ist erheblich und steigt mit wachsender Cloud-Nutzung.
  • In den Cloud-Portalen der Dienstleister. Das ist sinnvoll, wenn alle Services bei einem Dienstleister laufen – was aber selten der Fall ist. Beim (häufigeren) Szenario "Multi-Cloud" ist eine Auswertung nicht mehr gesamthaft in einem Portal möglich.
  • In einem FinOps-Tool vom Drittmarkt oder einer Eigenentwicklung.


Die Cloud-Strukturen und Reportings sind bei den Cloud-Anbietern unterschiedlich. Bei der Aufbereitung und Herstellung der Transparenz müssen die Daten richtig interpretiert werden.

Die Herausforderung ist eine einheitliche Nomenklatur in der Benennung der Cloud-Komponenten. Unterschiede hierbei sind "tödlich", da eine gesamthafte Betrachtung nicht mehr möglich ist. Vor allem untergraben sie die automatisierte maschinelle Auswertung: MS oder Microsoft, Netzwerk oder Network, 001 oder 1, Deutschland oder DE oder Germany, "-" oder "_" – solche Unschärfen machen Auswertungen schwierig oder sogar wertlos.

Eine bewährte Methode im Rahmen von FinOps ist daher das Tagging. Damit gemeint ist eine Charakterisierung und Verschlagwortung der Cloud-Nutzung. Ein Datensatz im Kostenreport der Cloud Provider muss alle Informationen in Form standardisierter Tags enthalten, um das Verrechnungskonzept und die Kostenzuordnung vollständig zu bedienen und die anschließenden Tools zu befähigen, die Kosten vollautomatisiert zu allokieren und zu verrechnen.

Hierbei ist zu beachten, dass das Tagging auf unterschiedlichen Ebenen der Cloud-Nutzung erfolgen muss – auf Projekt-/Subscription-Ebene genauso wie auf der Ressourcen-Ebene. Das ist wichtig, weil nicht jede einzelne Nutzung tagbar ist – einen automatisiert startenden Container kann man nicht manuell taggen.

FinOps sieht also eine genaue Analyse der Kostenstrukturen plus ein durchgängiges, lückenloses Tagging vor. Das Ergebnis ist maximale Transparenz als Voraussetzung für eine wirksame Kostensteuerung. Möglich werden dadurch:

  • Zuordnung der Kosten zum Verursacher mit dem Ziel des Showback (Kosten den Verursachern transparent aufzeigen) oder Chargeback (Kosten verursachergerecht verrechnen)
  • Verrechnung der allgemeinen Cloud-Kosten nach individuellen Verrechnungsschlüssel
  • Erkennen von Trendentwicklungen, Ausreißern nach oben oder unten; Auswirkungen von besonderen Events (Weihnachten, Monats-/Quartals-/Jahresabschluss, Ferien/Urlaubszeiten)
  • Bessere Kostenprognosen für Budgetierung und Controlling
  • Ansätze für zukünftige Vertragsgestaltung und Optimierung der Nutzung und der Gebühr

Interdisziplinäre Zusammenarbeit statt Silos

Kostenverständnis ist aber nicht per Dekret zu erreichen und nicht von einer dezidierten Stelle aus herzustellen. Um ein gemeinsames Verständnis der Kosten zu schaffen und Sensibilisierung für die Kosten/Kostentreiber zu ermöglichen, müssen IT, Fachabteilung/Business und Finance/Controlling direkt zusammenarbeiten. Jede Rolle hat eine individuelle Sicht auf die Kosten; Auswertungen müssen alle Anforderungen erfüllen. Ist das nicht gegeben, schwindet die Akzeptanz schnell.

Transparenz und Verständnis ist das Fundament und die Voraussetzung für die nächsten Phasen im FinOps-Prozess: Optimierung und Umsetzung. Denn ohne einen Überblick und Wissen kann keine zielgerichtete und sinnvolle Anpassung erfolgen. Alles andere ist Lotterie.

Artikel empfehlen