Ein Entwicklungsteam richtet in AWS einen Kubernetes-Cluster ein – für ein internes Testsystem. Das Cluster läuft, die Tests laufen, am Ende des Sprints ist das Feature fertig. Der Cluster wird nicht mehr gebraucht. Er wird aber auch nicht abgebaut, weil niemand dafür zuständig ist und niemand weiß, ob er noch gebraucht wird. Drei Monate später erscheint er auf der AWS-Rechnung. Niemand fragt.
Das Szenario ist erfunden, aber es ist repräsentativ. Cloud-Verschwendung entsteht fast nie durch bösen Willen – sie entsteht durch unklare Zuständigkeiten und das Fehlen von Feedback-Schleifen zwischen denen, die Ressourcen erstellen, und denen, die die Rechnung sehen.
Was FinOps ist – und was nicht
FinOps steht für Financial Operations. Es ist kein Tool, keine Software-Kategorie und kein einmaliges Cost-Cutting-Projekt. Es ist eine Praxis, die technische Teams, Finanzteams und Business-Stakeholder zusammenbringt, um Cloud-Ausgaben gemeinsam zu verstehen und zu steuern.
Die FinOps Foundation – die Organisation, die den Begriff und das Framework geprägt hat – beschreibt die Grundlogik so: In der Cloud kann jedes Team Ressourcen in Minuten provisionieren. Die Verantwortung für die entstehenden Kosten folgt dieser Geschwindigkeit nicht automatisch. FinOps ist die Praxis, sie nachzuziehen.
Was FinOps nicht ist: ein Auftrag an die Finanzabteilung, die Cloud-Ausgaben zu begrenzen. Finanzteams können Cloud-Ressourcen nicht direkt steuern – das können nur die Teams, die sie erstellen und nutzen. Wer FinOps als reines Finance-Thema behandelt, löst das eigentliche Problem nicht.
Wie Cloud-Kosten typisch außer Kontrolle geraten
In On-Premise-Infrastruktur war das Bestellprinzip ein natürlicher Kostenbegrenzer: Hardware kaufen erforderte einen Budgetantrag, eine Lieferzeit, eine Installation. Wer eine VM brauchte, wartete. Wer zu viele beantragt hatte, saß auf ungenutzter Hardware, die im nächsten Investitionsgespräch auffiel.
In der Cloud entfällt dieser Reibungswiderstand. Eine EC2-Instanz in AWS, eine VM in Azure, ein Kubernetes-Cluster – das dauert Minuten und erfordert in den meisten Organisationen keine Genehmigung unterhalb eines bestimmten Schwellenwerts. Das ist der Geschwindigkeitsvorteil der Cloud. Es ist gleichzeitig das Cost-Governance-Problem.
Drei Muster sehen wir regelmäßig:
Zombie-Ressourcen: Instanzen, Volumes, Load Balancer, Snapshots, die niemand mehr aktiv nutzt aber auch niemand abgebaut hat. Sie existieren still und werden berechnet. Eine strukturierte Analyse typischer Unternehmens-Cloud-Umgebungen findet Zombie-Ressourcen, die fünf bis fünfzehn Prozent der Gesamtkosten ausmachen.
Überprovisionierung: Teams, die nicht wissen, wie viel Kapazität sie wirklich brauchen, nehmen sicherheitshalber mehr. Ein Server mit 64 GB RAM für eine Anwendung, die 12 GB nutzt, ist in On-Premise teuer und fällt auf. In der Cloud wird er einfach weiter bezahlt.
Ungenutzte Reservierungen: Cloud-Anbieter bieten erhebliche Rabatte (40–70%) für Ressourcen, die über ein oder drei Jahre reserviert werden. Teams kaufen Reservierungen für erwarteten Bedarf – dann ändert sich die Architektur, der Bedarf verschiebt sich, die Reservierung läuft aber weiter.
Warum Cost-Monitoring allein nicht hilft
Die erste Reaktion in den meisten Unternehmen ist: Wir brauchen ein Dashboard. AWS Cost Explorer, Azure Cost Management, ein Tool wie CloudHealth oder Apptio. Kosten sichtbar machen.
Das ist notwendig, aber nicht hinreichend.
Sichtbarkeit ohne Verantwortung ändert Verhalten nicht. Wenn ein Dashboard zeigt, dass Entwicklungsteam A 40.000 Euro im Monat ausgibt, aber unklar ist, wer das optimieren soll und welche Konsequenzen das hat – dann wird das Dashboard beobachtet, und die Kosten bleiben gleich.
FinOps-Reife beginnt dort, wo Sichtbarkeit in Verantwortlichkeit übersetzt wird. Das bedeutet konkret:
Tagging-Strategie: Jede Cloud-Ressource trägt Tags, die sie einem Team, einem Projekt, einer Kostensstelle und einem Environment (dev/staging/prod) zuordnen. Ohne konsequentes Tagging ist kein Cost-Reporting auf Team-Ebene möglich.
Showback und Chargeback: Teams sehen ihre eigenen Kosten – entweder als Information (Showback) oder als interne Verrechnung (Chargeback). Das verändert, wie Teams über Ressourcen entscheiden. Ein Team, das weiß, dass es 35.000 Euro im Monat kostet, geht anders mit Skalierungsentscheidungen um als eines, das die Rechnung nie sieht.
Cloud-Kosten in Engineering-Entscheidungen. Architekturentscheidungen haben Kostenimplikationen. Ob ein Event-Streaming-System auf Kinesis oder SQS aufgebaut wird, ob eine Datenbank auf RDS oder Aurora läuft, ob Autoscaling-Grenzen eng oder weit gesetzt werden – all das beeinflusst die monatliche Rechnung erheblich. Teams, die diese Zahlen nicht kennen, können keine informierten Entscheidungen treffen.
Was ein realistischer Einstieg aussieht
FinOps in einem bestehenden Cloud-Setup zu etablieren, erfordert keinen Big-Bang-Ansatz. Drei Schritte, die nacheinander funktionieren:
Schritt 1 – Bestandsaufnahme: Welche Cloud-Accounts existieren? Welche Ressourcen laufen? Wie ist das Tagging-Coverage? Was sind die größten Kostentreiber in absoluten Zahlen?
Schritt 2 – Quick Wins: Zombie-Ressourcen identifizieren und abbauen, Instanzgrößen auf tatsächliche Auslastung anpassen, ungenutzte Reservierungen analysieren. Das ist einmalige Arbeit mit messbaren Ergebnissen – und schafft Vertrauen, dass FinOps nicht nur Theorie ist.
Schritt 3 – Strukturen aufbauen: Tagging-Konventionen definieren und durchsetzen, Team-Level-Reporting einrichten, Verantwortlichkeiten festlegen, einen regelmäßigen Review-Prozess etablieren.
Der letzte Punkt ist der schwerste. Er erfordert, dass Engineering-Teams Cloud-Kosten als Teil ihrer Arbeit akzeptieren – nicht als externen Constraint, der von Finance kommt. Das ist eine kulturelle Veränderung, und sie braucht Sponsoring auf der Führungsebene.
Ohne das bleibt FinOps ein Dashboard, das niemand ernst nimmt.