Reserved Instances: Die Coverage-Quote, die nichts beweist
FinOps-Teams feiern hohe Coverage. Ohne Eligibility-Basis verdeckt die Quote teure Cloud-Kosten. Was FOCUS 1.4 jetzt wirklich ändert.
94 Prozent Commitment-Coverage standen im Quartalsreport, grün hinterlegt. Das Team war stolz. Niemand fragte, wie viel von der Cloud-Rechnung überhaupt commitment-fähig war und genau diese Frage entscheidet, ob die Zahl etwas wert ist oder nur gut aussieht.
Das Wichtigste in Kürze
- Coverage misst nicht, was die meisten glauben: Eine hohe Deckungsquote sagt nichts darüber, wie viel der Last überhaupt für ein Commitment qualifiziert war. Ohne die Eligibility-Basis ist die Zahl ein Verhältnis zu einer unbekannten Größe.
- FOCUS 1.4 trennt coverable von covered: Seit dem 4. Juni 2026 weist die Spalte CommitmentProgramEligibilityDetails aus, für welche Programme eine Position qualifiziert ist, unabhängig davon, ob ein Commitment greift. Erstmals provider-übergreifend standardisiert.
- Der Hebel sitzt vor dem Kauf: Wer eligibility-adjustierte Deckungsraten rechnet, sieht ungenutzte Sparpotenziale, bevor die nächste Drei-Jahres-Reservierung unterschrieben wird, statt sie im Nachhinein im Dashboard zu suchen.
Verwandt:Cloud-Broker gegen Multi-Cloud-Kosten / Wann sich Cloud-Repatriation rechnet
Die Zahl, die jeder reportet und kaum jemand hinterfragt
Commitment-Coverage gehört zu den ersten Kennzahlen, die ein FinOps-Team auf die Folie bringt. Sie beschreibt, welcher Anteil der commitment-fähigen Nutzung tatsächlich durch Reserved Instances, Savings Plans oder vergleichbare Zusagen gedeckt war. Klingt eindeutig. Das Problem steckt im Wort commitment-fähig.
Eine Coverage von 94 Prozent wie im Beispiel oben ist nur so aussagekräftig wie die Basis, auf die sie sich bezieht. Spot-Kapazität, bestimmte Managed Services, einzelne Lizenzmodelle und Workloads außerhalb der Commitment-Regionen zählen oft gar nicht als commitment-fähig. Schrumpft diese Basis, steigt die Quote, ohne dass ein Euro weniger ausgegeben wird. Ein Team kann also stolz auf diese Quote sein, während ein erheblicher Teil der Rechnung zu vollem On-Demand-Tarif durchläuft und in der Kennzahl schlicht nicht vorkommt.
Bisher war diese Lücke schwer zu schließen, weil jeder Anbieter Eligibility anders definiert und exportiert. Wer AWS, Azure und Google Cloud nebeneinander betrieb, baute pro Provider eigene Logik, um überhaupt zu bestimmen, was coverable war. Diese Logik veraltete mit jedem neuen Instanztyp. Die ehrlichere Kennzahl, die eligibility-adjustierte Deckungsrate, blieb für die meisten Teams eine Schätzung.
Diese 17 neuen Spalten allein im Contract-Commitment-Dataset sind kein Selbstzweck. Sie sind das Eingeständnis, dass Commitment-Entscheidungen ohne diese Struktur bisher auf Halbwissen getroffen wurden.
Was FOCUS 1.4 zwischen coverable und covered schiebt
FOCUS, die offene Spezifikation für Cloud-Kosten- und Nutzungsdaten, hat am 4. Juni 2026 die Version 1.4 ratifiziert. Zwei neue Datasets, 47 neue Spalten. Die für diese Diskussion entscheidende Neuerung ist ein einziges Feld auf dem Cost-and-Usage-Dataset: CommitmentProgramEligibilityDetails.
Das Feld ist ein JSON-Objekt, das pro Position auflistet, für welche Commitment-Programme diese Position qualifiziert war. Jeder Eintrag nennt einen ProgramType, unabhängig davon, ob aktuell ein Commitment darauf angewandt wird. Damit steht zum ersten Mal direkt in den Rohdaten, was coverable war und was nicht. Die eligibility-adjustierte Deckungsrate lässt sich daraus berechnen, statt sie zu schätzen, auch wenn die Aggregation weiterhin im eigenen Tooling passiert. Praktiker können ungenutzte Sparpotenziale identifizieren und Commitment-Optionen über Anbieter hinweg vergleichen, ohne pro Provider eigene Eligibility-Logik zu pflegen.
Ein Rechenbeispiel macht den Unterschied greifbar. Läuft ein Cluster zu 60 Prozent auf Spot-Kapazität, ist dieser Anteil gar nicht commitment-fähig. Eine gemeldete Coverage von 90 Prozent bezieht sich dann nur auf die übrigen 40 Prozent. Die hohe Spot-Last fällt komplett aus der Betrachtung. Die eligibility-adjustierte Sicht dreht die Frage um. Sie misst, wie viel der wirklich coverable Last gedeckt ist und legt offen, welcher Teil der Rechnung nie im Commitment-Spiel war. Wer nur die erste Zahl auf die Folie bringt, optimiert eine Kennzahl, die an der eigenen Kostenstruktur vorbeigeht.
Der zweite Block betrifft die Brücke zwischen Engineering und Buchhaltung. FOCUS 1.4 ergänzt ein Invoice-Detail-Dataset mit den Feldern, wie sie auf der ausgestellten Rechnung stehen, von Zahlungswährung über Zahlungsziel bis zur Bestellnummer. Dazu kommt ein Billing-Period-Dataset, das die tatsächlichen Abrechnungsgrenzen des Rechnungsstellers kennt. Wer schon einmal versucht hat, einen Monatsabschluss sauber zu rechnen, obwohl der Abrechnungszeitraum eines Anbieters nicht am Monatsersten beginnt, kennt den Wert dieser scheinbar trockenen Ergänzung.
Zusammengenommen verschiebt sich damit, was als verlässliche Quelle gilt. Die Usage-Telemetrie zeigt, was technisch passiert ist. Erst der Abgleich mit dem Invoice Detail zeigt, was wirklich berechnet wurde. Für ein FinOps-Team ist das der Unterschied zwischen einer plausiblen Zahl und einer belegbaren.
Was Plattform-Teams vor der nächsten Reservierung ändern sollten
Die naheliegende Konsequenz ist ein Wechsel der Leitkennzahl. Nicht die nackte Coverage gehört auf die Folie, sondern die eligibility-adjustierte Deckungsrate plus der absolute Euro-Betrag, der trotz Eligibility zu On-Demand-Konditionen lief. Diese zweite Zahl ist die unbequeme. Sie benennt das Geld, das auf dem Tisch liegt, bevor jemand eine neue Drei-Jahres-Reservierung rechtfertigt.
Der zweite Schritt ist architektonisch. Solange die Plattform ihre Kostenentscheidungen allein aus Usage-Daten ableitet, bleibt das Invoice Detail ein nachgelagerter Buchhaltungsvorgang. Sinnvoller ist, die Rechnungsdaten als gleichwertige Quelle in die Kostenpipeline zu ziehen und gegen die Telemetrie abzugleichen. Erst dann trägt Shift-Left im FinOps mehr als ein Schlagwort, weil die Zahlen, auf die Entwicklerteams reagieren, mit der Rechnung übereinstimmen, die am Monatsende eintrifft.
Ein Hinweis zur Erwartung gehört dazu. Die Spezifikation ist ratifiziert, die Werkzeuge ziehen nach.
Wer heute schon Commitment-Entscheidungen vorbereitet, sollte die Eligibility-Sicht jetzt einfordern, auch wenn sie übergangsweise noch aus provider-eigenen Feldern zusammengesetzt wird. Der Standard liefert die Sprache dafür. Die teure Verwechslung von coverable und covered lässt sich jetzt sauber benennen und das ist die Voraussetzung, sie abzustellen.
Häufige Fragen
Was ist der Unterschied zwischen Coverage und Eligibility?
Eligibility beschreibt, welche Nutzung überhaupt für ein Commitment qualifiziert ist. Coverage beschreibt, welcher Anteil dieser qualifizierten Nutzung tatsächlich gedeckt wurde. Eine hohe Coverage auf einer kleinen Eligibility-Basis kann große On-Demand-Kosten verdecken.
Was genau macht die Spalte CommitmentProgramEligibilityDetails?
Sie ist ein JSON-Feld auf dem Cost-and-Usage-Dataset und nennt pro Position die Commitment-Programme, für die diese qualifiziert war, unabhängig davon, ob ein Commitment greift. So lässt sich die eligibility-adjustierte Deckungsrate direkt aus den Daten berechnen, ohne provider-spezifische Logik.
Wozu dienen die neuen Datasets Invoice Detail und Billing Period?
Invoice Detail bildet die Felder der ausgestellten Rechnung ab, etwa Zahlungswährung, Zahlungsziel und Bestellnummer. Billing Period kennt die tatsächlichen Abrechnungsgrenzen des Anbieters. Gemeinsam ermöglichen sie einen sauberen Abgleich zwischen Nutzung und Rechnung, auch wenn Abrechnungszeiträume nicht dem Kalendermonat folgen.
Ab wann lässt sich FOCUS 1.4 produktiv prüfen?
Die Spezifikation ist seit dem 4. Juni 2026 ratifiziert. Der Konformitäts-Validator für 1.4 wird im dritten Quartal 2026 erwartet, bis dahin läuft die formale Prüfung gegen FOCUS 1.3. Die Datenfelder lassen sich nutzen, sobald der jeweilige Anbieter sie exportiert.
Müssen wir unsere FinOps-Tools jetzt umstellen?
Nicht sofort. Sinnvoll ist, die eligibility-adjustierte Deckungsrate als zusätzliche Leitkennzahl einzuführen und den Rechnungsabgleich als gleichwertige Datenquelle zu behandeln. Beides geht übergangsweise auch mit provider-eigenen Feldern, FOCUS 1.4 standardisiert es nur.
Lesetipps der Redaktion
Bildquelle: KI-generiert (Juli 2026)
