Eine Reserved-Instances-Kauf-Checkliste füllt der Cloud-Verantwortliche vor jedem Kauf eines Commitments aus, ob Reserved Instance, Savings Plan, Azure-Reservierung oder Committed Use Discount, und die freigebende Rolle unterschreibt sie; der Datensatz hält die Basislast, das Abdeckungsziel, Laufzeit und Zahlungsoption, die Tausch- und Rückgaberegeln des Programms, die Freigabe und den Review-Termin fest, ein Datensatz je Kauf. Die Entscheidung, die er festhält: kaufen, verkleinern, vertagen oder ablehnen, mit Begründung. Welches Programm zu welcher Last passt, erklärt Wahl zwischen Commitment-Typen; wie Käufe zu einer Strategie werden, Commitment-Strategie. Diese Seite ist der Datensatz.
Die Vorlage
Entscheidungsdatensatz Commitment-Kauf <ID>, Datum <Datum>, Antragsteller <Cloud-Verantwortlicher>, Freigabe <Rolle>
1. Gegenstand
| Feld | Wert |
|---|---|
| Provider und Programm | <AWS Compute Savings Plan, EC2 Instance Savings Plan, Standard oder Convertible Reserved Instance; Azure Reservierung oder Savings Plan; Google Cloud ressourcen- oder ausgabenbasierter CUD> |
| Umfang | <Betrag je Stunde, Anzahl Instanzen, vCPU und GB oder Betrag je Monat> |
| Geltungsbereich | <Konto oder Organisation>, <Region>, <Instanzfamilie, Betriebssystem, Tenancy> |
| Laufzeit | <1 oder 3 Jahre>, Beginn <Datum>, Ende <Datum> |
| Zahlungsoption | <alles im Voraus, teilweise im Voraus, monatlich> |
| Rabatt laut Provider | <Prozent gegen On-Demand, Preisliste vom Datum, Link> |
2. Basislast
| Kennzahl | Wert | Zeitraum | Quelle |
|---|---|---|---|
| Nutzung des Gegenstands je Stunde, Minimum | <Wert> | letzte <90> Tage | Export, Filter <Usage Type, Meter oder SKU> |
| Nutzung je Stunde, Mittel | <Wert> | letzte <90> Tage | Export |
| Davon schon durch Commitments gedeckt | <Prozent> | letzter Monat | Abdeckungsbericht |
| Auslastung der bestehenden Commitments | <Prozent> | letzter Monat | Abdeckungsbericht |
| Empfehlung des Providers | <Umfang, Betrag> | Parameter <Tage, Laufzeit, Zahlung> | <Cost Explorer, Azure Advisor, Recommender> |
| Geplante Änderungen, die die Last senken | <Rightsizing, ARM-Umstieg, Abschaltung, Enddatum eines Projekts> | innerhalb der Laufzeit | <Roadmap, Team-Lead> |
3. Rechnung
| Posten | Wert |
|---|---|
| Kosten des Commitments über die Laufzeit | <Betrag> |
| On-Demand-Kosten derselben Nutzung | <Betrag> |
| Einsparung über die Laufzeit | <Betrag>, <Prozent> |
| Break-even-Auslastung | <Prozent der Stunden, ab der das Commitment günstiger ist als On-Demand> |
Ungenutzter Betrag bei <20> Prozent weniger Last | <Betrag je Monat> |
| Abdeckung nach dem Kauf | <Prozent>, Ziel <Prozent> |
4. Regeln des Programms
| Regel | Für diesen Kauf |
|---|---|
| Änderung oder Tausch während der Laufzeit | <laut Provider: möglich, eingeschränkt, nicht möglich> |
| Kündigung oder Rückgabe | <laut Provider: nicht möglich, bis Betrag je Jahr, über einen Marktplatz> |
| Flexibilität bei Größe, Familie, Region | <laut Provider> |
| Teilung über Konten oder Subscriptions | <Geltungsbereich geteilt: ja oder nein> |
| Automatische Verlängerung | <an, aus>, geprüft am <Datum> |
| Erscheint in den Abrechnungsdaten als | <Spalten oder Meter, in denen die Gebühr und die Deckung stehen> |
5. Freigabe und Review
| Feld | Wert |
|---|---|
| Freigabe durch | <Rolle laut RACI; ab Betrag Laufzeitwert Management> |
| Entscheidung | <kaufen, verkleinern auf Umfang, vertagen bis Datum, ablehnen>, Begründung <Text> |
| Budgetzeile | <Blatt 3 des Budgets, Zeile> |
| Review der Auslastung | <30> Tage nach Kauf, danach monatlich, Verantwortlich <Rolle> |
| Erinnerung vor Ablauf | <90> Tage vor <Enddatum>, an <Rolle> |
Checkliste vor der Unterschrift
- Basislast aus mindestens
<90>Tagen, nicht aus der letzten Woche oder einem Lastspitzen-Monat - Umfang unter dem Minimum der Basislast, nicht unter dem Mittel
- Bestehende Commitments mit Auslastung unter
<Prozent>zuerst erklärt oder getauscht - Geplante Änderungen innerhalb der Laufzeit mit den Team-Leads geprüft
- Instanzgeneration aktuell; kein Wechsel der Familie oder auf ARM geplant
- Zahlungsoption mit Finance abgestimmt: Liquidität und Buchung der Vorauszahlung
- Geltungsbereich auf die Organisation gesetzt, wo mehrere Konten die Deckung nutzen sollen
- Review-Termin und Ablauf-Erinnerung eingetragen, Datensatz im Budget verlinkt
So füllen Sie sie aus
Gegenstand: Umfang in der Einheit, die der Provider abrechnet, Betrag je Stunde bei Savings Plans und ausgabenbasierten CUDs, Instanzen bei Reservierungen; die Programme je Provider stehen in AWS Reserved Instances, AWS Savings Plans, Azure-Reservierungen, Azure Savings Plans und Committed Use Discounts.
Basislast: Das Minimum je Stunde ist die Zahl, die das Commitment nicht überschreiten darf; das Mittel zeigt, was On-Demand bleibt. Die Empfehlung des Providers hat Parameter, die Sie notieren, weil sie das Ergebnis bestimmen. Rechnung: Die Break-even-Auslastung folgt aus Rabatt und Zahlungsoption; wie Abdeckung und Auslastung gemessen werden, steht in Commitment-Abdeckung und -Auslastung.
Regeln: Jede Zeile aus der aktuellen Dokumentation des Providers, mit Datum, weil sich Tausch- und Rückgaberegeln ändern; den Stand je Programm fasst Tausch, Kündigung und Ablauf von Commitments zusammen. Wie die Gebühr in den Exporten erscheint, zeigt Listen-, Rechnungs-, effektive und amortisierte Kosten.
Freigabe: Die Schwelle, ab der das Management unterschreibt, steht im RACI; die Budgetzeile in der Budget-Vorlage.
So passen Sie sie an
Ein Team: Antragsteller und Verursacher sind dieselben; Abschnitt 2 wird mit dem Team-Lead gemeinsam ausgefüllt. Mehrere Teams: Die Deckung wird auf Organisationsebene gekauft, und Abschnitt 2 summiert die Basislast über die Konten, mit einer Zeile je Team, deren Enddaten geprüft sind.
Ein Provider: Abschnitt 4 trägt die Regeln einmal und wird bei jedem Kauf nur datiert. Drei Provider: Ein Datensatz je Provider und Programm, weil Tausch, Rückgabe und Flexibilität sich unterscheiden; die Abdeckung wird je Provider gemessen.
Startup: Nur Laufzeit ein Jahr, monatliche Zahlung und ein Umfang unter der Hälfte des Minimums, bis zwei Quartale Basislast vorliegen. Finance-geführt: Zahlungsoption und Buchung mit Finance vor der Rechnung in Abschnitt 3 abstimmen, und der Datensatz wird mit der Rechnung des Providers abgelegt.
Quellen
Gelesen am 2026-10-21. FinOps Foundation, Rate Optimization (CC BY 4.0), Was sind Savings Plans?, Berechnung der Savings-Plans-Empfehlungen, Reserved Instances für Amazon EC2, Savings Plan oder Reservierung in Azure, Tausch und Rückgabe von Azure-Reservierungen, Empfehlungen für Azure Savings Plans, Committed Use Discounts, Empfehlungen für Committed Use Discounts.