FinOps ist mehr als Cloud-Kostensenkung

KMU glauben oftmals, FinOps sei gleichbedeutend mit Kostensenkungen. Also «betreiben» sie FinOps. Sie betrachten ihre Cloud-Nutzung der letzten drei Monate, kaufen Reservierungen, senken die Kosten um 30 Prozent und verkünden den Erfolg. Sechs Monate später sind die Kosten wieder ausser Kontrolle, und niemand weiss warum. Das liegt daran, dass FinOps viel mehr ist als eine Massnahme zur Kostensenkung. Bei FinOps geht es darum, Verantwortlichkeiten zu schaffen, Prozesse zu implementieren und organisatorische Veränderungen voranzutreiben, um die Kosten unter Kontrolle zu halten und den Wert der Cloud zu maximieren, ohne die Innovation zu bremsen.

Was FinOps eigentlich ist

Eine öffentliche Institution, die jährlich rund 1,5 Millionen Dollar für Azure ausgab, verfügte über eine solide Reservierungsabdeckung: 80 Prozent der VMs waren reserviert, was monatlich über 70’000 Dollar einsparte. Man war überzeugt, über starke FinOps-Fähigkeiten zu verfügen. Dann stellte ein Berater eine schlecht konfigurierte neue Lösung mit übermässiger Protokollierung und fehlenden Aufbewahrungsrichtlinien bereit. Bei einem Budget von 2000 Dollar pro Monat stiegen die Kosten innerhalb von vier Monaten auf 33’000 Dollar. Als das Problem diagnostiziert wurde, hatte die Institution bereits 47’000 Dollar verloren. Es fehlte an einer Anomalieerkennung und einem Rechnungsprüfungsprozess. Der Sachverhalt soll zeigen: FinOps ist mehr als nur Kosteneinsparung. Was ist FinOps dann?

Die FinOps Foundation definiert FinOps als «ein operatives Rahmenwerk und eine kulturelle Praxis, die den geschäftlichen Wert von Technologie maximiert, eine zeitnahe datengestützte Entscheidungsfindung ermöglicht und durch die Zusammenarbeit zwischen Technik-, Finanz- und Geschäftsteams finanzielle Verantwortlichkeit schafft».


In einer ausgereiften FinOps-Praxis sind die Cloud-Kosten eine gemeinsame Verantwortung mit klar definierten Rollen und Zuständigkeiten. Die Teams haben Einblick in die Kosten der von ihnen entwickelten und betriebenen Systeme, tragen die Verantwortung für die von ihnen verursachten Ausgaben und erhalten Anreize, diese zu optimieren. Kosten sind Teil architektonischer Entscheidungen, Verschwendung wird kontinuierlich identifiziert und beseitigt oder bewusst als Kompromiss akzeptiert. Workloads werden an den Geschäftsanforderungen ausgerichtet, nicht an technischem Maximalismus. So sieht man nicht selten Unternehmen, in denen alle 5 Minuten Pipelines ausgeführt werden, obwohl eine Datenaktualität von nur 30 Minuten erforderlich wäre. Das bedeutet eine sofortige Einsparung von 83 Prozent. In einer FinOps-optimierten Umgebung wird das variable Kostenmodell voll ausgeschöpft: Umgebungen werden je nach Bedarf hoch- und heruntergefahren, ungenutzte Ressourcen werden abgeschaltet, und Ressourcen werden im Voraus reserviert, um den bestmöglichen Tarif zu sichern. Anomalien werden innerhalb weniger Tage erkannt und behoben. Technik, Finanzen und Beschaffung arbeiten nahtlos zusammen. Jede Rechnung wird vor der Zahlung geprüft, Budgets und Prognosen sind genau und werden von Personen erstellt, die die Kostentreiber verstehen. Das alles macht FinOps zu einem Hebel für geschäftlichen Mehrwert, aber auch geringere CO2- und Wasser-Fussabdrücke. Mit anderen Worten: Einsparungen und Kostenvermeidung sind das Ergebnis einer gut funktionierenden FinOps-Praxis, nicht die Praxis selbst.

Der Start mit FinOps

Viele KMU planen, eine FinOps-Umstellung zu beginnen, wenn sich «die Lage stabilisiert hat». Auf Stabilität zu warten bedeutet, erst zu handeln, wenn bereits eine hohe unerwartete Rechnung eingegangen ist. Der richtige Zeitpunkt für den Start ist jetzt, und der richtige Ausgangspunkt hängt davon ab, wo man als Unternehmen gerade steht.

Alte Lift-and-Shift-Infrastruktur: Hier häufen sich standardmässig Verschwendungen an, und eine Kostenverantwortung fehlt in der Regel. Was man typischerweise feststellt: 40 bis 50 Prozent der Instanzen könnten verkleinert werden; Workloads laufen rund um die Uhr, obwohl einige auf Null skaliert werden sollten; Daten liegen im Hot-Storage, ohne Lebenszyklusrichtlinien, obwohl sie in Archiv-Ebenen zehnmal günstiger wären; Anwendungsverantwortliche haben keinen Einblick in die Kosten ihrer Systeme; Reservierungskäufe sind blockiert, weil sich die Teams nicht darauf einigen können, wie die Einsparungen aufgeteilt werden sollen.
Ansatzpunkte: Die Definition eines Modells zur Kosten- und Einsparungsverteilung; das Erzielen erster schneller Erfolge, um Schwung aufzubauen und diese Dynamik dann zu nutzen, um die Zustimmung für eine umfassendere Governance zu sichern.


Cloud-native Unternehmen: Hier ist die Architektur in der Regel gut konzipiert. Die Frage ist, ob die Ausgaben durch tatsächliche Geschäftsanforderungen gerechtfertigt sind. Cloud-native Umgebungen sind von Natur aus effizient und standardmässig teuer, wenn sie nicht überprüft werden.
Ansatzpunkte: Die fünf grössten Kostenstellen identifizieren und jede einzelne im Hinblick auf die tatsächlichen Geschäftsanforderungen hinterfragen. Eine gute Architektur und gerechtfertigte Ausgaben sind nicht dasselbe.

Einführung von KI: KI-Workloads weisen Kostenprofile auf, die sich von allem anderen in einer typischen Infrastruktur unterscheiden. GPU-Rechenleistung, Inferenzvolumen und tokenbasierte Preisgestaltung führen zu ­un­gewohnten Kostentreibern mit unvorhersehbarer Nachfragedynamik. Das Risiko eines Kostenanstiegs ist unbegrenzt; ein schlecht konfiguriertes System kann an einem einzigen Tag hohe unerwarteter Kosten verursachen. Fin­Ops hilft dabei, den geschäftlichen Nutzen von KI-Workloads zu quantifizieren und nach ROI zu priorisieren, bevor die Ausgaben unkontrollierbar werden.
Ansatzpunkte: Kostentreiber Erfassen, eine Anomalieerkennung einrichten und eine an Geschäftsergebnisse gekoppelte Unit Economics definieren. Eine ergebnisorientierte Unit Economics hilft dabei, die KI-Strategie zu priorisieren.

Aktive Cloud-Migration: Der bestmögliche Zeitpunkt, mit FinOps zu starten. Eine Migration ist eine seltene Gelegenheit, das Zielbetriebsmodell zu definieren, bevor sich schlechte Gewohnheiten festsetzen: Tagging, Verantwortlichkeiten und Rechenschaftspflicht sollten von Anfang an in die Architektur integriert werden, anstatt sie später nachzurüsten. Unternehmen, die dies tun, vermeiden Kostenschocks. Auf die erste hohe Rechnung warten, um damit zu beginnen, währe ein Fehler.
Ansatzpunkte: FinOps-Governance von Beginn weg in den Migrationsumfang aufnehmen. Die Grundlagen lassen sich am kostengünstigsten schaffen, bevor die Workloads live gehen.

Die Stolpersteine

Bei der Einführung von FinOps treten immer wieder dieselben Fehler auf. Nachfolgend werden einige der häufigsten genannt.

Die Annahme, FinOps sei gleichbedeutend mit Reservierungen. Hyperscaler fördern diese Sichtweise, da langfristige Verpflichtungen für bestimmte VM-Typen und Regionen ihre Kapazitätsplanung unterstützen und Kunden binden. Reservierungen und Sparpläne sind ein legitimes Kosteninstrument, aber FinOps ist mehr als das. Und der Kauf zu vieler Verpflichtungen zu früh und ohne Strategie kann nach hinten losgehen.


Reservierungen ohne Strategie erwerben. Unternehmen kaufen Reservierungen, ohne zu verstehen, wie diese angewendet werden, ohne einen Zuweisungsmechanismus und ohne ihre stündlichen Nutzungsmuster zu kennen. Die Fragen, die zuerst zu klären sind: Werden ungenutzte Kapazitäten reserviert oder Workloads optimiert? Werden die Umtauschregeln und der Umfang der Reservierungen verstanden? Wie werden Kosten und Einsparungen intern verteilt? Wie sehen die Prognosen für ein Jahr und drei Jahre aus? Einige Unternehmen haben Hunderttausende von Franken an ungenutzten Dreijahresreservierungen, was zu einer negativen effektiven Einsparungsrate führt: Man zahlt mehr als den Listenpreis.

Fehlende Kostenverantwortung. Die Teams, die für die Infrastruktur verantwortlich sind, müssen auch die Kosten tragen. Ohne diese Verantwortung stösst jede Optimierungsmassnahme auf passiven Widerstand, und FinOps wird als Hindernis für die Umsetzung wahrgenommen, was zur Folge hat, dass die Einführung von FinOps auf Widerstand und organisatorische Trägheit stösst. Manche Unternehmen lassen monatlich erhebliche Einsparungen ungenutzt, weil sich die internen Teams nicht darauf einigen können, wie diese Einsparungen verteilt werden sollen. Während die Kostenverantwortung das ideale Endziel darstellt, ist der erste Schritt die Transparenz. Es empfiehlt sich, den Teams zunächst aufzuzeigen, wie hoch ihre Infrastrukturkosten sind und wie viel Verschwendung sie verursachen, um dann Kostenverantwortung aufzubauen.

Der Kauf eines Observability-Tools als erster Schritt. Da Transparenz der erste Schritt ist, beginnen viele Unternehmen damit, eine teure, erstklassige FinOps-Plattform anzuschaffen. Fin­Ops-­Plattformen werden jedoch als Prozentsatz der Ausgaben berechnet und sind teuer. Wer als Unternehmen 20’000 Franken pro Jahr zahlt, bevor das Betriebsmodell definiert ist, bevor das Tagging standardisiert ist und bevor das Chargeback-System in Betrieb ist, erhält ein Dashboard, auf das niemand reagiert. Es empfiehlt sich, mit nativen Tools und Kostenexporten zu beginnen und diese Tools zu nutzen, um deren Grenzen im Kontext Ihres Unternehmens zu verstehen. Die nativen Tools sind begrenzt, aber sie reichen aus, um den Anfang zu machen, und sie bringen Erkenntnisse zu einem Bruchteil der Kosten. Der Beschaffungs- und Einführungsprozess für ein Drittanbieter-Tool dauert Monate. Das sind Monate an verzögerten Einsparungen.

Sofortige Entwicklung massgeschneiderter Tools. Manche Unternehmen verbringen ihre gesamten ersten FinOps-Tage damit, massgeschneiderte Observability-Pipelines zu entwickeln, die genau auf ihre Bedürfnisse zugeschnitten sind. Auch das kostet Zeit. Die Behandlung aller Sonderfälle und die Wartung einer massgeschneiderten Plattform angesichts sich ständig ändernder Dateiformate für Kosten- und Nutzungsdaten sind ebenfalls Monate verzögerter Einsparungen. Auch hier lautet die Empfehlung, zunächst auf native Tools und Exporte zu setzen und massgeschneiderte Funktionen erst dann zu entwickeln, wenn sie einen Mehrwert bringen.

Übermässiges Vertrauen in Tagging und Tagging-Schulden. Fast jedes Unternehmen stellt fest, wie mangelhaft sein Tagging ist, sobald es versucht, Kosten zuzuweisen. Tagging ist nicht der einzige Zuweisungsmechanismus. Wird jedoch auf Tagging gesetzt, ist die nachträgliche Korrektur des Taggings in grossen Umgebungen mühsam. Darum die Empfehlung, Standards festzulegen, bevor diese benötigt werdem.

Auf der falschen Seite der Technik beginnen. Der erste Eindruck lässt sich nur schwer wieder umkehren. Wenn Ingenieure das Gefühl haben, dass FinOps es auf sie abgesehen hat, um Fehler zu finden, ihre Arbeit zu prüfen und mehr Tickets und Prozesse zu schaffen, wird die FinOps-Initiative schnell ins Stocken geraten. Die Technikteams sind diejenigen, die tatsächlich auf die Kosten einwirken können. FinOps muss von Anfang an als wertschöpfender Partner gesehen werden, und diese Wahrnehmung muss frühzeitig etabliert werden. Es empfiehlt sich, bewusst vorzugehen, wenn man sich an die Technik- und IT-Abteilungen wendet, den Ansatz konstruktiv und interaktiv zu gestalten und deutlich zu machen, dass das Ziel darin besteht, ihre Arbeit zu erleichtern, und nicht darin, sie nachträglich zu hinterfragen.

Unterschätzen der Qualifikations­lücke. FinOps befindet sich an der Schnittstelle von Cloud-Technologie, Finanzen und Geschäftsstrategie. Das ist eine ungewöhnliche Kombination, und ein FinOps-Leiter, der alle drei Bereiche abdeckt, ist ein seltenes Profil. Ohne gezielte Bemühungen um ein gemeinsames Verständnis zwischen allen Stakeholdern und ohne ausreichende Schulungen wird der Aufbau einer dauerhaften, kohärenten und funktionsübergreifenden FinOps-Praxis ein mühsamer Kampf sein.

Klein anfangen, dafür sofort

FinOps ist nicht gleichbedeutend mit Kostensenkungen; kein technisches Projekt mit einem Starttermin und einem Abschlussbericht. Es geht nicht darum, alle VMs mit Reservierungen abzudecken. FinOps ist ein Weg; eine organisatorische Kompetenz, deren Hauptherausforderungen kultureller Natur sind und deren Umfang und Wirksamkeit sich ständig verändern. Es geht darum, Kompromisse zwischen geschäftlichen Anforderungen, technischer Exzellenz und Kosten zu finden.

Die Empfehlung lautet, klein, aber möglichst rasch anzufangen, den Nutzen zu beweisen, an Dynamik zu gewinnen, sich die Zustimmung zu sichern, die erforderlichen Kompetenzen zu entwickeln und dann zu expandieren. Erfolgreiche Unternehmen warten nicht, bis sie bereit sind. Sie schaffen die Voraussetzungen, indem sie einfach anfangen.


Das Ziel von FinOps ist es nicht, eine perfekte Vorgehensweise zu haben, die alle Sonderfälle optimal bewältigen kann. Das Ziel ist ein Unternehmen, das seine Cloud-Kosten auf eine Weise versteht, kontrolliert und kontinuierlich optimiert, die seinem einzigartigen geschäftlichen Kontext und seinen Anforderungen entspricht.