Reserved Instances und Savings Plans sparen nur dort Geld, wo sie tatsächlich zu laufenden Workloads passen. Die Differenz zwischen dem, was theoretisch committed werden könnte, und dem, was real committed ist, bleibt in vielen Umgebungen unübersichtlich, weil niemand sie regelmäßig nachmisst. Cost Explorer und Azure Advisor liefern die Zahlen dafür bereits mit, ohne Zusatzwerkzeug.

Wie groß die Lücke in der Praxis typischerweise ist

Laut dem Flexera State-of-the-Cloud-Report 2026 gelten rund 29 Prozent der IaaS- und PaaS-Ausgaben als verschwendet, ein Anstieg gegenüber dem Vorjahreswert von 27 Prozent. Ein Teil davon entsteht nicht durch falsch dimensionierte Instanzen, sondern durch fehlende Commitments. Eine belastbare, aktuelle Prozentzahl speziell für die RI-/Savings-Plan-Abdeckung oder den Anteil committment-freier Unternehmen lässt sich derzeit nicht an einer einzelnen Quelle festmachen, die Werte schwanken stark zwischen den verfügbaren Berichten. Unabhängig von der exakten Zahl bleibt der Effekt in der Praxis erkennbar: On-Demand-Anteile, die seit Monaten stabil laufen und nie committed wurden, sind in vielen Umgebungen der Normalfall, nicht die Ausnahme.

Im AWS Cost Explorer nachsehen

Im Cost Explorer liegt der Bereich für Reservierungen und Savings Plans getrennt von der allgemeinen Kostenübersicht. Zwei Berichte zeigen die aktuelle Lücke direkt. Der Coverage-Bericht zeigt, welcher Anteil deiner On-Demand-fähigen Nutzung bereits durch RIs oder Savings Plans abgedeckt ist, aufgeschlüsselt nach Instanzfamilie, Region und Zeitraum. Der Utilization-Bericht zeigt das Gegenstück: wie viel von dem, was du bereits committed hast, tatsächlich genutzt wird. Eine hohe Utilization bei niedriger Coverage bedeutet, dass die bestehenden Commitments gut laufen, aber zu wenige davon existieren. Eine niedrige Utilization bedeutet, dass zuerst die bestehenden Commitments geklärt werden müssen, bevor neue dazukommen.

Die Recommendations-Ansicht für Reserved Instances und für Savings Plans schlägt dir anschließend konkrete Käufe vor, auf Basis eines wählbaren Rückblickzeitraums über mehrere Wochen Nutzungsdaten. Genau dieser Rückblickzeitraum ist der Punkt, an dem du nicht blind der Empfehlung folgen solltest. Eine Empfehlung, die auf den letzten sieben Tagen beruht, bildet Lastspitzen ab, keine stabilen Muster. Für ein Commitment über ein oder drei Jahre zählt, ob die zugrunde liegende Nutzung seit mehreren Monaten gleichmäßig läuft, nicht ob sie letzte Woche hoch war.

Ein typisches Bild in der Praxis: Der Coverage-Bericht zeigt für eine Instanzfamilie eine Abdeckung von 40 Prozent, der Utilization-Bericht für die bestehenden Commitments dagegen fast 100 Prozent. Die Lesart ist eindeutig: Die vorhandenen Reservierungen laufen voll aus, es fehlen schlicht weitere für die restlichen 60 Prozent On-Demand-Last. Zeigt der Utilization-Bericht stattdessen nur 70 Prozent bei bereits bestehenden Commitments, ist das eigentliche Problem nicht die Abdeckungslücke, sondern ungenutzte Reservierungen, die zuerst einem passenden Workload zugeordnet werden müssen.

In Azure Advisor denselben Blick werfen

Azure Advisor führt die Kostenempfehlungen in einer eigenen Kategorie, getrennt von Zuverlässigkeit, Sicherheit und operativer Exzellenz. Dort stehen Reserved-Instance-Empfehlungen neben Empfehlungen zum Rightsizing beziehungsweise Herunterskalieren ungenutzter Ressourcen. Der Unterschied zu AWS: Advisor zeigt dir vor allem, wo sich eine Reservierung lohnen würde. Die bestehende Abdeckung musst du selbst aus Cost Management gegen diese Empfehlung spiegeln, um die Lücke in Prozent zu bekommen. Cost Management liefert dafür die Aufschlüsselung in reservierte Kosten gegenüber On-Demand-Kosten je Abonnement.

Bevor du ein Commitment eingehst

Ein RI- oder Savings-Plan-Kauf bindet dich für die gewählte Laufzeit an eine Instanzfamilie, eine Region (bei bestimmten Savings-Plan-Typen flexibler gefasst) und ein Zahlungsmodell. Drei Fragen helfen vor dem Kauf. Läuft die zugrunde liegende Nutzung seit mindestens einigen Monaten stabil, oder ist sie saisonal oder experimentell? Passt die Laufzeit zur geplanten Lebensdauer des Workloads und nicht nur zum aktuell höchsten Rabattsatz? Und lohnen sich eher mehrere kleinere Käufe auf Basis eines kürzeren Rückblickzeitraums statt eines einzigen großen Commitments? Eine strukturierte Prüfung der eigenen Commitment-Lücke findest du hier: Reserved-Instance-Check.

Fragen oder Anmerkungen zu diesem Setup: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.