Eine belegte Einsparung ist die Senkung, die nach einer umgesetzten Änderung tatsächlich in den Kosten erscheint, im Unterschied zu der Senkung, die vorher geschätzt wurde. Zwischen beiden liegen vier Zustände: geschätzt, angenommen, umgesetzt und belegt. Wer sie getrennt führt, kann jederzeit sagen, wie viel versprochen, wie viel getan und wie viel bewiesen ist. Wer sie vermischt, berichtet Schätzungen als Ergebnis und muss später erklären, warum die Rechnung nicht folgt.
So funktioniert es
| Zustand | Übergang dorthin | Was festgehalten wird |
|---|---|---|
| Geschätzt | ein Fund mit Betrag, Preisbasis und Zeitraum | Quelle, Ressourcen oder Umfang, Betrag pro Monat, Preisbasis, Annahmen |
| Angenommen | der Verantwortliche der Ressource sagt zu | Verantwortlicher, Datum, erwartete Wirkung, geplanter Termin, bei Commitments die Freigabe |
| Umgesetzt | die Änderung ist live | Datum, Beleg, betroffene Ressourcen-IDs |
| Belegt | der Vergleich auf festem Umfang zeigt die Wirkung | gemessene Wirkung, Vergleichszeiträume, Methode oder „nicht belegbar“ |
Abgelehnt ist ein Ausgang mit Grund, kein fünfter Schritt. Wie die Zustände im Optimierungskreislauf zusammenhängen, beschreibt Der Optimierungskreislauf.
Wie die Werkzeuge schätzen
AWS Cost Optimization Hub rechnet die Wirkung einer Empfehlung auf 730 Stunden hoch, den Durchschnitt eines Monats, und nimmt Zeiten aus, in denen die Ressource nicht lief. Je nach Einstellung gilt der Betrag nach Abzug aller Rabatte des Kontos, einschließlich Reserved Instances und Savings Plans, oder zu öffentlichen On-Demand-Preisen. AWS nennt den Betrag selbst eine schnelle Näherung: Was tatsächlich eingespart wird, hängt von der künftigen Nutzung ab.
Azure Advisor rechnet zu Retail-Preisen, ohne Rabatte des Kontos und ohne vorhandene Reservierungen oder Savings Plans, und Microsoft weist darauf hin, dass die angezeigte Einsparung deshalb höher sein kann als möglich.
Google rechnet mit Vertragspreisen, wenn ein individueller Preisvertrag besteht und die Kostenberechtigung vorliegt, sonst zu Listenpreisen, jeweils ohne Gutschriften und weitere Rabatte. Der FinOps Hub berücksichtigt bereits gekaufte Committed Use Discounts nicht. Bei Commitment-Empfehlungen beruht die Einsparung auf der tatsächlichen Nutzung, die Kaufübersicht dagegen auf Listenpreisen und voller Auslastung.
Was die Status der Provider bedeuten
Der Google Recommender kennt ACTIVE, CLAIMED für eine laufende Umsetzung, SUCCEEDED für angewendet, FAILED und DISMISSED; den Status setzen Sie oder ein anderer Prozess. Azure Advisor kennt in seiner Statusverwaltung, derzeit in Preview, Active, Postponed, Dismissed und Completed. Completed heißt, dass die Maßnahme angewendet wurde oder die Empfehlung nicht mehr zutrifft; Advisor prüft das alle 24 Stunden selbst und schreibt den Status dann endgültig fest.
Beide Status beschreiben die Ressource, nicht die Rechnung. SUCCEEDED und ein systemgeprüftes Completed entsprechen hier dem Zustand umgesetzt, nicht belegt. Beide sind zudem befristet: Google hält CLAIMED, SUCCEEDED und FAILED 90 Tage nach der Statusänderung vor, Advisor zeigt systemgeprüft erledigte Empfehlungen sechs Monate lang. Ein Jahresbericht braucht deshalb ein eigenes Register.
Die Prüfung
Die FinOps Foundation zählt in ihrer Capability Usage Optimization den regelmäßigen Abgleich der tatsächlichen Wirkung mit der ursprünglichen Schätzung zu den Merkmalen einer reiferen Praxis. Die Prüfung folgt einer festen Reihenfolge:
- Umfang festlegen. Dieselben Ressourcen-IDs, Konten oder Tags vor und nach der Änderung; eine ersetzte Ressource mit neuer ID wird ausdrücklich zugeordnet.
- Basis wählen. Ein Zeitraum vor der Umsetzung, gleich lang wie der Vergleichszeitraum danach, ohne den Tag der Umsetzung.
- Kostenmaß festhalten. Effektive Kosten in beiden Zeiträumen, weil sie Commitments über die Nutzung verteilen; welches Maß welche Frage beantwortet, steht unter Listen-, berechnete, effektive, amortisierte Kosten.
- Differenz zerlegen. In Mengen- und Preiseffekt, wie im Variance Walk des monatlichen Kostenreviews; eine Rightsizing-Maßnahme erklärt nur ihren Teil.
- Wachstum herausrechnen. Kosten je Einheit eines Treibers, etwa je Anfrage oder Kunde, wie unter Unit Economics und Stückkosten.
- Störgrößen prüfen. Preisänderungen, gekaufte, ausgelaufene oder verschobene Commitments, Gutschriften und Wechselkurse im Vergleichszeitraum.
- Ergebnis eintragen. Ein Betrag pro Monat mit Methode, oder „nicht belegbar“ mit Grund.
Was es für Ihre Kosten bedeutet
Berichtet werden vier Summen nebeneinander, nicht eine: geschätzt, angenommen, umgesetzt, belegt. Nur die letzte gehört als Einsparung in den Bericht an Geschäftsführung und Finanzen; die angenommenen Maßnahmen gehören ab ihrem geplanten Termin in die Prognose.
Belegte Einsparung und Differenz auf der Rechnung gehen aus mehreren Gründen auseinander. Ein Monat hat zwischen 672 und 744 Stunden, die Schätzung von AWS rechnet mit 730. Eine Umsetzung in der Monatsmitte wirkt nur für einen Teil des Monats. Wo ein Commitment die Ressource deckte, wandert der freie Rabatt auf andere Nutzung oder bleibt ungenutzt; die Einsparung erscheint dann auf Kontoebene kleiner als auf der Ressource, wie Rightsizing beschreibt. Und Wachstum an anderer Stelle kann die Rechnung steigen lassen, obwohl jede Maßnahme gewirkt hat. Auch der Begriff selbst ist nicht einheitlich: Der FinOps Hub von Google nennt „realisierte Einsparungen“ des Vormonats, rechnet das Abschalten ungenutzter Ressourcen ausdrücklich nicht ein und kann bei schlecht ausgelasteten CUDs eine negative Summe zeigen.
„Nicht belegbar“ ist ein gültiges Ergebnis: Wenn Umfang, Basis oder Störgrößen keinen sauberen Vergleich zulassen, ist eine erzwungene Zahl schlechter als keine.
Wo es schiefgeht
- Schätzung als Ergebnis. Symptom: Die gemeldeten Einsparungen übersteigen deutlich, was die Rechnung zeigt. Ursache: Geschätzte und angenommene Beträge wurden als Einsparung berichtet, oft auf Retail-Basis.
- Umfang gewandert. Symptom: Die Prüfung findet keine Kosten mehr für die Ressource. Ursache: Die Ressource wurde ersetzt und hat eine neue ID; der Vergleich läuft ins Leere.
- Wachstum verdeckt die Wirkung. Symptom: Nach dem Rightsizing steigen die Kosten des Dienstes. Ursache: Mehr Instanzen laufen, jede kostet weniger; ein Vergleich vorher gegen nachher ohne Normierung zeigt das Wachstum, nicht die Maßnahme.
- Preisänderung gutgeschrieben. Symptom: Eine Maßnahme zeigt mehr Wirkung als geschätzt. Ursache: Im selben Zeitraum sank ein Preis oder ein neues Commitment griff, und der Preiseffekt wurde der Maßnahme zugerechnet.
- Provider-Status als Beleg. Symptom: Alle Empfehlungen sind erledigt, die Kosten unverändert. Ursache: SUCCEEDED oder Completed sagen, dass die Ressource geändert wurde oder die Empfehlung nicht mehr zutrifft, nicht, dass die Rechnung sinkt.
- Historie verloren. Symptom: Der Jahresbericht findet die Maßnahmen des ersten Quartals nicht mehr. Ursache: Recommender und Advisor halten erledigte Empfehlungen nur befristet vor.
Beispiel
Ein Dienst läuft auf N0 Instanzen zum Stundenpreis P0. Die Maßnahme stellt auf eine kleinere Größe zum Preis P1 um. Im Vergleichszeitraum mit h Stunden laufen wegen gestiegener Last N1 Instanzen.
| Größe | Formel |
|---|---|
| Kosten vorher | N0 × P0 × h |
| Kosten nachher | N1 × P1 × h |
| Naiver Vergleich | N0 × P0 × h − N1 × P1 × h |
| Kosten ohne Maßnahme bei gleicher Last | N1 × P0 × h |
| Wirkung der Maßnahme | N1 × (P0 − P1) × h |
Ist N1 größer als N0 × P0 / P1, fällt der naive Vergleich negativ aus, obwohl die Maßnahme jede Stunde N1 × (P0 − P1) spart. Belegt ist die letzte Zeile, sofern die Zahl der Instanzen der Last folgt und nicht der Größe, P0 und P1 aus derselben Preisbasis stammen und kein Commitment die Instanzen in einem der Zeiträume deckte.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Usage Optimization (CC BY 4.0); AWS Geschätzte monatliche Einsparung und Einstellungen des Cost Optimization Hub; Microsoft Kostenempfehlungen für VMs und Scale Sets und Status von Advisor-Empfehlungen verwalten; Google Cloud Grundbegriffe des Recommender, Wie Einsparungen in Empfehlungen berechnet werden, Empfehlungen für Committed Use Discounts und Kosten mit dem FinOps Hub optimieren.