AWS Savings Plans vs Reserved Instances…

Aktualisiert: 17. Juni 2026

AWS Savings Plans sind 2026 für die meisten Workloads die bessere Wahl als Reserved Instances, weil sie sich über Instanzfamilie, Größe und Region frei austauschen lassen und denselben Maximalrabatt von bis zu 72 % bieten wie Standard-RIs. Reserved Instances lohnen sich nur noch in zwei Nischen: bei RDS, ElastiCache, Redshift und OpenSearch (für die es keine Savings Plans gibt) und beim Verkauf über den RI-Marketplace, falls sich Pläne ändern. Wer 2026 EC2-, Fargate- oder Lambda-Workloads commitet, sollte fast immer zu Compute Savings Plans greifen.

Compute Savings Plans geben bis zu 66 % Rabatt auf On-Demand-Preise und decken EC2, Fargate und Lambda über alle Regionen und Instanzfamilien hinweg ab.
EC2 Instance Savings Plans gehen bis 72 %, sind aber an eine Instanzfamilie und Region gebunden, also nur sinnvoll bei sehr stabilen Workloads.
Standard Reserved Instances bieten denselben 72-%-Rabatt, sind aber nur über den RI-Marketplace handelbar. Savings Plans lassen sich nicht verkaufen.
Für RDS, ElastiCache, OpenSearch und Redshift gibt es weiterhin nur Reserved Instances. Savings Plans decken diese Dienste 2026 nicht ab.
Die optimale Coverage-Quote liegt bei 70–85 % der Baseline-Utilization; alles darüber führt zu ungenutzten Commitments und negativem ROI.
3-Jahres-All-Upfront liefert den höchsten Rabatt, aber der Break-Even gegenüber 1-Jahres-No-Upfront liegt erst bei rund 18 Monaten konstanter Nutzung.

Was ist der Unterschied zwischen Savings Plans und Reserved Instances?

Savings Plans und Reserved Instances sind beide Rabattmechanismen, bei denen Sie sich für ein oder drei Jahre auf eine bestimmte Ausgabenhöhe oder Instanzkonfiguration festlegen. Im Tausch dafür gibt es einen Preisnachlass von bis zu 72 %. Der Unterschied liegt darin, worauf Sie sich eigentlich festlegen.

Ein Savings Plan ist ein Commitment auf einen stündlichen Dollar-Betrag, also zum Beispiel "ich gebe die nächsten 12 Monate mindestens 12,50 US-Dollar pro Stunde für Compute aus". Solange Sie diesen Betrag verbrauchen, gilt der Rabatt. Es spielt keine Rolle, ob die Last auf einer m6i.large in eu-central-1 oder einer c7g.xlarge in us-east-1 läuft. Bei Compute Savings Plans gilt das sogar dienstübergreifend für EC2, Fargate und Lambda.

Eine Reserved Instance ist dagegen ein Commitment auf eine konkrete Instanzkonfiguration: Familie (zum Beispiel m6i), Größe, Betriebssystem, Region und je nach Typ auch Availability Zone. Wechseln Sie die Familie oder ziehen die Region um, ist die Reservierung verloren. Sie müsste dann umständlich konvertiert oder auf dem RI-Marketplace verkauft werden.

Ehrlich gesagt, in drei von vier FinOps-Audits, die ich begleite, finde ich noch alte Standard-RIs, die nach einer Migration auf Graviton oder einem Cluster-Umzug brachliegen. Genau dieses Risiko adressiert AWS mit Savings Plans seit 2019, und 2026 ist das Produkt so ausgereift, dass es für die meisten Compute-Workloads die Standardantwort ist. Wer tiefer in die Mechanik einsteigen will, findet die Details in den offiziellen AWS Savings Plans Docs.

Savings Plans vs. Reserved Instances im direkten Vergleich

Die folgende Tabelle fasst die entscheidenden Dimensionen zusammen, an denen sich ein Commitment-Kauf 2026 ausrichten sollte. Achten Sie besonders auf die Zeilen "Flexibilität" und "Verkaufbarkeit". Dort liegen die teuersten Fehlentscheidungen.

Kriterium	Compute Savings Plan	EC2 Instance Savings Plan	Standard Reserved Instance	Convertible Reserved Instance
Maximaler Rabatt	bis 66 %	bis 72 %	bis 72 %	bis 66 %
Laufzeit	1 oder 3 Jahre	1 oder 3 Jahre	1 oder 3 Jahre	1 oder 3 Jahre
Abgedeckte Dienste	EC2, Fargate, Lambda	nur EC2	EC2, RDS, ElastiCache, OpenSearch, Redshift	nur EC2
Region wechselbar	Ja, automatisch	Nein	Nein	Per Exchange
Instanzfamilie wechselbar	Ja, automatisch	Nur Größe innerhalb der Familie	Nur Größe (Linux/Unix)	Per Exchange
Verkaufbar	Nein	Nein	Ja (RI Marketplace)	Nein
Stornierung	Nicht möglich	Nicht möglich	Nicht möglich	Nicht möglich
Capacity Reservation	Nein	Nein	Zonal-RI ja	Zonal-RI ja

Wann sind Savings Plans die bessere Wahl?

Für etwa 90 % aller Workloads, mit denen ich in Audits zu tun habe, sind Compute Savings Plans der richtige Hebel. Konkret immer dann, wenn eines der folgenden Szenarien zutrifft: Sie planen eine Migration auf Graviton (m6i auf m7g), Sie betreiben EKS oder ECS mit dynamischer Skalierung, Sie nutzen Lambda oder Fargate für signifikante Anteile, oder Ihre Workloads laufen über mehrere Regionen verteilt. In allen vier Fällen würden Sie mit Standard-RIs entweder die Flexibilität verlieren oder den Rabatt nach einem Umzug verschenken.

Ein konkreter Fall aus 2025: Ein Kunde hatte 3-Jahres-Standard-RIs auf m5.4xlarge in eu-west-1 für rund 480.000 US-Dollar gekauft. Sechs Monate später hat das Plattform-Team auf Graviton-basierte m7g umgestellt, weil die Performance pro Dollar um 38 % besser war. Die RIs liefen für x86-m5 weiter, also effektiv Geld in den Wind geschrieben, weil nichts mehr darauf lief. Ein Compute Savings Plan über denselben Betrag hätte automatisch den neuen m7g-Verbrauch rabattiert.

Auch für Lambda-lastige Architekturen mit Provisioned Concurrency machen Compute Savings Plans Sinn. AWS rabattiert dort bis zu 17 % auf Duration und Provisioned Concurrency, was bei größeren Event-Driven-Workloads schnell fünfstellige Beträge pro Monat ausmacht. Wer seine serverlose Cost-Struktur noch nicht im Griff hat, findet im FinOps-Leitfaden für KI-Workloads ergänzende Strategien zu GPU- und Spot-Kombinationen.

Wann lohnen sich Reserved Instances noch?

Reserved Instances haben 2026 noch genau drei Anwendungsfälle, in denen sie Savings Plans überlegen sind. Erstens, und am wichtigsten: für AWS-Dienste außerhalb von Compute. Für Amazon RDS, ElastiCache, OpenSearch und Redshift gibt es schlicht keine Savings-Plan-Variante. Wer eine produktive PostgreSQL-Datenbank auf db.r6g.4xlarge für 24/7 betreibt, kann den vollen Rabatt nur über eine RDS Reserved Instance bekommen (typischerweise 30–60 % je nach Laufzeit und Payment Option).

Zweitens: für extrem stabile Workloads mit klarer Kapazitätsanforderung in einer bestimmten Availability Zone. Eine Zonal Reserved Instance reserviert nicht nur den Preis, sondern auch Compute-Kapazität. Das ist wichtig für Disaster-Recovery-Setups, in denen ein Failover-Cluster jederzeit anlauffähig sein muss. Savings Plans bieten diese Capacity-Garantie nicht.

Drittens: als Exit-Option. Standard-RIs sind das einzige Commitment-Modell, das Sie über den AWS RI Marketplace wieder verkaufen können. Wenn die Strategie Ihres Unternehmens noch nicht festliegt, etwa weil eine Multi-Cloud-Entscheidung ansteht, kann das den Restwert eines Fehlkaufs retten. Savings Plans hingegen sind in Stein gemeißelt: weder stornierbar noch handelbar. Diese Asymmetrie wird in den meisten FinOps-Reviews unterschätzt.

Wie hoch ist der Rabatt von Compute Savings Plans wirklich?

Die plakative Aussage "bis zu 66 %" ist marketingseitig korrekt, in der Praxis aber irreführend. Der tatsächliche Effektivrabatt eines Compute Savings Plans hängt von drei Variablen ab: Laufzeit, Payment Option und der Mischung an Instanztypen, die Sie tatsächlich verbrauchen. Die folgende Übersicht zeigt typische Effektivrabatte für gemischte EC2-Workloads in eu-central-1 (Frankfurt), Stand Juni 2026:

1 Jahr, No Upfront: 17–20 % gegenüber On-Demand
1 Jahr, Partial Upfront: 20–24 %
1 Jahr, All Upfront: 22–27 %
3 Jahre, No Upfront: 35–42 %
3 Jahre, Partial Upfront: 40–48 %
3 Jahre, All Upfront: 44–54 %

Die theoretischen 66 % erreichen Sie nur, wenn Sie auf einer einzigen, hochpreisigen Instanzfamilie wie p4d oder x2iezn drei Jahre All Upfront committen. Das ist der Edge Case, nicht der Normalfall. Für realistische Planung sollten Sie mit 35–45 % effektivem Rabatt rechnen, wenn Sie 3-Jahres-Commitments fahren, und mit 18–22 % bei 1-Jahres-Laufzeit. Der Break-Even-Punkt zwischen "1 Jahr No Upfront" und "3 Jahre All Upfront" liegt bei etwa 18–20 Monaten konstanter Nutzung. Wenn Sie unsicher sind, ob Ihr Architektur-Setup so lange überlebt, bleiben Sie bei 1 Jahr.

Coverage- und Commitment-Strategie für 2026

Die wichtigste FinOps-Kennzahl beim Commitment-Management ist die Coverage Ratio, also der Anteil Ihres On-Demand-Verbrauchs, der durch Savings Plans oder RIs rabattiert wird. Aus meiner Erfahrung in über zwanzig FinOps-Engagements liegt der Sweet Spot zwischen 70 % und 85 %. Darunter verschenken Sie Rabatt, darüber riskieren Sie ungenutzte Commitments. AWS verrechnet einen Savings Plan stundenweise, und jede Stunde, in der Ihr tatsächlicher Verbrauch unter dem committeten Dollar-Betrag liegt, ist verbranntes Geld.

Die folgende Heuristik hat sich in der Praxis bewährt. Identifizieren Sie zunächst Ihre Baseline-Utilization, also den Compute-Verbrauch, den Sie 24/7 über die letzten 90 Tage hatten. Diese Baseline können Sie zu etwa 80 % mit 3-Jahres-Savings-Plans abdecken. Die nächsten 10–15 % darüber, also leicht volatile, aber persistente Last, decken Sie mit 1-Jahres-Savings-Plans ab. Den Rest, also Peak-Last und experimentelle Workloads, lassen Sie auf On-Demand laufen. Noch besser: auf Spot Instances, wenn die Workload unterbrechungstolerant ist.

Bei Kubernetes-basierten Architekturen mit Karpenter-Autoscaling wird die Strategie nochmal subtiler. Dafür gibt es einen separaten Karpenter- und Kubecost-Praxisleitfaden für 2026, der die Wechselwirkung zwischen Node-Autoscaling und Compute Savings Plans im Detail behandelt.

So kaufen Sie Savings Plans über AWS Cost Explorer

AWS bietet im Cost Explorer einen Recommendation-Algorithmus, der auf Basis der letzten 7, 30 oder 60 Tage einen optimalen Commitment-Betrag vorschlägt. Die folgende AWS-CLI-Sequenz zeigt, wie Sie diese Empfehlungen programmatisch abrufen und in einem Reporting-Skript verarbeiten können:

# Empfehlungen für Compute Savings Plans abrufen
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope LINKED \
  --region us-east-1 \
  --output json > sp-recommendations.json

# Coverage-Quote der letzten 30 Tage prüfen
aws ce get-savings-plans-coverage \
  --time-period Start=2026-05-17,End=2026-06-17 \
  --granularity MONTHLY \
  --metrics SpendCoveredBySavingsPlans \
  --region us-east-1

# Utilization bestehender Savings Plans abrufen
# Werte unter 95 % deuten auf Over-Commitment hin
aws ce get-savings-plans-utilization \
  --time-period Start=2026-05-17,End=2026-06-17 \
  --granularity DAILY \
  --region us-east-1

Wichtig: AWS empfiehlt Commitments tendenziell zu hoch, weil der Algorithmus die letzten 60 Tage extrapoliert und keine geplanten Architekturänderungen kennt. Reduzieren Sie die Empfehlung um 10–15 %, wenn Sie wissen, dass eine Migration, Konsolidierung oder ein Workload-Offboarding ansteht. Bei mehreren Linked Accounts kaufen Sie immer im Payer Account, damit Sharing-Effekte über alle Tochterkonten greifen.

Häufige Fehler beim Commitment-Kauf

Die folgenden fünf Fehler tauchen in praktisch jedem FinOps-Audit auf, das ich begleite. Wer sie vermeidet, holt typischerweise 8–15 % mehr Effektivrabatt aus seinem Commitment-Portfolio.

Fehler 1, Kauf vor dem Right-Sizing: Sie committen einen Dollar-Betrag, der auf überdimensionierten Instanzen basiert. Right-Size zuerst (CPU-Utilization unter 40 % über 14 Tage ist ein klares Signal), dann committen. Sonst zementieren Sie Verschwendung für 1 oder 3 Jahre.

Fehler 2, 100 % Coverage anstreben: Niemand sollte 100 % Coverage haben. Workloads sind volatil, Architekturen ändern sich, AWS launcht neue Instanzgenerationen. Bleiben Sie bei 70–85 %.

Fehler 3, EC2 Instance Savings Plan ohne Notwendigkeit: Der 6-Prozentpunkte-Vorsprung des EC2 Instance SP gegenüber dem Compute SP klingt verlockend, aber die Familienbindung killt jede Migration. Nur wählen, wenn die Instanzfamilie absolut feststeht.

Fehler 4, All Upfront ohne Capital-Cost-Berechnung: Der All-Upfront-Bonus liegt bei rund 2–4 Prozentpunkten gegenüber No Upfront. Wenn Ihre internen Kapitalkosten höher sind, ist No Upfront ökonomisch besser, auch wenn der Rabatt nominal niedriger erscheint.

Fehler 5, kein Continuous Commitment Management: Ein Savings Plan ist kein "fire and forget". Prüfen Sie Coverage und Utilization wöchentlich, idealerweise automatisiert. Eine Utilization unter 95 % zwei Wochen in Folge ist ein klares Warnsignal für Over-Commitment und ein Indiz, beim nächsten Kauf konservativer zu sein.

Häufig gestellte Fragen

Was ist günstiger: Savings Plans oder Reserved Instances?

Bei identischer Konfiguration ist der maximale Rabatt gleich (bis zu 72 % für EC2 Instance Savings Plans und Standard Reserved Instances). Effektiv sind Savings Plans aber meist günstiger, weil ihre Flexibilität verhindert, dass Sie nach Architekturänderungen auf ungenutzten Rabatten sitzen bleiben.

Kann man AWS Savings Plans verkaufen oder kündigen?

Nein. Savings Plans sind weder kündbar noch handelbar. Nur Standard Reserved Instances können über den AWS RI Marketplace an andere Kunden weiterverkauft werden. Das ist der einzige Exit-Mechanismus für Commitments.

Was passiert mit ungenutzten Savings Plans?

Wenn Ihr tatsächlicher Compute-Verbrauch in einer Stunde unter dem committeten Dollar-Betrag liegt, wird die Differenz trotzdem in Rechnung gestellt. Sie zahlen also für Kapazität, die Sie nicht nutzen. Deshalb ist die Coverage-Quote von 70–85 % der wichtigste Hebel.

Sollte ich 1 Jahr oder 3 Jahre wählen?

3 Jahre liefern fast doppelten Rabatt, aber nur bei stabilen Workloads, deren Architektur sicher Bestand hat. Wenn eine größere Migration, ein Re-Plattforming oder eine Multi-Cloud-Entscheidung ansteht, bleiben Sie bei 1 Jahr. Der Break-Even liegt bei etwa 18–20 Monaten.

Decken Compute Savings Plans auch RDS und ElastiCache ab?

Nein. Compute Savings Plans gelten ausschließlich für EC2, Fargate und Lambda. Für RDS, ElastiCache, OpenSearch und Redshift gibt es nur die jeweiligen Reserved-Instance-Produkte mit eigenen Laufzeiten und Payment Options.