Kosten & Steuerung

FinOps einführen: Cloud-Kosten dauerhaft im Griff behalten

Die großen Einsparungen kommen nicht aus Rabattverträgen, sondern daraus, dass Teams sehen, was ihre Entscheidungen kosten. Rabattmodelle wie Savings Plans oder Reservierungen sind der zweite Schritt und binden euch für ein bis drei Jahre. Wer sie vor dem Aufräumen kauft, zementiert die eigene Verschwendung und zahlt dann Rabatt auf Ressourcen, die niemand braucht.

5 Kapitel mit allen Befehlen
Einsteigerin in die Cloud-Administration an zwei Monitoren mit Dashboards
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum Sparaktionen nach drei Monaten verpuffen

Der Ablauf ist fast immer derselbe. Die Rechnung überrascht, die Geschäftsführung fragt nach, das Plattformteam schaltet an einem Wochenende Testumgebungen ab und kauft Rabattverträge. Ein Quartal später liegen die Kosten wieder über dem alten Wert, weil die Ursache nicht angefasst wurde: Niemand sieht im Alltag, was eine Entscheidung kostet, und niemand ist dafür zuständig. FinOps setzt genau hier an. Es ist kein Werkzeug, sondern eine Arbeitsteilung zwischen Plattform, Entwicklung und Controlling mit einem festen Takt.

Das zweite Problem ist die Datenlage. Cloud-Rechnungen sind auf Abrechnung ausgelegt, nicht auf Steuerung. Ohne durchgängige Kennzeichnung lässt sich nicht sagen, welches Team oder welches Produkt welchen Anteil verursacht, und ohne diese Zuordnung ist jede Diskussion über Einsparungen eine Meinungsfrage. Die Kennzeichnung nachträglich einzuführen, ist mühsam, weil viele Ressourcen aus Vorlagen entstehen und ein Teil der Kosten, etwa Datenverkehr zwischen Zonen, sich gar keiner einzelnen Ressource zuordnen lässt.

Und dann sind da die Rabattmodelle, die in der falschen Reihenfolge gekauft werden. Savings Plans und Reservierungen senken den Preis je Stunde, sie senken nicht den Verbrauch. Wer sie vor dem Aufräumen kauft, verpflichtet sich für ein oder drei Jahre auf eine Auslastung, die eigentlich abgebaut werden sollte. AWS-Savings-Plans lassen sich nicht kündigen, Azure-Reservierungen nur gegen eine Gebühr und mit Deckelung. Diese Bindung ist der teuerste einzelne Fehler im ganzen Thema, weil sie sich über Jahre auswirkt.

Miniatur-Szene: Treppe aus drei Stufen hinauf zu einer schwebenden Cloud, Laptop und Wegweiser

Der FinOps-Kreislauf in fünf Stationen

  1. 01 Kennzeichnung verbindlich machen und technisch erzwingen
  2. 02 Kosten je Team sichtbar machen, zunächst als Showback
  3. 03 Ungenutztes abräumen und Größen anpassen
  4. 04 Rabattmodelle nur auf den stabilen Grundverbrauch kaufen
  5. 05 Budgets, Alarme und monatlicher Termin als Routine
Was du mitnimmst

FinOps als Kreislauf aus drei Phasen

Das Rahmenwerk der FinOps Foundation beschreibt drei Phasen, die immer wieder durchlaufen werden: sichtbar machen, verbessern, verankern. Die Reihenfolge ist nicht verhandelbar, weil jede Phase die Daten der vorigen braucht.

Inform: Kosten sichtbar und zuordenbar machen

Am Anfang steht die Zuordnung, nicht die Einsparung. Dazu gehören eine verbindliche Kennzeichnung mit wenigen Pflichtmerkmalen, aktivierte Kostenzuordnungsmerkmale in der Abrechnung und ein Bericht, den die Teams selbst aufrufen können. Ziel der Phase ist eine Zahl je Team und je Produkt, der alle Beteiligten glauben. Ohne diese Grundlage bleibt jede weitere Maßnahme angreifbar.

Optimize: erst aufräumen, dann einkaufen

Ungenutzte Datenträger, verwaiste Adressen, überdimensionierte Maschinen, Umgebungen ohne Abschaltzeiten und Daten in zu teuren Speicherklassen kosten sofort und ohne Gegenwert. Diese Positionen gehören zuerst weg. Erst wenn der Grundverbrauch stabil ist, lohnt der Einkauf von Rabattmodellen, und dann nur für den Anteil, der verlässlich rund um die Uhr läuft.

Operate: aus Aktionen Routine machen

FinOps wirkt erst mit festem Takt: ein monatlicher Termin mit Plattform, Entwicklung und Controlling, ein Budget je Team mit Alarmschwellen, eine Anomalieerkennung für ungeplante Ausschläge und eine kurze Liste offener Maßnahmen mit Namen dahinter. Ohne diesen Takt ist der Zustand von vor der Aufräumaktion innerhalb von zwei Quartalen zurück.

Wer ins Team gehört

Drei Rollen, nicht drei Abteilungen. Aus der Plattform kommt, wer die Umgebung technisch verändern kann, aus der Entwicklung, wer Architekturentscheidungen trifft, aus dem Controlling, wer Budgets und Verrechnung verantwortet. Eine FinOps-Rolle ohne technische Beteiligung erzeugt Berichte, die niemand umsetzt. Eine rein technische Runde diskutiert Einsparungen ohne kaufmännischen Bezug.

Showback vor Chargeback

Fang damit an, Teams ihre Kosten zu zeigen, ohne sie zu belasten. Allein die Sichtbarkeit senkt den Verbrauch messbar und erzeugt keine Abwehrreaktion. Echte Verrechnung lohnt sich erst, wenn die Zuordnung sauber ist und die Teams tatsächlich Einfluss auf ihre Kosten haben. Umgekehrt entsteht eine lange Diskussion über Zahlen statt über Maßnahmen.

Von absoluten Zahlen zu Kosten je Einheit

Die reife Stufe misst nicht mehr die Gesamtsumme, sondern die Kosten je Bestellung, je aktiver Person oder je verarbeitetem Auftrag. Diese Kennzahl darf steigen, wenn das Geschäft schneller wächst, und sie zeigt Probleme, die eine Gesamtsumme verdeckt. Für den Vergleich über Anbieter hinweg hat die FinOps Foundation mit FOCUS ein einheitliches Format geschaffen, das AWS, Azure und Google Cloud liefern.

Tutorial

Von der ersten belastbaren Zahl bis zur monatlichen Routine

Die großen Einsparungen kommen nicht aus Rabattverträgen, sondern daraus, dass Teams sehen, was ihre Entscheidungen kosten. Wer Rabattmodelle vor dem Aufräumen kauft, zementiert die eigene Verschwendung, deshalb ist die Reihenfolge hier nicht verhandelbar: erst Kosten sichtbar machen, dann die Kennzeichnung technisch erzwingen, danach aufräumen, erst anschließend Rabattmodelle bemessen und zuletzt das Ganze mit Budgets, Alarmen und einem festen Termin verankern. Die Befehle stehen für AWS und Azure nebeneinander.

01

Schritt 1: Kosten sichtbar machen

Bevor irgendjemand spart, braucht ihr eine Zahl, der alle glauben. Beide Anbieter liefern sie über die Kommandozeile, damit sie in eigene Berichte und Dashboards einfließen kann.

AWS: Kosten je Dienst und je Kennzeichnung
# Kosten des laufenden Quartals je Dienst
aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Dieselbe Frage, aber nach Kostenstelle aufgeteilt
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=Kostenstelle

Abfragen über Cost Explorer werden je Aufruf abgerechnet. Das ist belanglos, solange ein Bericht stündlich läuft, und wird spürbar, sobald ein Dashboard bei jedem Seitenaufruf neu abfragt. Speichere die Ergebnisse zwischen, statt live abzufragen.

Azure: Kosten je Ressourcengruppe und wiederkehrender Export
az costmanagement query \
  --type ActualCost --timeframe MonthToDate \
  --scope "/subscriptions/$SUB_ID" \
  --dataset-grouping name=ResourceGroupName type=Dimension

# Rohdaten regelmaessig exportieren statt jedes Mal abzufragen
az costmanagement export list --scope "/subscriptions/$SUB_ID" --output table

Für alles, was über einzelne Abfragen hinausgeht, richte einen wiederkehrenden Export in einen Speicher ein. Wähle dabei das FOCUS-Format statt des anbietereigenen Schemas: AWS, Azure und Google Cloud liefern damit dieselben Spaltennamen, und eure Auswertung funktioniert anbieterübergreifend ohne Umbau.

02

Schritt 2: Kennzeichnung erzwingen statt erbitten

Freiwillige Kennzeichnung liegt nach einem Jahr bei etwa der Hälfte der Ressourcen. Beide Anbieter können sie technisch durchsetzen, und genau das solltet ihr tun, bevor ihr über Zahlen diskutiert.

AWS Tag Policy: erlaubte Schreibweisen und Werte festlegen
{
  "tags": {
    "kostenstelle": {
      "tag_key": { "@@assign": "Kostenstelle" },
      "tag_value": { "@@assign": ["4711", "4712", "4713"] },
      "enforced_for": { "@@assign": ["ec2:instance", "ec2:volume", "rds:db"] }
    }
  }
}

Tag Policies vereinheitlichen Schreibweisen und verhindern falsche Werte, sie erzwingen aber nicht, dass ein Merkmal überhaupt gesetzt wird. Für die Pflicht brauchst du zusätzlich eine SCP mit einer Bedingung auf aws:RequestTag oder eine Prüfung in der Pipeline, die ein Rollout ohne Kennzeichnung ablehnt.

Azure Policy und die Aktivierung der Merkmale in AWS
# Azure: Kennzeichnung von der Ressourcengruppe erben lassen
az policy assignment create \
  --name erbe-kostenstelle \
  --scope "/subscriptions/$SUB_ID" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/cd3aa116-8754-49c9-a813-ad46512ece54" \
  --params '{"tagName":{"value":"Kostenstelle"}}' \
  --mi-system-assigned --location germanywestcentral

# AWS: welche Merkmale sind noch nicht als Kostenzuordnung aktiviert?
aws ce list-cost-allocation-tags --status Inactive --output table

Der zweite Befehl deckt eine Falle auf, die viele Wochen kostet: In AWS erscheinen Merkmale erst dann in der Abrechnung, wenn sie ausdrücklich als Kostenzuordnungsmerkmal aktiviert wurden, und die Aktivierung wirkt nicht rückwirkend. Eine Azure-Zuweisung mit Änderungswirkung braucht außerdem eine verwaltete Identität und eine Behebungsaufgabe für den Bestand.

03

Schritt 3: Aufräumen, bevor ihr einkauft

Die ersten zehn bis zwanzig Prozent Einsparung liegen fast immer in Ressourcen, die niemand vermisst. Sie zu finden ist eine Frage von Abfragen, nicht von Verhandlungen.

AWS: verwaiste Ressourcen und Empfehlungen zur Größe
# Nicht angehaengte Datentraeger
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,CreateTime]' --output table

# Reservierte oeffentliche Adressen ohne Zuordnung
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table

# Empfehlungen zur Groessenanpassung
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceName,currentInstanceType,finding,recommendationOptions[0].instanceType]' \
  --output table

Nicht angehängte Datenträger und reservierte Adressen ohne Zuordnung kosten weiter, obwohl sie nichts tun. Lösche sie nicht sofort, sondern erzeuge zuerst eine Momentaufnahme und warte dreißig Tage. Der Speicher für Momentaufnahmen kostet einen Bruchteil eines laufenden Datenträgers, und der Rückweg bleibt offen.

Azure: Advisor und ungenutzte Datenträger
az advisor recommendation list --category Cost --output table

az graph query -q "Resources
  | where type =~ 'microsoft.compute/disks'
    and properties.diskState == 'Unattached'
  | project name, resourceGroup, properties.diskSizeGB" --output table

Der Advisor bewertet nur, was lange genug gemessen wurde. Neu angelegte Ressourcen tauchen erst nach einigen Tagen auf, und Umgebungen, die nachts abgeschaltet sind, erscheinen fälschlich als überdimensioniert. Prüfe die Vorschläge einzeln, statt sie stapelweise umzusetzen.

Reihenfolge beim Aufräumen

  • Nicht angehängte Datenträger, alte Momentaufnahmen und ungenutzte öffentliche Adressen entfernen.Sie erzeugen laufende Kosten ohne jeden Gegenwert und lassen sich ohne Abstimmung mit Fachbereichen abbauen. Das ist der schnellste sichtbare Erfolg und schafft Rückhalt für die unbequemeren Schritte.
  • Nicht produktive Umgebungen außerhalb der Arbeitszeit abschalten.Entwicklung und Test werden selten mehr als fünfzig Stunden pro Woche genutzt, aber für einhundertachtundsechzig bezahlt. Eine Abschaltautomatik spart hier meist mehr als jede Größenanpassung.
  • Speicherklassen und Aufbewahrungsregeln für Objektspeicher und Protokolle festlegen.Protokolle und Sicherungen wachsen unbemerkt und liegen meist in der teuersten Klasse. Lebenszyklusregeln wirken auf den gesamten Bestand, nicht nur auf neu hinzukommende Daten.
  • Maschinen erst nach der Abschaltautomatik verkleinern.Größenanpassung braucht Abstimmung, Testfenster und oft einen Neustart. Wer damit anfängt, verliert Wochen, bevor der erste Euro eingespart ist, und verliert dabei die Aufmerksamkeit der Beteiligten.
  • Datenverkehr zwischen Zonen und Regionen gezielt prüfen.Diese Positionen tauchen in keiner Ressourcenliste auf und sind in verteilten Architekturen oft der zweitgrößte Posten. Ein falsch platzierter Dienst kann mehr kosten als die Rechenleistung, die er verbraucht.
04

Schritt 4: Rabattmodelle richtig bemessen

Rabatte haben die größte Hebelwirkung und das größte Risiko. Kaufe nur den Anteil ab, der auch in einem schlechten Quartal noch läuft.

Empfehlung einholen und bestehende Zusagen prüfen
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationSummary'

# Wie gut sind die bereits gekauften Zusagen ausgelastet?
aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-07-01 --granularity MONTHLY

Die Empfehlung rechnet ausschließlich mit der Vergangenheit. Prüfe sie gegen geplante Migrationen, Abkündigungen und saisonale Spitzen, bevor du kaufst. Ein Jahr ohne Vorauszahlung ist der übliche Einstieg, weil die Bindung überschaubar bleibt und sich die Auslastung noch beobachten lässt.

Rabattmodelle im Vergleich

ModellBindungFlexibilitätAusstieg
AWS Compute Savings Plan1 oder 3 JahreGilt über Instanztypen, Regionen, Fargate und Lambda hinwegNicht kündbar und nicht übertragbar
AWS EC2 Instance Savings Plan1 oder 3 JahreHöherer Rabatt, dafür an Instanzfamilie und Region gebundenNicht kündbar
AWS Reserved Instance, konvertierbar1 oder 3 JahreUmtausch in andere Typen möglichUmtausch statt Kündigung
Azure Reservierung1 oder 3 JahreAn Dienst und meist an Region gebunden, Geltungsbereich anpassbarStorno gegen Gebühr, mit Obergrenze je Zwölfmonatszeitraum
Azure Savings Plan für Compute1 oder 3 JahreGilt über mehrere Rechendienste hinwegNicht kündbar
Spot- und NiedrigpreiskapazitätkeineSehr hoher Rabatt, jederzeit entziehbarJederzeit, dafür Unterbrechungen einplanen
05

Schritt 5: Budgets, Alarme und ein fester Takt

Ohne Verankerung bleibt FinOps eine Aufräumaktion mit Halbwertszeit. Drei Dinge halten den Zustand: ein Budget je Team, eine Erkennung für Ausreißer und ein Termin im Kalender.

Budget, Anomalieerkennung und Kontrolle
# AWS: Budget mit Alarm auf die hochgerechnete Monatssumme
aws budgets create-budget --account-id 111122223333 \
  --budget file://budget-team-shop.json \
  --notifications-with-subscribers file://alarm.json

# Ungeplante Ausschlaege je Dienst erkennen
aws ce create-anomaly-monitor --anomaly-monitor \
  '{"MonitorName":"alle-dienste","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}'

# Azure: bestehende Budgets pruefen
az consumption budget list --output table

Setze den Alarm nicht auf den bereits erreichten Betrag, sondern auf die Prognose. Ein Alarm bei achtzig Prozent des Monatsbudgets kommt am achtundzwanzigsten und hilft niemandem mehr, ein Alarm auf die hochgerechnete Monatssumme kommt am siebten und lässt noch Zeit zum Handeln.

Der monatliche Termin dauert dreißig Minuten und hat drei Punkte: Abweichung gegenüber dem Vormonat je Team, Stand der offenen Maßnahmen, Auslastung der gekauften Zusagen. Fällt dabei ein einzelner Posten wiederholt auf, gehört er in eine gezielte Untersuchung, wie sie unter Cloud-Kosten analysieren beschrieben ist. Läuft ein großer Teil eurer Last in Kubernetes, kommt die Zuordnung je Namensraum hinzu, dafür lohnt der Blick auf Kubernetes-Kosten senken.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu FinOps und Cloud-Kosten

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Ab welcher Größe lohnt sich FinOps?
Ab dem Punkt, an dem niemand mehr aus dem Kopf sagen kann, wofür die Rechnung entsteht. In der Praxis liegt diese Schwelle bei etwa zehntausend Euro Cloud-Ausgaben im Monat, unabhängig von der Unternehmensgröße. Darunter reichen Budgetalarme, eine saubere Kennzeichnung und ein Blick pro Quartal. Darüber lohnen sich benannte Rollen, ein fester Termin und eigene Berichte, weil die Summe vieler kleiner Entscheidungen sonst schneller wächst als die Aufmerksamkeit. Der Aufwand für den Einstieg liegt bei wenigen Tagen, nicht bei einem Projekt.
Braucht es eine eigene Stelle dafür?
In den meisten Häusern nicht, jedenfalls nicht am Anfang. Wirksam ist eine benannte Person mit etwa einem Tag pro Woche und ein festes Trio aus Plattform, Entwicklung und Controlling. Eine eigene Stelle lohnt sich erst bei Ausgaben im Millionenbereich pro Jahr oder wenn mehrere Anbieter parallel laufen. Entscheidend ist nicht die Stellenbeschreibung, sondern dass jemand die Maßnahmenliste führt und der Termin auch dann stattfindet, wenn gerade kein Kostenproblem brennt.
Savings Plans oder Reserved Instances?
Für die meisten ist der Compute Savings Plan die richtige Antwort, weil er über Instanzfamilien, Regionen sowie Fargate und Lambda hinweg gilt und damit Umbauten nicht bestraft. Reserved Instances lohnen dort, wo eine Last nachweislich in einer Familie und Region bleibt, etwa bei Datenbanken, und wo der höhere Rabatt zählt. Die harte Grenze ist der Ausstieg: Savings Plans sind nicht kündbar, konvertierbare Reservierungen lassen sich immerhin umtauschen. Kauf deshalb den stabilen Grundverbrauch ab, nie die Spitze.
Wie bringen wir Kostenverantwortung in die Teams, ohne zu bremsen?
Über Sichtbarkeit und über Leitplanken, nicht über Genehmigungen. Jedes Team bekommt seine Kosten in einem Bericht, den es selbst aufrufen kann, dazu ein Budget mit Alarm auf die Prognose und eine kurze Liste von Vorgaben, etwa Pflichtkennzeichnung und Abschaltzeiten für nicht produktive Umgebungen. Was dagegen zuverlässig bremst, sind Freigabeschleifen für einzelne Ressourcen. Sie verlagern die Verantwortung zurück zur Plattform und erzeugen genau die Umgehungen, die später niemand mehr findet.
Welches Werkzeug brauchen wir dafür?
Für den Anfang reicht, was die Anbieter mitliefern: Cost Explorer, Budgets und Anomalieerkennung bei AWS, Microsoft Cost Management und Advisor bei Azure. Ein eigenes Werkzeug lohnt sich in zwei Fällen: wenn ihr mehrere Anbieter in einer Sicht zusammenführen wollt, oder wenn Kubernetes einen großen Teil der Kosten ausmacht und ihr je Namensraum zuordnen müsst, wofür OpenCost der offene Standardweg ist. Achte bei jeder Auswahl darauf, dass das Werkzeug FOCUS-Daten lesen kann, sonst baut ihr die Zuordnung ein zweites Mal.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

FinOps mit beiden Seiten besetzen, nicht nur mit der Technik

Die technische Seite deckt AWS Cloud Financial Management for Builders ab, die kaufmännische AWS Cloud for Finance Professionals. Wer den Betrieb dazwischen verantwortet, findet in Cloud Operations on AWS die Werkzeuge für Überwachung und Steuerung, und AWS Well-Architected Best Practices ordnet Kosten in die übrigen Entwurfsprinzipien ein. Alle Kurse laufen Live-Online oder in Präsenz. Schick am besten Plattform und Controlling gemeinsam, denn genau an dieser Schnittstelle entsteht der Nutzen.