Glossar
Savings Plans
Auch: Reserved Instances · Commitments · Reserved Capacity
Zwei Wege, für eine Nutzungszusage über ein oder drei Jahre deutlich weniger zu zahlen als für Rechenleistung auf Zuruf.
Die Mechanik ist überall dieselbe: Preisnachlass gegen Bindung. Man sagt AWS zu, eine bestimmte Menge über ein oder drei Jahre zu bezahlen, und bekommt dafür je nach Laufzeit und Vorauszahlung zwischen etwa 20 und 70 Prozent Rabatt. Genutzt oder nicht, bezahlt wird.
Die Begrifflichkeit geht regelmäßig durcheinander. Savings Plans gibt es nur für Rechenleistung, also EC2, Fargate und Lambda. Bei RDS heißen Commitments Reserved Instances, bei DynamoDB Reserved Capacity, bei ElastiCache und OpenSearch wieder Reserved Nodes. Wer „wir haben Savings Plans" sagt, meint oft nur die Rechenlast und hat die Datenbanken nicht abgedeckt.
Compute Savings Plans sind flexibler als EC2 Instance Savings Plans: Sie gelten über Instanztypen, Regionen und sogar über EC2, Fargate und Lambda hinweg, zu einem etwas geringeren Rabatt. In einer Umgebung, die sich noch bewegt, ist diese Flexibilität mehr wert als die letzten Prozentpunkte.
Die wichtigste Regel ist die Reihenfolge: Commitments kommen zuletzt. Wer sich auf eine unbereinigte Infrastruktur festlegt, zementiert die Verschwendung und macht jede spätere Optimierung wirtschaftlich sinnlos, weil die verkleinerte Datenbank nichts mehr spart, wenn die alte Größe längst bezahlt ist.
Die zweite Regel betrifft die Höhe. Sinnvoll sind 70 bis 80 Prozent der nachgewiesenen Grundlast, nie 100 Prozent. Der Rest bleibt flexibel. Ein zu großes Commitment ist die einzige Kostenmaßnahme, die sich nicht rückgängig machen lässt.
Und die dritte betrifft die Laufzeit. Drei Jahre bringen deutlich mehr Rabatt und sind eine Wette darauf, dass sich an der Architektur nichts Wesentliches ändert. Nach einem Umbau, vor einer Migration oder in einem wachsenden Produkt ist ein Jahr die ehrlichere Annahme.
Woran Sie es erkennen
- Es gibt Commitments, aber niemand hat vorher aufgeräumt.
- Die Datenbanken laufen ohne Reservierung, während für die Rechenlast ein Savings Plan besteht.
- Die Abdeckung liegt bei nahezu 100 Prozent der Nutzung.
- Die Laufzeit ist drei Jahre, obwohl die Architektur sich gerade ändert.
Nicht zu verwechseln mit
- Spot-Instances
- Rabatt gegen Unterbrechbarkeit statt gegen Bindung. Kein Vertrag, aber die Kapazität kann mit zwei Minuten Vorlauf entzogen werden. Für Batch-Lasten oft die günstigere Wahl.
- Rightsizing
- Verändert, wie viel Kapazität gebraucht wird. Commitments verändern nur den Preis dafür. Beides zusammen in dieser Reihenfolge, nie umgekehrt.
- Reserved Instances
- Der ältere Mechanismus, für RDS, ElastiCache und ähnliche Dienste weiterhin der einzige. Weniger flexibel als Savings Plans, aber dort ohne Alternative.
Wann es trägt
- Die Grundlast ist über mindestens drei Monate stabil und nachgewiesen.
- Aufräumen, Datenmengen und Rightsizing sind abgeschlossen.
- Die Architektur der betroffenen Komponenten steht nicht zur Debatte.
Wann nicht
- Als erster Schritt einer Kostensenkung. Das ist der häufigste und teuerste Fehler.
- Auf Lastspitzen. Committet wird die Grundlast, nicht das Maximum.
- Vor oder während einer Migration, solange die Zielarchitektur nicht steht.
- Über drei Jahre in einem Produkt, das sich noch stark verändert.
Wie man rangeht
- Grundlast bestimmenAus dem Cost and Usage Report die dauerhaft belegte Kapazität über mindestens drei Monate ablesen, nach der Bereinigung. Nicht der Durchschnitt zählt, sondern das Niveau, das nie unterschritten wird.
- Auf 70 bis 80 Prozent davon committenDer Rest bleibt zum vollen Preis und damit flexibel. Diese Reserve ist der Preis dafür, dass eine Architekturänderung später nicht bestraft wird.
- Alle Dienste abdecken, nicht nur RechenleistungReserved Instances für die Datenbanken, Reserved Capacity für DynamoDB, Compute Savings Plan für die Rechenlast. Wer nur Letzteres kauft, lässt den größeren Teil liegen.
- Ein Jahr wählen, wenn Zweifel bestehenDer zusätzliche Rabatt der Dreijahresbindung ist eine Wette auf Stabilität. Nach einem Umbau ist diese Wette selten gerechtfertigt.
- Erfolg amortisiert messenNach dem Kauf fällt die betroffene Zeile in der unblended-Sicht auf einen Bruchteil. Nur die amortisierte Sicht zeigt die echten laufenden Kosten.
Häufig gefragt
Savings Plan oder Reserved Instance?
Für Rechenleistung fast immer der Compute Savings Plan: Er gilt über Instanztypen, Regionen sowie EC2, Fargate und Lambda hinweg. Für RDS, ElastiCache, OpenSearch und DynamoDB gibt es keine Savings Plans, dort sind Reserved Instances beziehungsweise Reserved Capacity der einzige Weg.
Ein Jahr oder drei Jahre?
Drei Jahre bringen spürbar mehr Rabatt und sind eine Wette darauf, dass sich an der Architektur nichts Wesentliches ändert. In einer Umgebung, die gerade umgebaut oder migriert wird, ist ein Jahr die ehrlichere Annahme. In einer seit Jahren stabilen Plattform sind drei Jahre vertretbar.
Was passiert, wenn wir die zugesagte Menge nicht nutzen?
Sie wird trotzdem berechnet. Genau deshalb gilt die Obergrenze von 70 bis 80 Prozent der nachgewiesenen Grundlast. Nicht genutzte Zusagen sind der einzige Fall, in dem eine Kostenmaßnahme die Kosten erhöht.
Lässt sich ein Commitment rückgängig machen?
Nein. Reserved Instances lassen sich in engen Grenzen anpassen oder auf dem Marketplace verkaufen, Savings Plans nicht. Das ist der Grund, warum sie ans Ende der Reihenfolge gehören und nicht an den Anfang.