Eine Commitment-Strategie behandelt alle Reservierungen, Savings Plans und Committed Use Discounts eines Unternehmens als ein Commitment-Portfolio mit Typen, Geltungsbereichen, Laufzeiten und Enddaten, statt jeden Kauf einzeln zu entscheiden. Ihr Kern: Die stabile Grundlast ist abgedeckt, der schwankende Teil läuft zum On-Demand-Preis, und die Käufe sind so gestaffelt, dass nie alles zugleich ausläuft. Erst als Portfolio zeigt sich, wie Abdeckung, Flexibilität und Ablaufdaten zusammenwirken; eine einzelne Kaufentscheidung zeigt das nicht.
So funktioniert es
Das Register
Grundlage ist eine Liste aller laufenden Commitments:
| Feld | Wozu |
|---|---|
| Programm und Typ | bestimmt, was das Commitment bindet und in welcher Reihenfolge es greift |
| Geltungsbereich | Konto, Subscription, Projekt oder geteilt; bestimmt, welche Nutzung es findet |
| Zusage und Zahlungsweise | Stundenbetrag oder Menge, Vorauszahlung oder monatlich |
| Start, Ende, Verlängerung | der Ablaufkalender und ob es sich selbst verlängert |
| Auslastung und Beitrag zur Abdeckung | ob es zu groß, zu klein oder passend ist |
| Verantwortlicher | wer gekauft hat und über die Verlängerung entscheidet |
Bei AWS steht das Enddatum je Commitment im Cost and Usage Report, in reservation_end_time und savings_plan_end_time. Wie Verlängerung, Tausch und Ablaufbenachrichtigungen je Provider funktionieren, beschreibt Tausch, Kündigung und Ablauf von Commitments.
Basis und Spitze
Abgedeckt wird, was jede Stunde läuft; die Spitze bleibt On-Demand oder geht, wo sie Unterbrechungen verträgt, auf Spot-Kapazität. Die Empfehlungen der Provider setzen die Grenze unterschiedlich. Google bietet zwei Modelle: Stable usage richtet die Zusage an Ressourcen aus, die 30 Tage lang durchgehend liefen, Optimal savings maximiert die Nettoersparnis und rechnet auch zeitweise Nutzung ein, soweit sie die Gewinnschwelle erreicht. Nutzung, die schon ein Commitment deckt, zählt dabei nicht. Microsoft simuliert für Savings Plans viele Kandidaten gegen die tatsächlichen On-Demand-Kosten und gibt stets den niedrigeren Wert aus 3- und 30-Tage-Betrachtung aus, damit ein Rückgang der Nutzung nicht zu Überdeckung führt. Eine höhere Zusage senkt die Auslastung je Stunde, eine niedrigere lässt mehr Stunden ungedeckt. AWS empfiehlt den Betrag mit der größten geschätzten Einsparung über einen Rückblick von 7, 30 oder 60 Tagen und betont, dass die Empfehlung keine Prognose ist.
Alle drei rechnen aus der Vergangenheit; eine geplante Migration, ein auslaufendes Produkt oder ein neuer Großkunde stehen nicht in den Daten. Die Basis ist deshalb eine Entscheidung mit Prognose, nicht das Ergebnis einer Empfehlung, und sie wird nach dem Rightsizing bemessen, weil ein Commitment die Nutzung festschreibt, die es abdeckt, wie Der Optimierungskreislauf beschreibt.
Schichten
Spezifische Commitments, also Reservierungen und ressourcenbasierte CUDs, greifen vor den flexiblen; die Reihenfolge je Provider steht in Commitment-Rabatte der Cloud-Anbieter im Vergleich. Daraus folgt eine Schichtung: ein spezifischer Teil für Nutzung, deren Typ, Familie und Region feststehen, darüber ein flexibler Teil für Nutzung, die wandert. Zwischen dem Kauf eines Savings Plans und einer Reservierung für dieselbe Nutzung rät Microsoft zu mindestens sieben Tagen, nie zu beidem zugleich. AWS erstellt die Empfehlungen für Compute und EC2 Instance Savings Plans aus derselben Nutzung; sie sind nicht dafür gedacht, gleichzeitig umgesetzt zu werden.
Staffeln
Wer die gesamte Basis an einem Tag kauft, hat ein Enddatum für alles und eine einzige Entscheidung zur falschen Zeit. Die FinOps Foundation empfiehlt in ihrer Capability Rate Optimization, Käufe über das Jahr zu verteilen, damit regelmäßig Commitments auslaufen und neu bewertet werden; Microsoft rät, klein anzufangen und gezielt dort zu kaufen, wo die Sicherheit hoch ist. Gestaffelt wird in Tranchen, von denen jede einen Teil der Basis deckt und zu einem anderen Termin ausläuft. Jede Tranche wird gegen frische Empfehlungen geprüft, denn die alten hinken jedem Kauf hinterher.
Wer entscheidet
Die Foundation verortet Analyse und Kauf zentral, die Verhandlung beim Einkauf und die Leitlinien bei Finanzen und Leitung. Microsoft empfiehlt einen Prozess für zentrale Käufe mit einem benannten Team oder einer Person und eine einheitliche Überwachung von Auslastung und Abdeckung über alle Konten. In kleinen Unternehmen ist das oft eine Person, die mit Engineering abstimmt; die Rollen beschreibt FinOps-Rollen und Verantwortlichkeiten, die Freigabe Guardrails und Freigabeschwellen.
Was es für Ihre Kosten bedeutet
Das Portfolio wird in einem festen Takt geprüft, mit Abdeckung und Auslastung als Eingang:
| Befund | Entscheidung |
|---|---|
| Auslastung hoch, Abdeckung niedrig, Nutzung stabil | nächste Tranche prüfen |
| Auslastung sinkt | nichts zukaufen; Ursache klären, Geltungsbereich erweitern oder tauschen, wo erlaubt |
| Migration oder Familienwechsel geplant | flexiblen Typ wählen, spezifischen Teil nicht verlängern |
| Tranche läuft bald aus | Basis neu bewerten, dann verlängern, verkleinern oder auslaufen lassen |
| Nutzung wächst über die Basis | warten, bis aus dem Wachstum eine stabile Basis geworden ist |
Das Ergebnis misst die effektive Sparquote, die Abdeckung, Auslastung und Rabatttiefe in einer Zahl verbindet. Ein Portfolio, das nur auf Abdeckung zielt, kann über schwache Auslastung verlieren, was es über den Rabatt gewinnt. Vorauszahlung und monatliche Zahlung verteilen sich unterschiedlich auf berechnete und effektive Kosten, wie Listen-, berechnete, effektive, amortisierte Kosten zeigt; wie eine Vorauszahlung bilanziert wird, entscheiden Steuerberater oder Wirtschaftsprüfer.
Wo es schiefgeht
- Alles läuft gleichzeitig aus. Symptom: In einem Monat steigen die Kosten unveränderter Workloads auf On-Demand-Niveau, oder eine große Verlängerung muss in Tagen entschieden werden. Ursache: Die Basis wurde mit einem Kauf gedeckt, und es gibt nur ein Enddatum.
- Empfehlung direkt nach dem Kauf. Symptom: Kurz nach einem Kauf empfiehlt das Werkzeug noch einmal fast dieselbe Zusage. Ursache: Die Empfehlung hat den Kauf noch nicht erfasst; Azure senkt sie für denselben Geltungsbereich am Kauftag, braucht für andere Bereiche aber bis zu 25 Tage, und AWS verlangt nach Kauf, Rückgabe oder Ablauf eine Aktualisierung und berücksichtigt vorgemerkte Käufe nicht.
- Zwei Empfehlungen für dieselbe Nutzung. Symptom: Ein Savings Plan bleibt teilweise ungenutzt. Ursache: Compute- und EC2-Instance-Empfehlung oder Reservierung und Savings Plan wurden für dieselbe Nutzung gekauft.
- Kauf ohne Verantwortlichen. Symptom: Niemand weiß, wer über die Verlängerung entscheidet. Ursache: Das Register führt keinen Verantwortlichen, und die Voreinstellung der Verlängerung entscheidet allein.
Beispiel
Die Basis ist eine Zusage B, als Stundenbetrag oder Menge. Statt B an einem Tag zu kaufen, kauft das Unternehmen zu Beginn jedes Quartals B/4, jeweils mit derselben Laufzeit T.
| Quartal im ersten Jahr | Gedeckter Teil der Basis |
|---|---|
| 1 | B/4 |
| 2 | B/2 |
| 3 | 3B/4 |
| 4 | B |
Im ersten Jahr ist im Mittel 5/8 der Basis gedeckt statt der ganzen; das ist der Preis der Staffelung, ein Teil des Rabatts im ersten Jahr. Dafür läuft nach Ablauf von T in jedem Quartal genau eine Tranche von B/4 aus, und jede Verlängerung ist eine Entscheidung über B/4 mit den Nutzungsdaten von dann. Sinkt die Basis, schrumpft das Portfolio mit jeder auslaufenden Tranche um ein Viertel, statt bis zum Ende einer einzigen Laufzeit überdeckt zu bleiben.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Rate Optimization (CC BY 4.0); Microsoft Rate optimization im FinOps Framework und Empfehlungen für Savings Plans; AWS Berechnung der Savings-Plans-Empfehlungen, CUR 2.0 Reservierungsspalten und Savings-Plans-Spalten; Google Cloud Empfehlungen für Committed Use Discounts.