Glossar
FinOps
Auch: Cloud Financial Operations · Cloud-Kostenmanagement
Die Praxis, Cloud-Kosten als laufende technische Entscheidung zu behandeln statt als monatliche Rechnung, die die Buchhaltung bekommt.
FinOps setzt voraus, dass die Menschen, die Architektur entscheiden, auch sehen was sie kostet. Das klingt banal, ist aber in vielen Organisationen nicht der Fall: Die Rechnung geht an den Einkauf, die Entscheidung fällt im Team, und dazwischen liegt ein Monat. Wer die Wirkung seiner Entscheidung erst nach dem Abschluss sieht, kann sie nicht steuern.
Der Kern sind drei wiederkehrende Schritte: sichtbar machen, wem welche Kosten gehören; die größten Hebel bewerten; und die Wirkung nach der Umsetzung messen. Diese Schleife läuft dauerhaft, nicht als Projekt. Ein einmaliges Aufräumen senkt die Rechnung für ein Quartal, danach wächst sie zurück, weil dieselben Kräfte weiterwirken: jeder neue Service bringt neue Metriken, jede neue Pipeline neue Daten.
Wichtig ist die Unterscheidung zwischen Kostenoptimierung und FinOps. Optimierung ist eine Maßnahme, FinOps ist die Fähigkeit, sie regelmäßig und ohne Sondereinsatz zu treffen. Ein Team mit FinOps-Praxis braucht keine Sparrunde, weil es die Rechnung ohnehin liest.
AWS-Rechnungen explodieren selten, sie sedimentieren. Vier Jahre Wachstum, in denen es immer Wichtigeres gab, ergeben eine Rechnung, bei der jede einzelne Entscheidung zu ihrem Zeitpunkt vertretbar war und die Summe trotzdem nicht mehr zu erklären ist. Das ist die typische Ausgangslage, nicht der Sonderfall.
Die Kennzahl, die zählt, ist nicht die Gesamtsumme, sondern die Kosten pro fachlicher Einheit: pro tausend Requests, pro Kunde, pro Import. Eine steigende Gesamtrechnung bei stärker steigender Nutzung ist Erfolg. Ohne Bezugsgröße lässt sich das nicht unterscheiden, und genau diese Unterscheidung führt Kostendiskussionen aus der Panik in die Steuerung.
Organisatorisch braucht FinOps zwei Dinge, die nichts mit Technik zu tun haben: eine Zahl pro Woche, die im Team sichtbar ist, und die Erlaubnis, dafür Zeit zu verwenden. Ohne das erste sieht niemand die Wirkung, ohne das zweite verliert Kostenarbeit jede Woche gegen Feature-Arbeit.
Woran Sie es erkennen
- Die Cloud-Rechnung geht an den Einkauf, die Architekturentscheidung fällt im Team.
- Niemand kann sagen, welches Team welchen Anteil verursacht.
- Kostenthemen kommen nur auf, wenn die Rechnung einen Schwellwert reißt.
- Es gibt keine Zahl für die Kosten pro Kunde, pro Request oder pro Vorgang.
- Beobachtbarkeit und Analyse tauchen in der Rechnung neben den Datenbanken auf, obwohl sie in keinem Architekturbild als Kostenstelle stehen.
Nicht zu verwechseln mit
- Kostenoptimierung
- Eine einmalige Maßnahme mit Anfang und Ende. FinOps ist die laufende Praxis, die solche Maßnahmen überflüssig macht, weil sie kontinuierlich stattfindet.
- Cost Explorer
- Ein Werkzeug für den Überblick. Es aggregiert nach Service und beantwortet damit die Frage „was ist teuer", nicht „warum". Für die zweite Frage braucht es den Cost and Usage Report.
- Savings Plans
- Ein Preisnachlass gegen Bindung, also der letzte Schritt. Wer sich auf eine unbereinigte Infrastruktur committet, zementiert die Verschwendung für ein bis drei Jahre.
Wann es trägt
- Die monatliche AWS-Rechnung liegt im vierstelligen Bereich oder darüber.
- Mehrere Teams deployen in dieselben Konten.
- Die Rechnung ist in den letzten zwölf Monaten schneller gewachsen als die Nutzung.
- Vor einer Commitment-Entscheidung: erst bereinigen, dann binden.
Wann nicht
- Bei einer Rechnung von wenigen hundert Euro im Monat kostet die Analyse mehr als sie findet.
- Während einer laufenden Migration: die Zielarchitektur steht noch nicht fest, jede Optimierung daran ist verfrüht.
- Als Ersatz für eine Architekturentscheidung. Wenn eine Last grundsätzlich überflüssig ist, hilft kein Rabatt darauf.
Wie man rangeht
- Zuordnung herstellenPflicht-Tags für Team, Umgebung, Anwendung und Kostenstelle, erzwungen über Tag Policies und Prüfungen in der IaC-Pipeline. Ein freiwilliges Tag fehlt nach einem halben Jahr auf einem Drittel der Ressourcen, und dann ist jede Auswertung wertlos.
- Rohdaten verfügbar machenCost and Usage Report mit Ressourcen-IDs nach S3 exportieren und mit Athena abfragbar machen. Eine Stunde Aufwand, danach beantwortet man Kostenfragen mit SQL statt mit Vermutungen.
- Nach Verbrauchsart auswerten, nicht nach Service„CloudWatch: 2.600 Euro" ist keine Information. Erst die Aufschlüsselung nach Verbrauchsart zeigt, ob es Metriken, Logs oder Dashboards sind, und die haben völlig verschiedene Ursachen.
- Reihenfolge einhaltenLöschen und Aufbewahrung, dann Beobachtbarkeit, dann Daten, dann Verkleinern, dann Architektur, und erst ganz am Ende Commitments. Wer mit dem letzten Schritt beginnt, macht alle vorherigen wirtschaftlich sinnlos.
- Wirkung messen, nicht schätzenVerbrauch messen, also Stunden, Gigabyte, gescannte Terabytes und Requests, nicht nur Euro. Credits, Rabatte und Steuern verzerren die Rechnungssumme, der Verbrauch lügt nicht.
- Rückwachsen verhindernBudgets mit Alarmen je Konto, Anomaly Detection, Aufbewahrungsregeln als Pflichtparameter im IaC-Modul und eine Kostenzahl pro Woche im Team-Channel. Ohne diesen Schritt ist die Ersparnis in zwölf Monaten wieder weg.
Häufig gefragt
Wo fängt man mit FinOps an?
Mit der Zuordnung, nicht mit dem Sparen. Solange nicht klar ist, welche Kosten zu welchem Team und welcher Anwendung gehören, bleibt jede Maßnahme eine Chefsache. Ist die Zuordnung da, entscheiden die Teams selbst, weil sie die Wirkung ihrer Architektur sehen.
Wie viel lässt sich realistisch einsparen?
Das hängt davon ab, wie lange niemand hingesehen hat. Ein Account, auf den regelmäßig jemand schaut, gibt vielleicht 20 bis 30 Prozent her. In einem gewachsenen Account mit vier Jahren Sediment habe ich über zwölf Monate gut 83 Prozent erreicht, von rund 15.000 auf rund 2.500 Euro im Monat, ohne Abstriche an der Produktionsverfügbarkeit. Die Methode ist übertragbar, die Quote nicht.
Braucht man dafür ein FinOps-Werkzeug?
Für zwei bis drei Konten nicht. Der Cost and Usage Report plus ein Nachmittag SQL findet dasselbe wie ein Werkzeug, das mehrere Prozent der Ersparnis kostet, dauerhaft. Bei hunderten Konten sieht die Rechnung anders aus. Die unbequeme Wahrheit über diese Werkzeuge: Finden ist nicht das Problem, Ändern ist das Problem, und das nimmt einem kein Dashboard ab.
Wie verhindert man, dass die Kosten zurückwachsen?
Mit vier Dingen: erzwungenen Pflicht-Tags, Budgets mit Alarmen je Konto statt nur fürs Gesamtkonto, Aufbewahrungsregeln als Pflichtparameter in den IaC-Modulen, und einer wöchentlich sichtbaren Kostenzahl im Team. Ohne Gegenmaßnahmen wirken dieselben Kräfte weiter, die die Rechnung ursprünglich hochgetrieben haben.
Muss der Betrieb dafür angehalten werden?
Nein. Die ersten drei Phasen, also Löschen, Beobachtbarkeit und Daten, kommen ohne eine einzige Architekturänderung aus und machen in der Regel den größeren Teil der Ersparnis aus. Wichtig ist nur eine Regel: nichts sofort endgültig löschen, sondern erst stoppen, zwei Wochen warten, dann löschen.