FinOps ist kein Tool-Problem
Einer der hartnäckigsten Mythen rund um Cloud-Kosten lautet, FinOps sei im Kern eine Tool-Frage. Ist es nicht. Fast immer laufen ausufernde Kosten auf denselben Grund hinaus, weil niemand vorher festgelegt hat, wie viel ein Produkt kosten darf. Deshalb löst kein Werkzeug das Problem für sich, sondern erst eine klare Erwartung und eine gemeinsame Datenbasis, an der Kosten, Betrieb und Organisation zusammenlaufen.
Der Mythos vom richtigen Tool
Wenn Cloud-Kosten aus dem Ruder laufen, ist der erste Reflex fast immer die Suche nach dem passenden Werkzeug, das die Sache endlich in den Griff bekommt. Wir könnten dir an dieser Stelle einen Namen nennen und diese Erwartung damit scheinbar bestätigen, aber ehrlich gesagt würden wir dir keinen Gefallen damit tun.
Denn ein Tool sagt dir, was du ausgibst, aber nicht, ob es das wert ist. Diese zweite Frage ist die eigentlich wichtige, und sie lässt sich nicht kaufen, sondern nur beantworten.
Die eigentlich erste Frage
Bevor es um Optimierung geht, steht eine Entscheidung an, die erstaunlich oft nie bewusst getroffen wird: Wie viel darf und soll ein Produkt eigentlich kosten? Stell dir vor, jemand würde eine Fabrik bauen, ohne vorher über Stückkosten und Margen gesprochen zu haben, was in der physischen Welt undenkbar wäre. Beim Betrieb eines Produkts in der Cloud passiert genau das ständig, weil Ressourcen die Illusion erzeugen, beliebig skalierbar zu sein, und weil jede Skalierung sofort und unmittelbar auf der Rechnung landet, ohne dass jemand sie vorher eingeplant hat.
Wer diese Frage stellt, dreht die Perspektive um. Es geht nicht mehr darum, eine zu hohe Rechnung nachträglich zu drücken, sondern darum, vorab bewusst zu entscheiden, wo investiert wird, weil es dem Produkt nützt, und wo nicht. Aus einer Kostenrechnung, die man erduldet, wird eine Investitionsentscheidung, die man steuert. Genau das meint Kontrolle: nicht am wenigsten ausgeben, sondern wissen, wofür man ausgibt und was es bringt.
Von der Rechnung zur Einheit
Damit diese Frage beantwortbar wird, muss die absolute Rechnung auf eine Einheit bezogen werden, die zum Produkt passt. Eine Cloud-Rechnung von 1.200 US-Dollar im Monat sagt für sich genommen nichts. Erst wenn man sie durch die 800 aktiven Nutzer teilt, die das Produkt in diesem Monat wirklich verwendet haben, entsteht mit rund 1,50 US-Dollar pro aktivem Nutzer eine Zahl, mit der sich arbeiten lässt. Liegt der Preis bei 15 US-Dollar im Monat, macht die Infrastruktur also etwa zehn Prozent aus, und die eigentliche Frage lautet nicht mehr „Ist 1.200 viel?", sondern „Bleibt dieser Anteil stabil, wenn wir wachsen?".
Welche Einheit die richtige ist, hängt vom Produkt ab. Bei einem Mehrmandanten-Produkt lohnt oft der Blick auf die Kosten pro Mandant, der ja mehrere Nutzer bündelt, weil ein einzelner großer Mandant die Struktur ganz anders belastet als viele kleine. Bei anderen Produkten ist eine Betrachtung pro Vorgang denkbar, was allerdings schnell abstrakt wird und selten der beste Startpunkt ist. Das ausgereifte Ziel dahinter ist eine echte Unit-Economics-Betrachtung, wie sie die FinOps Foundation beschreibt, bei der Kosten, Nutzung und Erlös pro Einheit zusammengeführt werden. Das ist die Richtung, aber ehrlicherweise nicht der erste Schritt.
Der ehrliche erste Schritt
Bevor man Kosten sauber auf Einheiten umlegen kann, steht eine unspektakulärere Arbeit an, die in der Praxis fast immer übersprungen wird. Zuerst muss man wissen, welche Verträge überhaupt existieren, denn neben der großen Cloud-Rechnung verstecken sich oft weitere laufende Posten bei anderen Anbietern, die nie jemand gebündelt betrachtet hat. Dann muss man verstehen, welche Systeme über diese Verträge tatsächlich bezahlt werden, weil ein Vertragsname selten verrät, welcher Dienst dahinter für welches Produkt läuft.
Genauso wichtig ist die Frage, wer für jeden dieser Posten verantwortlich ist, weil eine Kostenposition ohne verantwortliche Person nie bewusst gesteuert wird, sondern einfach weiterläuft. Und schließlich lässt sich für jeden Posten fragen, was er dem Gesamtsystem eigentlich beiträgt, ob er also ein Produkt trägt, das Wachstum ermöglicht oder ein Risiko absichert, oder ob er nur historisch da ist. Erst wenn diese vier Dinge geklärt sind, wird aus einer Rechnung eine Landkarte, auf der sich Einheiten und Investitionsentscheidungen überhaupt verorten lassen.
Wo Tools helfen und wo nicht
Damit kein falscher Eindruck entsteht: Für Standard-Probleme sind Standard-Tools oft genau richtig. Wer eine wiederkehrende Frage hat, für die es ein etabliertes Werkzeug gibt, sollte es nutzen, statt das Rad neu zu erfinden. Ein Tool misst allerdings immer nur das, was du ihm vorgibst, und die Festlegung, dass es auf die Kosten pro aktivem Nutzer ankommt, nimmt dir keines ab. Diese Festlegung ist die eigentliche Arbeit, und ein Werkzeug wird erst danach nützlich.
Das eigentlich Spannende an der aktuellen technischen Welt liegt aber woanders. Sobald die Kostendaten in einer sauberen, standardisierten Basis liegen, lassen sie sich mit einem Sprachmodell verbinden und dadurch explorieren, statt sie nur in vorgefertigten Dashboards zu betrachten. Man stellt eine Frage, sieht die Antwort, und die nächste Frage ergibt sich aus dieser Antwort, ohne dass jemand vorher eine passende Kachel angelegt haben muss. Genau darin steckt heute ein großes Potenzial, weil die Daten so beweglich werden, wie das Denken über sie ohnehin ist.
Der erste konkrete Schritt
Diese Datenbasis anzulegen ist kleiner, als die meisten erwarten. AWS, GCP, Azure und OCI unterstützen mittlerweile alle das FOCUS-Format, einen einheitlichen Standard für Abrechnungsdaten über alle Anbieter hinweg. Ihn zu aktivieren kostet kaum Aufwand und schafft sofort eine saubere, standardisierte Grundlage, auf der jede weitere Auswertung aufsetzt. Für ein Unternehmen mit einem eigenen Produkt in der Cloud ist das der niedrigschwelligste erste Schritt zu echter Kontrolle über die eigenen Zahlen.
Was aus dieser Grundlage entsteht, wenn man sie über eine lokale DuckDB per MCP mit einem Sprachmodell verbindet und in natürlicher Sprache befragt, beschreiben wir ausführlich im Artikel Mit den eigenen Zahlen reden. Hier genügt der Gedanke, dass die Basis der Anfang ist, nicht das Ziel.
Wo die Wirkung entsteht
Der eigentliche Wert entsteht nicht durch die Daten selbst, sondern in dem Moment, in dem aus Daten Informationen werden, die einen Unterschied machen. Erst dann lässt sich die Investitionsfrage für jedes Produkt beantworten, und erst dann wird aus einem Bauchgefühl eine Entscheidung, die man begründen und über die Zeit überprüfen kann. In unserer Praxis zeigt sich dabei immer wieder, dass diese Sicht auf die Kosten selten allein steht, sondern eng mit Security, Betrieb und Organisation verwoben ist, weil dieselbe Datenbasis und dieselbe Reife am Ende alle diese Themen tragen.
Der beste nächste Schritt ist deshalb kein Kauf, sondern ein Gespräch: im eigenen Unternehmen die Frage stellen, wie viel jedes Produkt kosten darf, und parallel den FOCUS-Export aktivieren, um überhaupt eine Grundlage zu haben. Wenn du dabei jemanden an der Seite haben willst, der knietief im Thema steckt, ordnen wir das gerne gemeinsam mit dir ein.
Häufige Fragen
Ist FinOps nicht einfach die Wahl des richtigen Tools?
Für Standard-Probleme sind Standard-Tools oft genau richtig. Aber ein Tool zeigt nur, was du ausgibst, nicht, ob es das wert ist. Diese Frage hängt an einer bewussten Entscheidung, wie viel ein Produkt kosten darf, und an einer sauberen Datenbasis, die sich heute mit einem Sprachmodell explorieren lässt, statt nur in Dashboards zu enden.
Was ist der erste konkrete Schritt?
Die eigene Datenbasis anlegen: in AWS einen Data Export im FOCUS-1.2-Format aktivieren, als Parquet nach S3, mit täglicher Granularität. Das kostet kaum Aufwand und schafft eine saubere, standardisierte Grundlage, auf der jede weitere Auswertung aufsetzt.
Geht es bei FinOps ums Sparen?
Nicht in erster Linie. Es geht darum, bewusst zu investieren und Kontrolle zu bekommen, also zu wissen, wofür man ausgibt und was es dem Produkt bringt, statt eine zu hohe Rechnung nachträglich zu drücken.
Auf welche Einheit soll ich die Kosten beziehen?
Für die meisten Produkte sind die Kosten pro aktivem Nutzer ein guter, greifbarer Start. Bei Mehrmandanten-Produkten lohnt zusätzlich der Blick pro Mandant. Eine vollständige Unit-Economics-Betrachtung ist das Ziel, aber nicht der erste Schritt.
Was ist der ehrliche erste Schritt vor allen Zahlen?
Zu wissen, welche Verträge überhaupt existieren, welche Systeme darüber bezahlt werden, wer dafür verantwortlich ist und was jeder Posten dem Gesamtsystem beiträgt. Erst diese Landkarte macht Einheiten und Investitionsentscheidungen verortbar.
Ist das FOCUS-Format an AWS gebunden?
Nein. AWS, GCP, Azure und OCI unterstützen FOCUS inzwischen alle. Der Standard ist gerade deshalb nützlich, weil er Abrechnungsdaten über die Anbieter hinweg vereinheitlicht.
Ähnliche Themen
KPIs richtig machen
Einen KPI setzt man nicht auf, weil man etwas messen kann, sondern weil man Sichtbarkeit für etwas Bestimmtes braucht: für eine Zahl, die sich verbessern soll, oder als Wächter, der warnt, wenn eine Änderung anderswo etwas Gutes verschlechtert. Alles andere ist eine Vanity Metric. Aus diesem Zweck folgt die Form, ein Korridor mit Ziel-, Risiko- und Chancenschwelle statt einer nackten Zahl, und für den Betrieb eines Produkts genügen drei davon: Allokation, Forecast-Genauigkeit und Effizienz.
Weiterlesen →Was AWS Support wirklich kostet
Support-Kosten sind bei AWS keine feste Gebühr, sondern ein Prozentsatz des Verbrauchs, der still mitwächst, sobald die Rechnung wächst. Mit dem Umbau der Support-Pläne Ende 2025 hat sich diese Rechnung verschoben, weil Business Support+ den alten Business Support ablöst und das Enterprise-Minimum von 15.000 auf 5.000 US-Dollar fällt. Das macht die Frage, welcher Plan zu welcher Konten-Struktur passt, neu interessant, und mit dem Rechner im Artikel lässt sie sich für die eigenen Zahlen durchspielen.
Weiterlesen →