AWS Savings Plans vs Reserved Instances: Welches wann
Commitment-Rabatte sind der größte einzelne Hebel an einer AWS-Rechnung — 30–60% unter On-Demand-Preisen für Workloads, die Sie ohnehin betreiben würden. Sie sind zugleich die einfachste Stelle, einen Fehler für ein oder drei Jahre festzuschreiben. Die Frage „Savings Plans vs Reserved Instances“ taucht in fast jedem Kosten-Review auf, das wir durchführen, und die ehrliche Antwort lautet: Die meisten Teams brauchen beides, weil sie unterschiedliche Services abdecken. Hier ist der Entscheidungsrahmen, den wir mit Kunden verwenden.
Die beiden Mechanismen im Überblick
| Savings Plans | Reserved Instances | |
|---|---|---|
| Worauf Sie sich festlegen | $/Stunde Compute-Ausgaben | Eine bestimmte Instanzkonfiguration |
| Deckt ab | EC2, Fargate, Lambda (Compute SP); SageMaker hat einen eigenen SP | EC2, RDS, ElastiCache, OpenSearch, Redshift (als Reserved Nodes/Instances) |
| Flexibilität | Hoch — gilt über Familie, Größe, OS und Region hinweg (Compute SP) | Geringer — an Instanzattribute gebunden; Convertible RIs lassen sich tauschen |
| Typischer Rabatt | Bis zu ~72% (EC2 Instance SP, 3 Jahre) / ~66% (Compute SP, 3 Jahre) | Bis zu ~60–70% je nach Service und Laufzeit |
| Laufzeit / Zahlung | 1 oder 3 Jahre; No/Partial/All Upfront | 1 oder 3 Jahre; No/Partial/All Upfront |
| Weiterverkauf bei Planänderung | Nein | Standard EC2 RIs lassen sich auf dem RI Marketplace verkaufen |
Die Faustregel
- Compute (EC2/Fargate/Lambda): Savings Plans verwenden. Sie haben EC2 RIs als Standard abgelöst, weil sie Architekturänderungen überstehen — Instanzfamilie wechseln, einen Workload nach Fargate verschieben, Graviton einführen: Der Rabatt folgt Ihren Ausgaben.
- Datenbanken und Analytics (RDS, ElastiCache, OpenSearch, Redshift): Reserved Instances / Reserved Nodes verwenden. Das ist die Lücke, die Teams übersehen: Savings Plans decken RDS nicht ab. Ist Ihre Rechnung datenbanklastig — und das sind die meisten — lässt eine reine SP-Strategie Ihren größten Posten zu On-Demand-Preisen laufen.
- DynamoDB: hat einen eigenen Reserved-Capacity-Mechanismus, unabhängig von beiden.
Compute SP vs EC2 Instance SP
Innerhalb der Savings Plans gibt es eine zweite Entscheidung. Compute Savings Plans gelten für jedes Compute überall — jede Familie, Größe, Region, jedes OS, dazu Fargate und Lambda — bei etwas geringerem Rabatt. EC2 Instance Savings Plans zahlen mehr (Sätze vergleichbar mit Standard RIs), binden Sie aber an eine Instanzfamilie in einer Region. Unser Standard: Compute SP für den Großteil des Commitments, EC2 Instance SP nur für Workloads, bei denen Sie sicher sind, dass sie die gesamte Laufzeit auf derselben Familie bleiben (große, stabile Steady-State-Flotten). Wenn Sie eine Graviton-Migration oder einen Containerisierungsschub erwarten, bleiben Sie beim Compute SP — Flexibilität ist mehr wert als die zusätzlichen Rabattpunkte.
Standard vs Convertible RIs
Bei den Services, für die RIs die einzige Option sind, wiederholt sich der Trade-off: Standard RIs rabattieren stärker und lassen sich auf dem Marketplace weiterverkaufen (nur EC2); Convertible RIs rabattieren weniger, lassen sich aber während der Laufzeit gegen andere Konfigurationen tauschen. Für RDS, wo Engine- und Größenwechsel häufig sind, schlagen kürzere Laufzeiten oder konservatives Sizing aggressive Dreijahres-All-Upfront-Wetten.
So bemessen Sie das Commitment
- 1. Erst Right-Sizing, dann Commitment. Ein Commitment auf eine überdimensionierte Flotte schreibt die Verschwendung für die Laufzeit fest. Erst aufräumen — unser Leitfaden zur Kostensenkung beschreibt die Reihenfolge.
- 2. Auf die stabile Grundlast committen, nicht auf die Spitze. Betrachten Sie 30–90 Tage Nutzung im Cost Explorer; committen Sie rund 70–80% des stabilen Sockels und lassen Sie Spitzen On-Demand oder auf Spot laufen. Zu wenig Commitment kostet Sie ein paar Rabattpunkte; zu viel ist Geld, das jede Stunde verbrennt.
- 3. Staffeln Sie Ihre Commitments. Statt eines großen 3-Jahres-Kaufs kaufen Sie jedes Quartal in Tranchen. So mitteln Sie Prognosefehler aus und haben bei Planänderungen immer Tranchen, die bald auslaufen.
- 4. Beobachten Sie monatlich zwei Zahlen: Utilization (nutzen Sie, was Sie gekauft haben?) und Coverage (wie viel berechtigte Nutzung läuft noch On-Demand?). Beide finden Sie in den Savings-Plans-/RI-Reports des Cost Explorer. Utilization unter ~95% heißt, Sie haben zu viel gekauft; Coverage unter ~70% bei einem stabilen Workload heißt, Sie lassen Geld liegen.
Die Fehler, die wir in Audits immer wieder finden
- Reine SP-Strategien bei RDS-lastigen Rechnungen — der Datenbankposten bleibt still zum vollen Preis.
- Commitment vor dem Right-Sizing — ein Dreijahresrabatt auf doppelt so große Instanzen wie nötig ist immer noch Verschwendung.
- Abgelaufen und vergessen — RIs und SPs laufen still aus; die Nutzung fällt auf On-Demand zurück, und niemand merkt es, bis die Rechnung springt. Richten Sie Ablauf-Alerts ein.
- All Upfront bei unsicheren Workloads — No Upfront kostet nur geringfügig mehr und hält Cash und Optionen offen.
- Niemand verantwortet die Zahl — Coverage und Utilization prüft keiner, einmal gekauft, nie wieder angefasst. Commitment-Management ist eine Quartalsroutine, keine einmalige Aktion.
Häufige Fragen
Decken Savings Plans RDS ab?
Nein. Savings Plans decken EC2, Fargate und Lambda ab (plus einen separaten SageMaker-Plan). RDS, ElastiCache, OpenSearch und Redshift brauchen Reserved Instances / Reserved Nodes.
Was spart mehr, Savings Plans oder Reserved Instances?
Bei gleicher Laufzeit und Zahlung sind EC2 Instance SPs und Standard RIs vergleichbar; Compute SPs rabattieren etwas weniger, dafür mit deutlich mehr Flexibilität. Der größere Unterschied bei den Einsparungen kommt aus Sizing- und Coverage-Disziplin, nicht aus dem Mechanismus.
Kann ich ein ungenutztes Commitment verkaufen?
Nur Standard EC2 Reserved Instances lassen sich auf dem RI Marketplace weiterverkaufen. Savings Plans und Convertible RIs sind nicht verkäuflich — ein weiterer Grund, konservativ zu dimensionieren.
1 Jahr oder 3 Jahre?
Dreijahreslaufzeiten rabattieren deutlich stärker, aber committen Sie sich nur bei Workloads mit nachweislich stabiler Grundlast so weit. Ein gängiges Muster: 3-Jahres-Commitments für den bewährten Sockel, 1-Jahres-Tranchen für den Rest.
Fazit
Savings Plans für Compute, Reserved Instances für Datenbanken, bemessen an der Grundlast nach dem Aufräumen, in Tranchen gekauft, quartalsweise geprüft. Dieser eine Satz ist der Großteil der Commitment-Strategie — der Rest ist die Disziplin, das Aufräumen tatsächlich zuerst zu erledigen und die zwei Zahlen monatlich im Blick zu behalten.
Sie wollen das Commitment anhand Ihrer tatsächlichen Rechnung durchgerechnet? Unser AWS-Kostenoptimierungs-Audit (Festpreis €5.000, angerechnet, wenn Sie in ein Projekt übergehen) quantifiziert Ihre Verschwendung pro Befund und liefert einen dimensionierten, gestaffelten Commitment-Plan — mit der Option, aus den Einsparungen zu bezahlen.