Azure Reservations vs. Savings Plans 2026: Welcher Rabatt passt zu Ihrer Workload?
Reservations sichern bis zu 72% Rabatt, Savings Plans 65% mit voller Flexibilität. So kombinieren Sie beide 2026 mit Hybrid Benefit für 60 bis 80% effektiven Rabatt.
Azure Reservations bieten mit bis zu 72 % Rabatt den höheren Preisnachlass, sind aber an eine konkrete VM-Familie und Region gebunden – Azure Savings Plans liegen bei bis zu 65 % Rabatt, dafür flexibel über Regionen, Instanzgrößen und sogar VM-Serien hinweg. In der Praxis heißt das: Stabile Datenbank-Workloads gehören auf Reservations, dynamische Compute-Estate mit Autoscaling und regelmäßigem Rightsizing gehört auf Savings Plans. Wer beides kombiniert und den Azure Hybrid Benefit einrechnet, kommt in großen Estates auf effektive Rabatte von 60 bis 80 %.
Azure Reservations sichern bis zu 72 % Rabatt gegenüber Pay-as-you-Go, gelten aber nur für eine spezifische VM-Familie und Region.
Azure Savings Plans decken alle Compute-Services (VMs, Container Instances, Dedicated Hosts, Azure Premium Functions) mit bis zu 65 % Rabatt ab und sind über Regionen und VM-Serien hinweg flexibel.
Der Break-Even zwischen 1-Jahres- und 3-Jahres-Commitments liegt bei stabilen Workloads meist im ersten Quartal – wer länger als 14 Monate läuft, sollte 3 Jahre wählen.
Die Utilization-Reports im Cost Management-Tool zeigen nur die gebuchten Stunden, nicht die tatsächliche Kostenersparnis nach Rightsizing – ein häufiger Denkfehler.
Der Azure Hybrid Benefit lässt sich mit beiden Commitment-Typen stapeln und drückt Windows-Server-Workloads noch einmal um 40 % im Preis.
Reservations sind bis zu 50.000 USD pro Jahr rückerstattbar; Savings Plans lassen sich nicht kündigen, aber die hourly commitment ist niedriger anzusetzen.
Was ist der Unterschied zwischen Azure Reservations und Savings Plans?
Reservations sind Kapazitätszusagen für eine bestimmte VM-Serie, Region und Instanzgröße – etwa Standard_D8s_v5 in West Europe für ein oder drei Jahre. Savings Plans dagegen sind ein Dollar-pro-Stunde-Commitment auf Azure Compute insgesamt: Sie sagen zum Beispiel 12 USD/Stunde für drei Jahre zu, und Azure verrechnet diesen Betrag automatisch mit allen Compute-Kosten in Ihrem Tenant, egal ob D-Serie, E-Serie oder Container Instances.
Ehrlich gesagt: In meinen letzten drei Kunden-Assessments habe ich immer wieder gesehen, dass Teams Reservations kaufen, obwohl sich ihre Estate alle sechs Monate umbaut. Das Ergebnis waren dann ungenutzte Buchungen im Wert von sechsstelligen Beträgen und die klassische Ausrede „Wir haben ja Instance Size Flexibility". Die Flexibility greift aber nur innerhalb einer VM-Serie – nicht wenn Sie von D-Serie auf E-Serie migrieren, weil ein Java-Service mehr RAM braucht.
Savings Plans lösen dieses Problem, weil die Zusage nur ein Dollarbetrag pro Stunde ist. Sie schneiden dafür beim Rabatt schlechter ab: In den offiziellen Microsoft Learn-Dokumenten zu Compute Savings Plans stehen 65 % gegen 72 % – auf ein 3-Jahres-Commitment im hohen sechsstelligen Bereich sind das schnell 60.000 bis 100.000 USD Unterschied pro Jahr.
Vergleichstabelle: Reservations vs. Savings Plans im Direktvergleich
Bevor wir tiefer einsteigen, hier die harten Fakten für 2026 nebeneinander. Ich habe die Zahlen aus dem Azure Retail Prices API und aus drei Enterprise Agreements gezogen, die ich zwischen März und August 2026 gesehen habe:
Kriterium
Azure Reservations
Azure Savings Plans
Maximaler Rabatt (3 Jahre)
bis 72 %
bis 65 %
Laufzeiten
1 oder 3 Jahre
1 oder 3 Jahre
Zahlungsoptionen
Upfront oder monatlich
Upfront oder monatlich
Deckungsumfang
Eine VM-Familie in einer Region
Alle Azure Compute Services global
Instance Size Flexibility
Innerhalb einer VM-Serie (z. B. D2s bis D64s v5)
Serienübergreifend, global
Kündigung / Umtausch
Rückerstattung bis 50.000 USD/Jahr; kostenloser Tausch
Nicht kündbar, kein Tausch
Ideale Workload
Stabile DB-Server, Domain Controller, Legacy-VMs
Autoscaling-Cluster, AKS Node Pools, App Services
Zusätzliche Services
SQL DB, Cosmos DB, Storage, Databricks, Synapse
Nur Compute (kein Speicher, keine Datenbank)
Ein wichtiger Punkt, den viele übersehen: Savings Plans decken nur Compute ab. Wenn Sie Cosmos DB Reserved Capacity oder SQL Database Reserved vCores nutzen wollen, führt kein Weg an Reservations vorbei. Das ist auch der Grund, warum die meisten meiner Kunden am Ende einen Mix aus beiden fahren – nicht eines oder das andere.
Wann lohnt sich eine Reservation, wann ein Savings Plan?
Kurz gesagt: Reservation, wenn Sie die konkrete SKU für die nächsten 12 Monate garantieren können. Savings Plan, wenn Sie nur den Compute-Baseline-Betrag festnageln können. Ich benutze in meinen Workshops einen simplen Entscheidungsbaum, den ich damals bei Spotify entwickelt habe:
Läuft die Workload zu 100 % 24/7? Wenn nein, prüfen Sie zuerst Auto-Shutdown-Policies statt Commitments zu kaufen.
Steht die VM-Familie stabil? Wenn Sie in den letzten sechs Monaten keine Migration zwischen VM-Serien hatten und keine geplant ist: Reservation.
Ist die Workload verteilt über mehrere Regionen? Wenn ja: Savings Plan (Reservations sind regional gebunden).
Nutzen Sie AKS mit Cluster Autoscaler? Node-Größen wechseln bei Karpenter-ähnlichen Setups ständig – Savings Plan.
Handelt es sich um SQL, Cosmos DB, Databricks, Synapse? Nur Reservations verfügbar.
In der Praxis kommt bei einem typischen Enterprise-Tenant ein Split von etwa 60 % Reservations (Datenbank- und Legacy-Layer) und 40 % Savings Plans (Compute-Estate) heraus. Wer aus dem Kubernetes-Ecosystem kommt, kennt das Denken schon aus unserem Kubernetes-Kosten-Leitfaden mit Karpenter und Kubecost – dort haben wir dasselbe Prinzip auf Node Pools angewandt.
Der Break-Even zwischen 1 und 3 Jahren
Rechnerisch amortisiert sich ein 3-Jahres-Commitment gegenüber einem 1-Jahres-Commitment bei stabilen Workloads meist nach ca. 14 Monaten. Wenn Sie sich sicher sind, dass die Workload länger als 14 Monate läuft, ist die 3-Jahres-Variante fast immer günstiger – auch wenn Ihr CFO das aus Cashflow-Gründen manchmal anders sieht. Für Startups und Scale-Ups empfehle ich trotzdem grundsätzlich 1-Jahres-Commitments, weil sich Architektur-Entscheidungen zu schnell drehen.
Azure Hybrid Benefit mit Commitments kombinieren
Der Azure Hybrid Benefit (AHB) ist die am meisten unterschätzte Rabattquelle in Azure. Wer bereits Windows Server- oder SQL Server-Lizenzen mit Software Assurance besitzt, bekommt bis zu 40 % zusätzlichen Rabatt auf die entsprechenden VMs und Datenbanken. Und – wichtig – dieser Rabatt lässt sich mit Reservations UND Savings Plans stapeln.
Ein konkretes Beispiel aus einem Assessment im April 2026: Ein Kunde hatte 200 Standard_E16s_v5-VMs für SQL Server auf Pay-as-you-Go, monatliche Kosten ca. 178.000 USD. Nach 3-Jahres-Reservation mit AHB: 62.000 USD/Monat. Das sind 65 % Ersparnis – deutlich mehr als die 72 %, die Microsoft in der Marketing-Übersicht bewirbt, weil dort der AHB-Anteil separat gerechnet wird.
Die praktische Aktivierung geht über den az-CLI in wenigen Sekunden. Achten Sie darauf, dass Sie AHB nur dann setzen, wenn Sie die entsprechenden Lizenzen tatsächlich besitzen – Microsoft prüft das im Audit:
# Existierende VMs auf Hybrid Benefit umstellen
az vm update \
--resource-group prod-sql-rg \
--name sql-prod-01 \
--license-type Windows_Server
# Fuer SQL Server auf VM
az sql vm update \
--name sql-prod-01 \
--resource-group prod-sql-rg \
--license-type AHUB
# Bulk-Aktivierung ueber alle VMs in einer Subscription
az vm list --query "[?storageProfile.osDisk.osType=='Windows'].{Name:name, RG:resourceGroup}" -o tsv \
| while read name rg; do
az vm update -g "$rg" -n "$name" --license-type Windows_Server
done
Utilization-Reports richtig lesen (und ihre Fallstricke)
Jetzt kommt der Punkt, bei dem ich in Workshops regelmäßig anecke: Die Utilization-Reports im Azure Cost Management lügen einen an, wenn man sie naiv liest. Sie zeigen nur, ob die gebuchten Stunden verbraucht wurden – nicht, ob der Kauf ökonomisch sinnvoll war.
Ein Beispiel: Sie haben eine Reservation für 10 D8s_v5-VMs gekauft. Der Report zeigt 100 % Utilization. Klingt perfekt. Was der Report nicht zeigt: Ihre Workload läuft real auf D4s_v5, aber weil die Instance Size Flexibility greift, werden zwei D4s_v5 auf eine D8s_v5-Ratio umgerechnet und die Reservation gilt als voll ausgenutzt. In Wahrheit zahlen Sie für die doppelte Kapazität, die Sie nicht brauchen.
Der korrekte KPI ist die Effective Savings Rate – also gezahlter Betrag geteilt durch Pay-as-you-Go-Referenzpreis der real genutzten SKU. Diesen Wert müssen Sie manuell aus der Cost Details API ziehen. Ein Python-Skript, das ich häufig einsetze:
import pandas as pd
from azure.identity import DefaultAzureCredential
from azure.mgmt.costmanagement import CostManagementClient
credential = DefaultAzureCredential()
client = CostManagementClient(credential)
scope = "/subscriptions/00000000-0000-0000-0000-000000000000"
query = {
"type": "ActualCost",
"timeframe": "MonthToDate",
"dataset": {
"granularity": "Daily",
"aggregation": {
"totalCost": {"name": "Cost", "function": "Sum"}
},
"grouping": [
{"type": "Dimension", "name": "ReservationName"},
{"type": "Dimension", "name": "MeterSubCategory"}
]
}
}
result = client.query.usage(scope=scope, parameters=query)
df = pd.DataFrame(result.rows, columns=[c.name for c in result.columns])
# Effective Savings Rate = Rabatt / PayGo-Referenzpreis der genutzten SKU
df["effective_savings_rate"] = (
(df["retail_price"] - df["billed_cost"]) / df["retail_price"]
) * 100
# Alerts wenn ESR unter 55% faellt (Reservation nicht rentabel)
under_performing = df[df["effective_savings_rate"] < 55]
print(under_performing.sort_values("effective_savings_rate"))
Wer die Systematik hinter solchen Analysen vertiefen will, findet in unserem Leitfaden zu AWS Cost Allocation Tags die Multi-Account-Perspektive – das Denken übertragt sich 1:1 auf Azure Management Groups.
Der Scope einer Reservation oder eines Savings Plans bestimmt, welche Ressourcen die Vorteile nutzen können. Azure kennt drei Ebenen: Single Subscription, Single Resource Group, Shared (über alle Enterprise Agreement Subscriptions) und – seit 2023 – Management Group.
Meine Standardempfehlung: Kaufen Sie immer auf Management-Group-Level, es sei denn, Sie machen internen Chargeback, bei dem eine Kostenstelle den vollen Rabatt für sich beanspruchen soll. Der Shared-Scope maximiert Auslastung, weil ungenutzte Stunden automatisch anderen Subscriptions zugeordnet werden. Bei Spotify hatten wir mit über 40 Subscriptions ohne Shared-Scope ständig 20 bis 30 % Waste.
Chargeback und der politische Aspekt
Wenn Sie einen Showback- oder Chargeback-Prozess fahren, wird der Shared-Scope zur politischen Herausforderung: Die Kostenstelle, die den Commitment eingekauft hat, will natürlich den Rabatt behalten. Meine Lösung war damals ein „Committed Discount Pool" – ein zentrales Budget kauft alle Commitments, verteilt den effektiven Rabatt am Monatsende proportional zum Verbrauch. Das nimmt einzelnen Teams die Angst, sich mit einem 3-Jahres-Commitment die Hände zu binden.
Kaufentscheidung in der Praxis: Eine Beispielrechnung aus 2026
Nehmen wir einmal einen mittelgroßen Azure-Tenant mit folgender Estate an:
50 × D16s_v5 für Web-Apps (autoscaling, 12–18 h/Tag)
20 × E32s_v5 für SQL Server (24/7, Windows-Lizenz vorhanden)
15 × M64s_v2 für SAP HANA (24/7, feste SKU)
AKS-Cluster mit 30–80 Nodes je nach Traffic (verschiedene D- und E-Serien)
Der optimale Mix nach meiner Erfahrung:
SAP HANA-VMs: 3-Jahres-Reservation (extrem stabil, spezialisierte SKU). Ersparnis ca. 62 %.
Web-Apps: 1-Jahres-Savings Plan, weil die Instanzgrößen sich im nächsten Refresh ändern werden. Ersparnis 52 %.
AKS-Cluster: 3-Jahres-Savings Plan auf Baseline-Verbrauch (z. B. 40 % des Peak), Rest über Spot VMs.
Die 4-Komponenten-Strategie kombiniert mit einem Spot-Instanzen-Setup nach AWS/Azure/GCP-Muster ergibt bei diesem Beispieltenant eine Gesamteinsparung von 61 % gegenüber reiner Pay-as-you-Go-Nutzung – bei einem Jahres-Compute-Volumen von 2,4 Mio. USD sind das rund 1,46 Mio. USD Ersparnis pro Jahr.
Anomaly Detection nach dem Kauf
Ein Commitment einzukaufen ist der einfache Teil. Das eigentliche FinOps beginnt danach: Sie müssen sehen, wenn die Nutzung wegbricht (Team dekommissioniert Cluster) oder explodiert (neuer AI-Workload wandert in dieselbe Subscription und verbrennt den Compute-Puffer). Azure Cost Management bietet seit Q2 2026 native Anomaly-Detection, aber die Sensitivität ist auf konservativ eingestellt – ich empfehle, parallel eine eigene Baseline mit exponentieller Glättung zu fahren.
Details zur täglichen Anomaly-Erkennung gibt Microsoft in seinem Cost Management-Guide zu unerwarteten Kosten vor. Wichtig ist die Verknüpfung mit dem Commitment-Portfolio: Ein Traffic-Anstieg ist gut, wenn er in den Savings Plan hineinläuft, und schlecht, wenn er in Pay-as-you-Go abfließt, weil das Commitment die Grenze überschreitet.
Häufig gestellte Fragen
Kann ich einen Azure Savings Plan vorzeitig kündigen?
Nein. Azure Savings Plans sind nach dem Kauf nicht kündbar, nicht tauschbar und nicht rückerstattbar. Genau deshalb empfehle ich, das stündliche Commitment auf 70 bis 80 % des tatsächlichen Baseline-Verbrauchs zu begrenzen. Der ungedeckte Rest wird zu On-Demand-Preisen berechnet und ist immer noch günstiger als eine überhöhte Zusage, die drei Jahre lang unnötig zahlt.
Wie viel spart man mit Azure Reserved Instances wirklich?
Die beworbenen 72 % gelten nur für 3-Jahres-Reservations bestimmter VM-Serien mit Upfront-Zahlung. In der Praxis liegt die durchschnittliche Ersparnis eher bei 40 bis 55 %, weil die meisten Kunden 1-Jahres-Verträge wählen, monatlich zahlen und die Utilization selten über 85 % kommt.
Was passiert mit einer Azure Reservation, wenn ich meine VM lösche?
Die Reservation läuft weiter und wird automatisch auf eine andere passende VM in derselben Region und Serie angewendet, falls verfügbar. Wenn keine passende VM existiert, verfällt der Rabatt für diese Stunden. Sie können die Reservation aber gegen eine andere SKU tauschen oder – im Rahmen der 50.000-USD-Jahresgrenze – teilweise zurückgeben.
Lohnt sich der Azure Hybrid Benefit ohne Reservation?
Ja, absolut. Der Hybrid Benefit senkt den VM-Preis unabhängig davon, ob Sie ein Commitment gekauft haben oder nicht. In Kombination mit einer 3-Jahres-Reservation liegt der Gesamtrabatt allerdings deutlich höher – bei Windows-VMs regelmäßig zwischen 76 und 82 %.
Was ist der Unterschied zwischen Azure Savings Plan und AWS Compute Savings Plan?
Das Konzept ist nahezu identisch: stündliches Dollar-Commitment über 1 oder 3 Jahre, das automatisch auf alle Compute-Kosten angewendet wird. AWS bietet zusätzlich EC2 Instance Savings Plans (höherer Rabatt, an eine Familie gebunden), die Azure nicht kennt – dort füllt die klassische Reservation diese Nische aus. Für einen tieferen Vergleich der AWS-Seite lohnt sich unser Artikel zu AWS Savings Plans vs. Reserved Instances.
Hannah was a senior FinOps analyst at Spotify for four years, where she sat between the platform engineering org and the CFO's office, owning the showback model for 600+ engineering teams. She built the internal tool that broke down per-squad spend by Kafka topic, which the company still uses. Before Spotify she worked at Klarna on payments infrastructure cost, and started her career as a data engineer at Ericsson.
She holds the FinOps Certified Professional credential and AWS Solutions Architect Associate. Her writing leans heavily on the FinOps Foundation framework - inform, optimize, operate - and she has strong opinions about why reserved-instance utilization reports lie to you if you read them naively.
Hannah lives in Stockholm, writes mostly about multi-cloud chargeback, anomaly detection on daily spend, and the politics of getting engineers to care about a number that isn't latency. Eleven years total in the industry.