Cloud-Commitment-Rabatte sind niedrigere Preise im Tausch gegen die Zusage, ein oder drei Jahre lang eine Menge Ressourcen zu nutzen oder einen Betrag je Stunde auszugeben, und alle drei Anbieter bieten sie in zwei Familien an: mengenbasiert auf eine Konfiguration und ausgabenbasiert auf einen Betrag. Der Typ legt fest, was die Zusage bindet, eine Instanzfamilie, eine Region, einen Dienst oder nur Geld, und damit, was eine Änderung an der Infrastruktur mit dem Rabatt macht. Für die Rechnung heißt das: Je enger ein Typ bindet, desto höher ist in der Regel der Rabatt, den der Anbieter nennt, und desto eher läuft nach einer Änderung eine Gebühr ohne passende Nutzung weiter.
So funktioniert es
Zwei Familien
FOCUS unterscheidet in der Spalte CommitmentDiscountCategory zwischen Usage, einer zugesagten Menge, und Spend, einem zugesagten Betrag. Mengenbasiert sind Reserved Instances bei AWS, Reservierungen bei Azure und ressourcenbasierte Committed Use Discounts bei Google. Ausgabenbasiert sind Savings Plans bei AWS und Azure und die ausgabenbasierten CUDs bei Google, als Compute Flexible Commitment, je Dienst oder als Flexible Savings Plan mit monatlichem statt stündlichem Fenster. Die FinOps Foundation trennt in der Capability Rate Optimization dieselben zwei Formen und hält fest, dass der Rabatt mit der Einschränkung wächst; die Begriffe ordnet Die vier Domains und ihre Capabilities ein.
Vergleich
| Programm | Bindet | Laufzeit und Zahlung | Flexibilität | Ausstieg | Kapazität |
|---|---|---|---|---|---|
| AWS Reserved Instances | Instanztyp, Region, Plattform, Tenancy | 1 oder 3 Jahre; All, Partial oder No Upfront | Größe innerhalb der Familie bei regionalen Linux-RIs; Convertible tauschbar | Standard verkaufbar, Convertible tauschbar | nur zonale RIs |
| AWS Savings Plans | USD je Stunde; EC2 Instance zusätzlich Familie und Region | 1 oder 3 Jahre; drei Zahlungsoptionen; Database nur 1 Jahr ohne Vorauszahlung | Compute: Familie, Größe, Region, Betriebssystem, Fargate, Lambda | Rückgabe nur in engen Grenzen | nein |
| Azure-Reservierungen | Produkt, Region, Geltungsbereich | 1 oder 3 Jahre; vorab oder monatlich | Instanzgrößenflexibilität; Geltungsbereich änderbar | Tausch und Rückgabe mit Grenzen | nein, dafür eigene Capacity Reservations |
| Azure Savings Plans | Betrag je Stunde | 1 oder 3 Jahre; vorab oder monatlich | Dienste und Regionen im Geltungsbereich | keiner | nein |
| Google ressourcenbasierte CUDs | vCPU, Speicher, GPU, Local SSD einer Maschinenserie, Region, Projekt | 1 oder 3 Jahre, verlängerbar; monatliche Gebühr | CUD-Sharing über Projekte; Merge, Split, Upgrade | keiner | nur mit angehängter Reservierung |
| Google ausgabenbasierte CUDs | Betrag je Stunde, beim Flexible Savings Plan je Monat | 1 oder 3 Jahre; monatliche Gebühr | Projekte, je nach Dienst alle Regionen | keiner | nein |
Die Obergrenzen, die die Anbieter am 2026-10-16 nennen: AWS bis zu 72 % für Standard RIs und EC2 Instance Savings Plans, 66 % für Convertible RIs und Compute Savings Plans, 35 % für Database Savings Plans; Azure bis zu 72 % für Reservierungen und 65 % für den Savings Plan für Compute; Google bis zu 55 % für ressourcenbasierte Hardware-Commitments, 70 % bei speicheroptimierten Serien, und für Compute Flexible Commitments auf Allzweckserien wie E2, N2 und C4 28 % für ein und 46 % für drei Jahre.
Reihenfolge der Anwendung
Wo beide Familien dieselbe Nutzung decken könnten, gilt eine feste Reihenfolge. AWS wendet zuerst Reserved Instances an, dann Savings Plans, EC2 Instance vor Compute. Azure wendet Reservierungen vor Savings Plans an, und unter Savings Plans dreijährige und enger gefasste zuerst. Google verbraucht zuerst ressourcenbasierte, dann Compute Flexible Commitments; dienstspezifische Zusagen gehen dem Compute Flexible Commitment vor. Die breitere Zusage sieht also nur, was die engere übrig lässt.
Die Fragen, die die Anbieter nennen
Microsofts Seite zur Wahl zwischen Savings Plan und Reservierung stellt Reservierungen auf Workloads ab, die durchgehend laufen und bei denen keine Änderung von Instanztyp, Familie oder Region absehbar ist, und Savings Plans auf Workloads, die über Familien, Dienste oder Regionen wandern. Sie nennt außerdem eine Reihenfolge: zuerst Rightsizing, dann Tausch oder Umwandlung schlecht genutzter Reservierungen, erst danach neue Zusagen. Die AWS-FAQ stellt bei Datenbanken die Flexibilität zwischen Diensten und Instanztypen gegen stabile Workloads auf bestimmten Instanztypen und dreijährige Laufzeiten. Google ordnet ressourcenbasierte CUDs gleichmäßiger Nutzung in einem Projekt, einer Region und einer Konfiguration zu und Compute Flexible Commitments Nutzung, die nicht daran gebunden ist. Daraus ergeben sich vier Fragen: wie stabil Typ, Familie und Region sind, über wie viele Dienste sich die Nutzung verteilt, ob der Rabatt einer geplanten Migration folgen muss und welche Zusagen schon vorher greifen. Wie viel und wann gekauft wird, behandelt das Kapitel Optimierung und Einsparungen.
Was es für Ihre Kosten bedeutet
In den Abrechnungsdaten erscheinen beide Familien als Gebühr oder Kauf und als gedeckte Nutzung. Mengenbasierte Zusagen lassen sich in Stunden oder normalisierten Einheiten auswerten, ausgabenbasierte nur in Geld; Abdeckung und Auslastung beschreibt Commitment-Abdeckung und Auslastung.
Auch die Preisbindung unterscheidet sich. AWS hält die Sätze eines Savings Plan über die Laufzeit gleich. Google rechnet die Gebühr einer ausgabenbasierten Zusage mit dem Listenpreis am Kauftag, die einer ressourcenbasierten mit dem On-Demand-Preis, der an dem Tag gilt, an dem sie aktiv wird, also am Tag nach dem Kauf; spätere Preisänderungen wirken sich auf keine der beiden aus. Bei Azure Savings Plans dagegen gelten laut Microsoft jeweils die aktuellen Savings-Plan-Preise, Änderungen wirken zum Monatsersten. Was ein Ausstieg kostet und wann er möglich ist, steht unter Tausch, Kündigung und Ablauf. Für Last, die Unterbrechungen verträgt, ist Spot-Kapazität ein weiterer Hebel auf den Preis, ohne Laufzeit.
Wo es schiefgeht
- Typ nach dem höchsten Rabatt gewählt. Symptom: Nach einem Wechsel der Instanzfamilie oder Region läuft die Gebühr weiter, und die neue Nutzung zahlt On-Demand. Ursache: Der höhere Rabatt bindet mehr Attribute, und ohne Tauschrecht bleibt die Zusage an der alten Konfiguration.
- Zwei Familien auf derselben Nutzung. Symptom: Ein Savings Plan bleibt teilweise ungenutzt, obwohl genug berechtigte Nutzung läuft. Ursache: Reservierungen und ressourcenbasierte CUDs greifen zuerst, der Plan sieht nur den Rest.
- Compute-Zusage für Datenbanken erwartet. Symptom: Ein Compute Savings Plan senkt die RDS- oder SQL-Rechnung nicht. Ursache: Datenbanken haben bei AWS und Azure eigene Programme, beschrieben unter Reservierte Kapazität.
- Tauschrecht als dauerhaft angenommen. Symptom: Eine ab dem 2027-02-01 gekaufte Azure-Reservierung für virtuelle Maschinen lässt sich nicht tauschen. Ursache: Für Dienste, die Savings Plans abdecken, schließt Microsoft den Tausch solcher Reservierungen aus.
- Einjährige Flex-Zusage auf M-Serien. Symptom: Ein Compute Flexible Commitment wird bei Google verbraucht, ohne dass ein Rabatt sichtbar ist. Ursache: Für speicheroptimierte VMs gibt es den Rabatt nur bei drei Jahren; ein einjähriges Commitment wird ohne Rabatt aufgebraucht.
Quellen
Gelesen am 2026-10-16. AWS Was sind Savings Plans?, Savings-Plans-Typen, Anwendung von Savings Plans auf die Nutzung, Savings Plans FAQ, Reserved Instances für Amazon EC2, Preise für EC2 Reserved Instances; Microsoft Zwischen Savings Plan und Reservierung wählen, Was sind Azure-Reservierungen?, Was sind Savings Plans?, Anwendung des Savings-Plan-Rabatts, Reserved VM Instances, Tausch und Rückgabe von Reservierungen; Google Cloud Committed Use Discounts, Committed Use Discounts für Compute Engine, Ressourcenbasierte Committed Use Discounts; FinOps Foundation Rate Optimization; FOCUS Column Library, Commitment Discount Category.