Eine FinOps-Rolle ist eine benannte Verantwortung für einen Teil der Cloud-Kosten: wer für die Kosten eines Bereichs antwortet, wer die Rechnung liest, wer Commitments kauft, wer eine Einsparung entscheidet und wer die Zuordnung pflegt. Für die Rechnung zählt weniger, wie diese Rollen heißen, als ob jede dieser Verantwortungen einen Namen trägt. Kosten ohne Verantwortlichen wachsen, weil niemand den Bericht liest, in dem sie stehen, und niemand die Frage beantworten muss, warum sie sich verändert haben.
So funktioniert es
Das FinOps Framework der FinOps Foundation beschreibt die Beteiligten als Personas und unterscheidet Kern-Personas von verbündeten Personas. Die Kern-Personas sind der FinOps Practitioner, der Business, Engineering und Finance verbindet und die Praxis zentral aufbaut; Engineering, das die Infrastruktur entwirft, baut und betreibt und dabei Kosten neben Leistung und Sicherheit stellt; Finance, das den Geschäftswert der Technologieausgaben beziffert und Prognose, Budget und Chargeback trägt; Product, das Anforderungen definiert und Initiativen an Geschäftszielen priorisiert; Procurement, das Technologie einkauft und Verträge, Verhandlungen und Lizenzen verwaltet; und Leadership, das Ziele setzt und die Rechenschaft für kosteninformierte Entscheidungen einfordert. Als verbündete Personas nennt das Framework ITAM, ITFM, Sustainability, ITSM/ITIL und Security: Disziplinen mit eigenem Auftrag, die Kostendaten mitnutzen oder liefern. Die Personas sind ein Rahmen, kein Organigramm; sie beschreiben, welche Perspektive am Tisch sitzen muss, nicht, wie viele Menschen dort sitzen.
Unabhängig von der Unternehmensgröße brauchen fünf Verantwortungen einen Träger:
- Der Kostenverantwortliche je Bereich antwortet für die Kosten eines Teams, eines Produkts oder einer Umgebung. Er sieht seinen Kostenbericht, erklärt die Abweichung und entscheidet innerhalb seines Budgets.
- Die Person, die die Rechnung liest und den Monat abschließt, prüft die Rechnung gegen die Abrechnungsdaten, bucht Gutschriften und Steuern richtig und legt fest, ab wann ein Monat als geschlossen gilt.
- Die Person, die Commitments kauft, entscheidet über Reserved Instances, Savings Plans und Committed-Use-Rabatte und trägt die Auslastung, die daraus folgt.
- Die Person, die eine Einsparung entscheidet, nimmt eine Einsparungschance an oder lehnt sie ab und trägt das Risiko der Änderung.
- Die Person, die die Zuordnung pflegt, hält Tag-Richtlinien, Zuordnungsregeln und Kontenstruktur so, dass der Zuordnungsgrad nicht mit jedem neuen Konto sinkt.
Die Tabelle ordnet sie den Kern-Personas zu: Eine Zelle sagt, ob die Persona die Verantwortung trägt, mitwirkt oder informiert wird.
| Verantwortung | FinOps Practitioner | Engineering | Finance | Product | Procurement | Leadership |
|---|---|---|---|---|---|---|
| Kosten eines Bereichs verantworten | wirkt mit | verantwortet | informiert | wirkt mit | informiert | informiert |
| Rechnung lesen und Monat abschließen | wirkt mit | informiert | verantwortet | informiert | informiert | informiert |
| Commitments kaufen | wirkt mit | wirkt mit | wirkt mit | informiert | verantwortet | informiert |
| Einsparung entscheiden | wirkt mit | verantwortet | informiert | wirkt mit | informiert | informiert |
| Zuordnung und Tags pflegen | verantwortet | wirkt mit | wirkt mit | informiert | informiert | informiert |
| Budget und Ziele setzen | wirkt mit | wirkt mit | wirkt mit | wirkt mit | informiert | verantwortet |
In einem kleinen Unternehmen fallen die Spalten zusammen, die Zeilen nicht. Ein Entwickler ist Engineering, Kostenverantwortlicher für alle Bereiche und FinOps Practitioner zugleich; eine Finance-Person liest die Rechnung, schließt den Monat ab und kauft die Commitments, die der Entwickler vorschlägt; die Geschäftsführung ist Leadership und Product zugleich und entscheidet einmal im Monat über Budget, Ziele und die Einsparungen, die eine Freigabe brauchen. Was auch dann einen Namen braucht: wer die Rechnung gegen die Daten prüft, wer ein Commitment unterschreibt und wer eine Einsparung ablehnen darf. Fehlt einer dieser Namen, liegt die Entscheidung bei niemandem, und die Rechnung entscheidet.
Zum Zugriff auf Kostendaten gehört dieselbe Klarheit. Lesender Zugriff ist der Normalfall: Jeder Kostenverantwortliche sieht seinen Bereich, ohne Einstellungen ändern zu können. Ein Administrator verbindet Konten und ändert Abrechnungseinstellungen; Finance braucht Exporte und Rechnungen. Die Provider bilden das in ihren Rollen ab: AWS schaltet den Zugriff auf die Billing-Konsole für IAM-Identitäten erst nach einer Aktivierung durch den Root-Benutzer frei und vergibt dann feingranulare Berechtigungen, bei in Organizations erstellten Mitgliedskonten ist die Einstellung standardmäßig aktiv; Azure trennt Cost Management Reader von Cost Management Contributor und vergibt sie je Scope, bei EA-Verträgen zusätzlich über die Einstellungen, ob Kontoinhaber und Abteilungen Kosten sehen dürfen; Google Cloud unterscheidet unter anderem Billing Account Viewer für den reinen Lesezugriff, Billing Account Costs Manager für Budgets und Exporte und Billing Account Administrator für die Verwaltung des Abrechnungskontos.
Was es für Ihre Kosten bedeutet
Rollen tauchen auf der Rechnung nicht auf, in den Daten aber schon. Jeder Bereich, der einen Kostenverantwortlichen hat, lässt sich in einem Kostenbericht als eigene Sicht abbilden und per Abonnement an diese Person senden; jeder Bereich ohne Verantwortlichen landet in einer Sammelposition, die niemand erklärt. Der Zuordnungsgrad ist deshalb die erste Kennzahl, an der sich ablesen lässt, ob das Rollenmodell trägt.
Die Auslastung der Commitments zeigt, ob die Verantwortung für den Kauf und die Verantwortung für die Nutzung zusammenpassen. Ein Commitment, das Finance gekauft hat, nachdem Engineering die Workload verkleinert hat, erscheint als bezahlte, aber ungenutzte Stunden. Die Zahl der offenen Einsparungschancen zeigt, ob jemand entscheidet: Eine Liste, die nur wächst, hat keinen Entscheider. Und die Abweichung zwischen Rechnung und Abrechnungsdaten zeigt, ob jemand den Monat abschließt; wird sie nie gemessen, prüft sie niemand.
Ungenutzte Ressourcen bleiben stehen, weil kein Bereich sie trägt; Reservierungen laufen weiter oder verlängern sich, weil niemand ihre Auslastung sieht; eine neue Region wird bezahlt, bevor jemand sie bemerkt. Showback, das jedem Verantwortlichen seine Zahlen zeigt, ist die günstigste Form, diese Kosten sichtbar zu machen, lange bevor Chargeback sie tatsächlich umlegt.
Wo es schiefgeht
- Ein FinOps Practitioner ohne Befugnis. Er sieht jede Abweichung, kann aber weder eine Einsparung anordnen noch ein Commitment stoppen. Die Berichte werden besser, die Rechnung nicht. Die Rolle braucht eine Entscheidung, die sie allein treffen darf, oder einen Entscheider, der ihr zuhört.
- Finance verantwortet die Kosten ohne Engineering. Finance sieht den Betrag, aber nicht die Ursache, und die Ursache sitzt in der Architektur. Die typische Folge ist ein Commitment, das zur Rechnung passt, aber nicht zur Workload.
- Kostenverantwortliche, die ihren Bericht nie sehen. Die Zuordnung existiert, der Bericht existiert, aber er erreicht die Person nicht, die handeln könnte. Verantwortung ohne Sicht ist eine Zeile in einem Dokument.
- Rollen im Dokument, nicht im Werkzeug. Wer lesen, wer verbinden und wer exportieren darf, steht in einem Organisationshandbuch, während in der Plattform alle Administrator sind. Die Rolle hält nur, wenn Zugriff und Benachrichtigung sie abbilden.
- Commitments und Nutzung in getrennten Händen. Procurement kauft nach Rechnung, Engineering plant nach Bedarf, und keiner sieht den Kalender des anderen. Wer das Commitment unterschreibt, muss die Nutzungsprognose derjenigen gegenzeichnen lassen, die sie verantworten.
Quellen
Gelesen am 2026-10-15. FinOps Foundation FinOps Framework (CC BY 4.0) und Personas; AWS Zugriff auf Abrechnungsinformationen und Werkzeuge verwalten; Microsoft Zugriff auf Cost-Management-Daten zuweisen; Google Cloud Zugriff auf Cloud Billing steuern.