Azure-Reservierungen: Laufzeit, Scope und Abrechnung

Azure-Reservierungen sind Zusagen über ein oder drei Jahre für eine bestimmte Ressourcenkonfiguration, etwa eine VM-Größe in einer Region; im Gegenzug rechnet Azure passende Nutzung jede Stunde zum Reservierungspreis statt zum Pay-as-you-go-Preis ab. Eine Reservierung ist ein reiner Abrechnungsrabatt und lässt die Ressourcen unberührt. Eine Stunde ohne passende Nutzung verfällt, bezahlt wird trotzdem die ganze Laufzeit. Für die Rechnung heißt das: Eine Reservierung senkt den Preis der gleichmäßigen Grundlast, und ihr Wert hängt daran, dass im gewählten Scope jede Stunde passende Ressourcen laufen. Sie ist das Azure-Gegenstück zu den Reserved Instances von AWS.

So funktioniert es

Beim Kauf legt man die Attribute fest, an die der Rabatt gebunden ist: SKU, Region (wo zutreffend), Laufzeit und Scope. Die Laufzeit beträgt ein oder drei Jahre, das Feld Term in den Kostendaten zeigt 12 oder 36 Monate. Bezahlt wird vorab oder monatlich, laut Microsoft zum gleichen Gesamtpreis. Monatsraten laufen ab dem Kaufdatum und können beim Microsoft Customer Agreement mit dem Wechselkurs der lokalen Währung schwanken.

Azure wendet den Rabatt stündlich an, laut Übersicht mit Azure Databricks als einziger Ausnahme. Läuft eine VM nur einen Teil der Stunde, füllen andere passende VMs im Scope den Rest. Am Ende der Stunde ist die Zuordnung fest: Nutzung über der Reservierung kostet Pay-as-you-go, ungenutzte Stunden verfallen. Wird eine Ressource freigegeben oder gelöscht, wandert der Rabatt zu einer anderen passenden Ressource im Scope. Eine gestoppte, aber nicht freigegebene VM wird dagegen weiter berechnet und verbraucht weiter Reservierungsstunden.

Eine VM-Reservierung deckt nur die Rechenkosten. Windows-Lizenz, zusätzliche Software, Netzwerk und Speicher kosten weiter den normalen Preis, und Spot VMs lassen sich nicht reservieren. Neben VMs sind unter anderem SQL Database, Cosmos DB, Blob Storage, App Service und Premium SSD ab P30 reservierbar, jeweils mit eigener Einheit; diese Programme beschreibt Reservierte Kapazität für Datenbanken und Dienste.

Scope

Der Scope bestimmt, wo der Rabatt greift: eine Ressourcengruppe, ein Abonnement, eine Verwaltungsgruppe (deren Abonnements im selben Abrechnungskontext) oder Shared, also alle berechtigten Abonnements im Abrechnungskontext. Dieser Kontext ist beim Enterprise Agreement die Enrollment, beim Microsoft Customer Agreement das Billing Profile unterhalb des Abrechnungskontos. Azure verarbeitet Reservierungen in dieser Reihenfolge: Ressourcengruppe, Abonnement, Verwaltungsgruppe, Shared. Der Scope lässt sich nach dem Kauf jederzeit ändern, ohne neue Transaktion und ohne die Laufzeit zu berühren.

Instanzgrößenflexibilität

Beim Kauf einer Reserved VM Instance wählt man zwischen den Einstellungen „Optimize for instance size flexibility“ und „capacity priority“. Mit der ersten gilt der Rabatt für alle Größen derselben Flexibilitätsgruppe, umgerechnet über ein Verhältnis: In der DSv2-Gruppe hat Standard_DS1_v2 das Verhältnis 1 und Standard_DS4_v2 das Verhältnis 8, eine Reservierung für DS4_v2 deckt also acht DS1_v2 oder die Hälfte einer DS5_v2 mit dem Verhältnis 16. Die Verhältnisse stellt Microsoft per API und PowerShell bereit; die CSV-Datei auf der Seite erhält laut Microsoft seit dem 2026-05-09 keine Aktualisierungen mehr. Mit dieser Einstellung erhalten außer Nutzung mit ConsumedService = Microsoft.Compute auch Dienste wie Microsoft.Batch und Microsoft.MachineLearningServices den Rabatt.

Für neue Reservierungen ist die automatische Verlängerung beim Kauf voreingestellt; ohne sie gilt nach dem Laufzeitende Pay-as-you-go. Reservierungen lassen sich tauschen und zurückgeben, Rückgaben bis 50.000 USD je rollierende 12 Monate und Billing Profile oder Enrollment. Stand 2026-10-16 schreibt Microsoft außerdem: Ab dem 2027-02-01 gekaufte Reservierungen sind nicht mehr tauschbar, wenn Savings Plans den Dienst abdecken, etwa Virtual Machines, App Service und SQL Database; vorher gekaufte behalten einen letzten Tausch. Die Regeln beschreibt Tausch, Kündigung und Ablauf, die flexiblere Zusage Azure Savings Plan für Compute.

Was es für Ihre Kosten bedeutet

Cost Management liefert Reservierungen für Enterprise Agreement und Microsoft Customer Agreement in zwei Datensätzen:

Actual Cost entspricht der Rechnung: Eine Vorauszahlung erscheint als Spitze im Kaufmonat, die abgedeckten VMs kosten null, und Frequency unterscheidet OneTime (vorab) von Recurring (monatlich). Die amortisierten Kosten verteilen den Kaufpreis gleichmäßig auf die Tage der Laufzeit, ordnen ihn den Ressourcen mit Rabatt als ihre effektiven Kosten zu und weisen ungenutzte Stunden als eigenen Posten ohne Abonnement aus. Nur diese Sicht taugt für Showback und Chargeback; die Kostenmaße beschreibt Listen-, berechnete, effektive, amortisierte Kosten. Für Abonnements mit Pay-as-you-go-Preisen (MS-AZR-0003P) zeigt Cost Analysis keine amortisierten Reservierungskosten.

Für den Abgleich ist ProductOrderId der stabile Schlüssel: Kauf- und Nutzungsposten tragen dieselbe Bestellnummer, die ReservationId kann abweichen, weil Split, Merge, Teilrückgabe oder Tausch neue Reservierungen erzeugen. RINormalizationRatio in AdditionalInfo zeigt, mit welchem Verhältnis die Reservierung auf einen Posten angewendet wurde. Den Export beider Datensätze beschreibt Azure-Kostenexporte, die Ansichten im Portal Azure Cost Management and Billing. Die Auslastung zeigt das Portal unter Reservations je Reservierung mit Verlauf, mit einstellbaren Warnungen bei niedriger Auslastung.

Im Vergleich mit AWS Reserved Instances:

Wo es schiefgeht

• Zu enger Scope. Symptom: UnusedReservation wächst, während in einem anderen Abonnement passende VMs Pay-as-you-go zahlen. Ursache: Die Reservierung gilt nur für eine Ressourcengruppe oder ein Abonnement.
• Gestoppt statt freigegeben. Symptom: Die Auslastung ist hoch, obwohl ein Teil der VMs nichts tut. Ursache: Gestoppte, nicht freigegebene VMs werden weiter berechnet und verbrauchen Reservierungsstunden.
• Lizenz mitgerechnet. Symptom: Windows-VMs kosten trotz voller Reservierung mehr als der Reservierungspreis. Ursache: Die Reservierung deckt nur die Infrastruktur, die Windows-Lizenz wird je vCPU separat berechnet.
• Falsche Flexibilitätsgruppe. Symptom: Eine Reservierung für Standard_D1 bleibt ungenutzt, obwohl Standard_DS1 läuft. Ursache: Größen mit Premium Storage bilden eine eigene Gruppe; Azure wertet ServiceType in AdditionalInfo aus, nicht den Meter.
• Chargeback aus Actual Cost. Symptom: Abgedeckte Ressourcen stehen mit null in der Auswertung, das kaufende Abonnement trägt die ganze Vorauszahlung. Ursache: Actual Cost zeigt den Kauf wie die Rechnung; erst Amortized Cost verteilt ihn auf die Nutzer.

Beispiel

Die Preisseite für Linux-VMs zeigte am 2026-10-16 für eine D2s v5 (2 vCPU, 8 GiB) mit Ubuntu in der Region Germany West Central, in Euro und je Stunde:

Die Azure Retail Prices API lieferte am selben Tag für diese Reservierungen 547,3425 EUR und 1.050,6864 EUR bei unitOfMeasure = 1 Hour. Das ist der Preis der ganzen Laufzeit: Geteilt durch 8.760 beziehungsweise 26.280 Stunden ergibt er die Stundenpreise der Seite. Microsoft rechnet die Euro-Preise aus US-Dollar um und bezeichnet sie als Schätzungen.

Quellen

Gelesen am 2026-10-16. Microsoft What are Azure Reservations?, Buy a reservation, How a reservation discount is applied, How the Azure reservation discount is applied to virtual machines, Virtual machine size flexibility with Reserved VM Instances, Get Enterprise Agreement and Microsoft Customer Agreement reservation costs and usage, View amortized benefit costs, Understand usage details fields, View reservation utilization after purchase, Automatically renew reservations, Self-service exchanges and refunds for Azure Reservations, Linux Virtual Machines pricing, Azure Retail Prices REST API overview.