Als kurze Wiederholung – worum handelt es sich hier eigentlich?

Bei Reservierungen (oder Reserved Instances) bucht man eine spezifische VM SKU (oder zumindest eine konkrete Serie, dazu unten mehr) für eine bestimmte Azure Region, ggf. für einen spezifischen Scope (z.B. eine bestimmte Subscription) auf ein oder drei Jahre. Dafür erhält man diese Leistung dann zu einem stark rabattierten Preis. Die Kosten kann man entweder monatlich oder direkt einmal vollständig im Voraus zahlen.

Bei einem Savings Plan zahlt man einen selbst gewählten Betrag ein. Dabei legt man weder eine SKU, noch eine Region fest. Man muss sich noch nicht einmal für einen konkreten Service festlegen, wenngleich Savings Plans nur für eine kleine Liste von Diensten gelten (insb. VMs, VMSS, AKS, App Services). Dafür erhält man Leistungen zu einem rabattierten Preis. Welche das sind, wird von Microsoft danach entschieden, welche passenden Dienste im Scope des Savings Plans den größten Preisnachlass durch den Plan haben. Im Prinzip zahlt man hier einen gewissen Betrag ein, den Microsoft dann „verzinst“ und aus dem verzinsten Guthaben dann Leistungen bezahlt.

Es gibt hier also zwei ganz wesentliche Unterschiede:

Nun kommt aber ein weiterer Aspekt (zumindest derzeit noch, und keiner weiss wie lange) dazu: Die Verbindlichkeit!

Eine Reservierung für VMs ist zwar sehr spezifisch in ihrer Gültigkeit (Region, VM SKU), kann allerdings geändert werden (Exchange, also der Umtausch in eine andere Reservierung, Trade-In, also das Eintauschen gegen einen Savings Plan, oder Cancelation, also das Stornieren einer Reservierung bis zu einem maximalen Betrag von 50.000 USD).

(Siehe hierzu Changes to the Azure reservation exchange policy – Microsoft Cost Management | Microsoft Learn)

Und auch wenn man sich für eine spezifische VM SKU entscheiden muss, gibt es für Reservierungen eine (mittlerweile standardmäßig aktivierte) Flexibilitäts-Option. Ist diese aktiv, kann eine Reservierung auch für andere VMs der selben „Instance Size Flexibility Group“ genutzt werden. Vereinfacht gesagt kann man dann eine andere VM der selben Serie einsetzen und die gebuchten Kerne werden entsprechend umgerechnet. So kann man dann z.B. in einer gebuchten Instanz der D8s_v5 auch alternativ 2 Instanzen der D4s_v5 betreiben. Man bleibt aber immer auf die selbe Serie und somit die selbe zugrunde liegende Hardware festgelegt!

Ein Savings Plan hingegen ist in sich deutlich flexibler in der Nutzung, da er unabhängig von einer speziellen VM SKU und auch unabhängig von einer Region verwendet werden. Allerdings gibt es für einen gebuchten Savings Plan keinerlei Möglichkeiten, diesen zu ändern. Er lässt sich weder verkleinern noch stornieren. Man kann lediglich weitere Savings Plans hinzubuchen. Er bringt somit also in letzter Konsequenz eine gefühlte höhere Verbindlichkeit mit sich!

Nun stellt sich natürlich die Frage, für welche der beiden Optionen man sich entscheiden sollte. Das kann man zwar nicht pauschal beantworten, aber es gibt einige wesentliche Aspekte, die man berücksichtigen sollte:

• Da eine Reservierung für eine spezifische Hardware (und somit ein spezielles CPU-Modell) gilt, sollte man diese nicht für alte VM SKUs buchen, weil dadurch eine Modernisierung erschwert wird. (Für VM-SKUs, die bereits abgekündigt sind, kann z.T. auch keine Reservierung mehr gebucht werden).
• Für Workloads, die zwar heute noch als klassische VM betrieben werden, für die aber eine Modernisierung z.B. hin zu Kubernetes angedacht ist, sind Savings Plans in der Regel die bessere Option, da diese auch nach der Modernisierung weiterhin genutzt werden können.
• Reservierungen bieten den größeren Rabatt als Savings Plans. Wenn es also keinen Grund zur Annahme gibt, dass die genutzten VM-Typen nicht mindestens für die Dauer der Reservierung genutzt werden, dann ist eine Reservierung kaufmännisch oft lohnender.

Und gerade zum letzten Punkt, nämlich den Rabatten bzw. Kosten, will ich noch etwas aufzeigen!

In der nachfolgenden Tabelle sind für einige ausgewählte VM-SKUs die Preise und Rabatte für West Europe und East U.S. dargestellt:

Hierbei kann man einiges feststellen:

• Reservierungen haben einen nahezu durchgehend gleichhohen Rabatt, unabhängig von Region und VM-Serie. Er liegt bei 1-jährigen Reservierungen bei ca. 40% (mit leichten Abweichungen bei sehr neuen Serien) und bei ca. 60% bei 3-jährigen Reservierungen.
• Savings Plans unterscheiden sich vor allem bei den etwas älteren VM-Serien recht deutlich zwischen den Regionen. Während es in West Europe nur etwa 25% Rabatt gibt, sind es in East U.S. über 30%.
• Somit bringen Reservierungen in West Europe zwischen 8% (Es_v6 für 1 Jahr) und 33% (Ds_v5 für 3 Jahre) mehr Rabatt als Savings Plans.
• In East U.S. sind es hingegen nur zwischen 8% und ca. 20% (D2_v5 für 3 Jahre).
  • Ergo: In West Europe lohnen sich Reservierungen oft deutlich stärker, als in East U.S.
  • Bei neueren VM-Serien sind gerade in West Europe die Rabatte bei Reservierungen nur noch geringfügig höher als bei Savings Plans der selben Laufzeit (z.B. E4s_v6 auf ein Jahr: 32% vs. 37%!)

Es kommt also auch sehr stark auf die vorgesehene Region und die eingesetzten VM-Serien an, wenn es darum geht, zu entscheiden, welcher Weg der bessere ist!

Ich hoffe, diese Analyse hilft euch etwas besser, die Entscheidungen für Reservierungen und Savings Plans zu treffen…

PS: Schaut euch bezüglich der Frage, ab wann sich Reservierungen und Savings Pläne generell lohnen, auch gerne meine vorhergegangenen Beiträge zu diesem Thema an. (Kosten sparen in Azure – Reservierungen und Kosten sparen in Azure – Savings Plans).

Bei den „Compute Savings Plans“ bzw. „Savings Plans for Compute“ handelt es sich um eine weitere Möglichkeit, durch ein langfristiges Commitment Rabatte zu bekommen. Sie verfolgen also ein ähnliches Ziel wie Reservierungen – funktionieren dabei jedoch völlig anders.

Anders als bei Reservierungen muss man sich bei den Savings Plans nicht für einen bestimmten Ressourcen-Typ festlegen. Die gebuchten Savings Plans gelten für alle unterstützten Ressourcen-Typen. Das sind aktuell:

• Azure Virtual Machines (*)
• Azure App Service
• Azure Functions premium plan
• Azure Container Instances
• Azure Dedicated Host
• Azure Container Apps
• Azure Spring Apps Enterprise

(*) Da Savings Plans für VMs gelten, gelten sie auch für alles, was durch die regulären Nutzungsgebühren von VMs abgedeckt ist, also z.B. Virtual Machine Scale Sets (VMSS), Azure Kubernetes Service (AKS) oder Azure Virtual Desktop (AVD).

Man bucht auch nicht eine bestimmte Menge oder Instanzen-Anzahl von einem konkreten Dienst, sondern definiert eine stündlich zu zahlende Summe. Diese Summe wird dann eingesetzt, um zu rabattierten Preisen die verwendeten Dienste der entsprechenden Ressourcen-Arten zu bezahlen. Dabei werden automatisch die Services mit dem höchsten Rabatten genutzt.

Rechenbeispiel

Um dies besser zu verstehen, erkläre ich es an einem einfachen Beispiel:

Nehmen wir an, wir haben eine einzige Azure VM, und zwar eine D8s_v5. Diese kostet regulär 0.441€/h (Nur Compute-Anteil). Bei einem 1-jährigen Savings Plan kostet die selbe VM noch 0.336€/h. Würden wir jetzt also stündlich genau 0.336€ in den Savings Plan einzahlen, wäre die VM damit vollständig abgedeckt und wir hätten ca. 24% Rabatt auf den Preis bekommen.

Wenn wir jetzt z.B. nur 0.200€/h in den Savings-Plan einzahlen würden, dann wären ca. 0.6h durch den Savings Plan abgedeckt. Die fehlenden 0.4h würden wir zum regulären Preis von 0.441€/h, also für ca. 0.176€, bezahlen. Somit hätten wir dann für die VM 0.376€ in dieser Stunde bezahlt.

Hätten wir hingegen 0.400€/h eingezahlt, dann wäre die VM zwar vollständig bezahlt, wir hätten aber auch 0,064€ zu viel bezahlt. Dieser Betrag wäre verloren. Das zeigt diese Grafik recht gut:

Es ist dabei aber zu beachten, dass man Savings Plans derzeit nur in US-Dollar abschließen kann. Man muss die Beträge also ggf. umrechnen.

Gemeinsamkeiten mit Reservierungen

Savings Plans haben einige Gemeinsamkeiten mit Reservierungen, insbesondere:

• Laufzeit: Der Savings Plan kann für ein Jahr oder für drei Jahre gebucht werden – wobei es bei drei Jahren deutlich größere Rabatte gibt.
• Scope: Savings Plans werden ebenfalls für einen bestimmten Scope gebucht und gegen eine definierte Subscription abgerechnet
• Abrechnung: Savings Plans werden (obwohl der Betrag pro Stunde eingestellt wird) einmal monatlich abgerechnet (siehe unten)
• Over-Commitment: Es gilt „Use-it-or-loose-it„.

Weitere Unterschiede zu Reservierungen

Vorteilhaft ist, dass ein Savings Plan nicht für eine bestimmte Region gebucht wird – er gilt also für alle Regionen. Somit muss man sich auch nicht langfristig an eine bestimmte Region binden, wie es bei Reservierungen der Fall wäre.

Außerdem kann man eben auch nur Anteile seiner Ressourcen abdecken. Während man bei Reservierungen in der Regel immer volle Instanzen bucht, könnte man bei Savings Plans z.B. auch nur 50% aller Systeme abdecken. Würde man die Systeme dann später auf die Hälfte verkleinern, wäre das dann kein Problem.

Da man sich weder für eine VM SKU, noch eine Serie festlegen muss, kann man jederzeit auf die neueste Hardware-generation wechseln. Auch eine Modernisierung von VMs zu Containern (in AKS) wäre problemlos möglich.

Für Savings Plans sind jedoch keine weiteren Flexibilitäten oder Anpassungen verfügbar. Sie lassen sich nicht stornieren, umtauschen oder anderweitig verändern. Lediglich der Scope kann angepasst werden. Man muss also vorsichtig sein, damit man nicht zu viel bucht – es ließe sich später nicht mehr reduzieren! (Hinzubuchen weiterer Savings Plans ist hingegen jederzeit problemlos möglich)

Abrechnung von Savings Plans

Wie oben erwähnt, wird jeder Savings Plan einmal im Monat abgerechnet. Dabei werden die monatlichen Stunden mit dem eingezahlten Stundensatz multipliziert (dunkelgrüne Zeile – hier wurde lediglich ein Betrag von 0.001 USD pro Stunde eingezahlt – das entspricht 0.65 EUR).

Am 15.10.2024 wurde dann eine D12 VM durch den Savings Plan teilweise abgedeckt – konkret hat man dafür 0.115h erhalten, die VM hat einen Savings-Plan-Stundenpreis von 0.379 USD. Die restlichen 23.884h des Tages wurden dann zum regulären Preis von 0.557 USD bezahlt.

Ab wann lohnt es sich?

Auch hier wollen wir uns die Frage stellen, ab wann sich ein Savings Plan lohnt. Es gelten die selben Annahmen / Bedingungen wie im Artikel zu den Reservierungen beschrieben.

Beginnen wir mit dem einfacheren Fall eines 24/7 Betriebes und der Frage, nach wie vielen Monaten sich der Savings Plan „gelohnt hat“ (also die Gesamtkosten durch den Savings Plan geringer sind, als wenn die Laufzeit zum regulären Pay-per-Use Preis bezahlt worden wäre).

Wir können sehen, dass auch hier das Bild über die 3 VM-SKUs ziemlich gleich ist. Dabei

• …lohnt sich der einjährige Savings Plan nach ca. 9-10 Monaten…
• …lohnt sich der dreijährige Savings-Plan nach ca. 19-20 Monaten…

…im Vergleich zu Pay-per-Use.

Im Vergleich zwischen durchgehendem dreijährigem Savings Plan und einjährigem Plan plus Restzeit mittels Pay-per-Use ist der dreijährige Plan nach ca. 22-23 Monaten günstiger.

Wenn man in Betracht zieht, 2 Jahre hintereinander einen einjährigen Plan zu buchen, dann lohnt sich das in der Regel ab 19 Monaten (gelb markiert) im Vergleich zu Pay-per-Use. Und dann ist der 3-jährige Plan auch erst nach ca. 26 Monaten die bessere Option – bis dahin wären 2 Jahre im einjährigen Plan und der Rest in Pay-per-use günstiger. Jedoch lohnen sich im Vergleich zum nur für ein Jahr laufenden einjährigen Plan die 2 Jahre erst nach ca. 22 Monaten (Summe der beiden dunkelgrünen Felder und deren Monate vs. gelbe Felder)!

Man könnte also sagen:

• Bei einer geplanten Laufzeit ab ca. 26 Monaten ist der beste Weg der Savings Plan für 3 Jahre
• Bei einer geplanten Laufzeit zwischen 22 und 25 Monaten ist es sinnvoll, 2 Jahre lang einen einjährigen Plan zu buchen
• Bei einer geplanten Laufzeit zwischen 10 und 21 Monaten bucht man einen einjährigen Plan für ein Jahr – den Rest der Laufzeit zahlt man dann einfach per Pay-per-Use
• Bei einer geplanten Laufzeit von 9 Monaten oder weniger ist Pay-per-Use der besser Weg

Wenn wir uns nun der zweiten Frage, nämlich ab wie vielen Stunden täglichen Betriebes über die gesamte Laufzeit sich welcher Plan lohnt, dann sieht es folgender Maßen aus:

Hier können wir sehen, dass…

• …es für einen einjährigen Plan ca. 18h…
• …es für einen dreijährigen Plan ca. 13h…

…täglich sein müssten.

Auch hier gilt also, dass man problemlos auch dann noch gut mit einem Savings Plan fährt, wenn man die Systeme für einige Stunden am Tag ausschaltet („Snoozing“), vor allem beim dreijährigen Plan. Denn in dieser Zeit spart man dann ja auch noch zusätzlich die Kosten für etwaige Betriebssystem-Lizenzen, wenn diese nicht durch Hybrid Benefit abgedeckt sind.

Weiterhin gilt auch hier, dass, sobald wir mehr als nur das eine angenommene System haben, die Amortisierung in der Regel noch früher eintritt. Dennoch rate ich auch beim Savings Plan dazu, nicht alle vorhandenen Systeme damit abzudecken, um noch etwas Flexibilität zu erhalten!

Fazit

Mit Savings Plans lassen sich im Vergleich zu Pay-per-Use gute Ersparnisse erzielen. Auch wenn die Rabatte im Vergleich zu Reservierungen zum Teil deutlich geringer sind – man bekommt dafür etwas mehr Freiheiten bei der Nutzung. Und auch wenn man sich nicht auf eine konkrete VM-SKU festlegen muss – eine Optimierung (insbesondere Rightsizing) sollte vor dem Buchen der Savings Plans erfolgen, damit man keine zu hohen Beträge verbindlich fixiert, unter die man dann später auch durch Optimierungen nicht mehr drunter kommt.

• Rightsizing, also das Verwenden der für die benötigte Leistung optimalen Größe
• Hybrid Benefit, also das Einbringen von bereits vorhandenen oder explizit zu diesem Zweck erworbenen Lizenzen
• Reservierungen (siehe unten)
• Compute Savings Plans (siehe unten)
• Modernisierung der Anwendung (um dann z.B. statt VMs eher auf PaaS Dienste zurückzugreifen, die sich leichter skalieren lassen)

Bei meinen Kunden spielen dabei in letzter Zeit sehr oft Reservierungen und Savings Plans eine wichtige Rolle in der Betrachtung hinsichtlich Kostenersparnissen. Aber um was handelt es sich hier überhaupt? Und wann lohnt sich das? Diesen Fragen wollen wir in diesem und mindestens einem weiteren Blog-Artikel nachgehen.

Reservierungen

Bei einer Reservierung wird ein konkreter Azure Service in einer definierten Region und einer definierten SKU für einen Zeitraum von einem oder drei Jahren fest gebucht. Dabei spielt es keine Rolle, welche Ressource man damit konkret betreiben will. Man muss also z.B. nicht eine bestimmte VM reservieren, sondern man reserviert eine VM-Instanz in der benötigten Größe. Dafür erhält man dann einen beachtlichen Preisnachlass („Rabatt“). Dieser hängt vor allem von der Laufzeit ab – für 3 Jahre gibt es deutlich mehr Rabatt als für ein Jahr – dafür ist man aber auch länger gebunden.

Man kann sich das Ganze so ähnlich wie mit einem PKW-Parkplatz vorstellen. Im Parkhaus kann man entweder stündlich bezahlen, oder man kann einen Stellplatz für einen längeren Zeitraum zu einem fixen Preis mieten. Wenn man jetzt mal nicht da ist, zahlt man dennoch weiter für den Platz, dafür zahlt man aber im selben Zeitraum weniger, als wenn man die volle Zeit zum Stunden-Tarif bezahlt hätte. Und statt des eigenen PKWs kann auch jederzeit ein anderes Fahrzeug „gleicher Größe“ den Parkplatz nutzen. So ähnlich verhalten sich auch die Reservierungen. Man zahlt fortwährend für eine bestimmte Leistung – unabhängig davon, ob man diese gerade auch wirklich abruft. Dabei muss man einiges beachten:

• Eine Reservierung wird für eine konkrete Region gebucht und kann nur dort verwendet werden
• Eine Reservierung gilt nur für den konkreten Ressourcen-Typ in einer bestimmten Größe („SKU“); Mittels „Instance Size Flexibility“ kann man bei VMs etwas Flexibilität in Bezug auf die Größe erhalten (siehe weiter unten und hier: https://learn.microsoft.com/en-us/azure/virtual-machines/reserved-vm-instance-size-flexibility)
• Da man bei VMs eine konkrete VM-Serie reserviert, legt man sich dabei auch für einen bestimmten CPU-Typ und somit auch für eine bestimmte Hardware-Generation fest; Insbesondere bei 3 Jahren Laufzeit hat man dann irgendwann eben „alte“ Hardware…
• Eine Reservierung muss für einen bestimmten Scope gebucht werden; Das kann eine Resource Group, eine Subscription, eine Management Group oder der sogenannte „Shared“ Scope sein. Dabei gilt: Je „größer“ der Scope ist, desto besser ist die Chance, dass die bezahlte Leistung auch (irgendwo im Tenant) abgerufen wird und somit der bezahlte Betrag nicht unnötig verfällt. Gleichzeitig wird es aber bei größerem Scope auch immer schwerer, die Kosten sauber zu trennen.
• Auch wenn man zur „Abnahme“ und Zahlung der Leistung verpflichtet ist, gibt es keine Garantie, dass Microsoft die Leistung auch tatsächlich bereitstellen kann; Die reservierte Instanz wird also nicht dauerhaft für den Kunden zur Verfügung vorgehalten!
• Reservierungen können vollständig im Voraus („upfront“) oder monatlich bezahlt werden. Die Gesamtkosten sind dabei gleich. Bei monatlicher Zahlung wird immer zum „Monatstag“ (also ganze Monate nach Buchung der Reservierung) der gesamte Betrag für den vollen Monat abgerechnet.
• Azure Reservierungen können aus dem Prepayment (Monetary Commitment) bezahlt werden; Wenn keins vorhanden ist, werden die Kosten einfach zusammen mit der jeweiligen Subscription abgerechnet.
• Die Reservierung einer VM deckt nur die Compute-Kosten ab. Weitere Kosten für OS-Lizenz, Disk, Traffic und co. werden weiterhin ganz normal abgerechnet. (Reservations software costs for Azure – Microsoft Cost Management | Microsoft Learn)
• Reservierungen werden stündlich betrachtet und folgen dem „Use-it-or-loose-it“ Prinzip: Wenn in der betrachteten Stunde im gewählten Scope, der gewählten Region und SKU keine Ressource vorhanden ist, verfällt die reservierte Leistung; Die Stunden können nicht später nachgenutzt werden.

Flexibilität

Eine Reservierung erlaubt trotz der zunächst starren Festlegung einiges an Flexbilität:

• Die konkrete Ressource kann jederzeit geändert werden, solange die Region, der Ressourcen-Typ und die SKU gleich bleiben und sich die neue Ressource weiterhin im Scope der Reservierung befindet
• Der Scope kann bei Bedarf jederzeit angepasst werden
• Hat man statt der „Capacity“ Option die „Flexibility“ Option gewählt, kann man innerhalb einer Gruppe von VMs (In der Regel die gewählte VM-Serie) andere als die konkret gebuchte Größe einsetzen. Dabei wird über ein Punkte-System gearbeitet. Eine gebuchte D4s_v5 Instanz mit 4-Kernen kann dann z.B, genutzt werden, um zwei Instanzen der Größe D2s_v5 (mit je 2 Kernen) zu betreiben.
• Eintauschen der Reservierung gegen einen Savings Plan („Trade-In“)

Neben den genannten Optionen gibt es einige weitere Optionen, die zwischenzeitlich schon abgekündigt waren, dann aber doch wieder ohne konkretes End-Datum verlängert wurden (Self-service exchanges and refunds for Azure Reservations – Microsoft Cost Management | Microsoft Learn):

• Exchange: Eintauschen der reservierten Compute-Leistung gegen vergleichbare Mengen (Kosten) in einer anderen VM-Serie oder anderen Region
• Refund: Rückgabe der Reservierung gegen Rückzahlung noch nicht genutzter Beträge oder entfallen der weiteren Zahlung; Dabei kann die Summe der noch nicht gezahlten oder nicht verwendeten Leistung einen Betrag von 50.000 USD in einem rollierenden 12-Monats-Zeitraum nicht übersteigen. Microsoft behält sich für die Zukunft das Recht vor, für die vorzeitige Stornierung eine Gebühr zu verlangen.

Weitere Tipps zu Reservierungen

• Vor dem Buchen von Reservierungen sollten alle relevanten Ressourcen hinsichtlich der eingesetzten Größe („SKU“) geprüft und ggf. optimiert werden; Nach der Buchung ist eine Optimierung dann nur noch schwer bis gar nicht mehr möglich, da die gebuchte Größe ja weiterhin eingesetzt werden muss.
• Trotz einer vorhandenen Reservierung kann es sinnvoll sein, eine Azure VM temporär abzuschalten, wenn diese nicht benötigt wird („Snoozing“), insbesondere, wenn das Betriebssystem laufende Lizenzkosten verursacht.

Ab wann lohnt sich eine Reservierung

Ab wann sich eine Reservierung konkret lohnt hängt von sehr vielen Faktoren ab. Daher will ich hier mal nur den „ungünstigen“ Fall annehmen – nämlich dass es nur genau eine Ressource in der reservierten Größe gibt und man nicht auf die Optionen Exchange oder Refund zurückgreifen kann oder will. Sobald man mehrere Ressourcen hat, die für die selbe Reservierung in Frage kämen, verschiebt sich der „Break-Even-Point“ noch mehr nach vorne.

Nehmen wir also an, wir haben eine VM einer bestimmten Größe reserviert. Diese soll nun aber nicht für die volle Laufzeit im 24/7 Betrieb genutzt werden. Nach wie vielen Tagen einer 24/7 Nutzung oder ab welcher täglichen Nutzung über den vollen Reservierungszeitraum würde sich die Reservierung noch lohnen? (Gelohnt hat sie sich dann, wenn man am Ende durch das Buchen der Reservierung nicht teurer wird, als wenn man die Ressource während der realen Nutzungszeit zum normalen Pay-per-Use Preis bezahlt hätte).

Dazu nehmen wir mal 3 gängige VM-Größen („SKUs“) zur Berechnung an:

• D8s v5
• B4s v2
• F2s v2

Als Region wird jeweils West Europe verwendet. Wir betrachten bei den Kosten ausschließlich VM Compute, monatlich werden 730 Stunden angenommen. Die Preise sind in Euro, Stand 15.02.2025. Da Reservierungen immer nur monatlich abgerechnet werden können, werden auch nur ganze Monate betrachtet.

Im Folgenden sind zunächst die Kosten bei 24/7 Betrieb von Interesse. Dabei sind in jeder Spalte die jeweiligen Kosten bis zu diesem Monat akkumuliert dargestellt. Der besseren Darstellung wegen werden werden nur die relevanten Monate gezeigt. Als Tausender-Trennzeichen wir das Komma verwendet.

Wie man in der Tabelle erkennt, unterscheiden sich die verschiedenen VM-SKUs nur geringfügig. Im Allgemeinen kann man sagen:

• Eine 1-jährige Reservierung lohnt sich nach 7 bzw. 8 Monaten (Blau)
• Eine 3-jährige Reservierung lohnt sich nach 14 Monaten (Rosé)

(Die Spalte ganz rechts zeigt es genauer – den 8. Monat bei einem Jahr braucht es auch nur in einem kleinen Anteil)

Das bedeutet, dass man ab diesem Moment die reservierte VM abschalten könnte und man am Ende dennoch leicht gespart hätte, oder anders gesprochen: Ab diesem Moment ist jeder weitere genutzte Monat dann quasi „kostenfrei“! Somit könnte man, sobald man wenigstens für z.B. 18 Monate Planungssicherheit hat, dennoch problemlos zur 3-jährigen Reservierung greifen, zumindest im Vergleich zum durchgehenden pay-per-use Preis.

Wenn man sich nun die Frage stellt, ob bspw. bei 18 Monaten nicht eine einjährige Reservierung plus 6 Monate pay-per-use besser wäre, dann ist diese Frage natürlich völlig gerechtfertigt. Hier stellt sich also die Frage: Nach wie vielen weiteren pay-per-use Monaten nach einer einjährigen Reservierung hat man den Preis der 3-jährigen Reservierung erreicht.

In unseren 3 Fällen ist das nach 6.45, 6.59 bzw. 6.06 Monaten, also spätestens nach 7 Monaten der Fall. In sofern wäre also spätestens nach 19 Monaten Betrieb eine 3-jährige Reservierung immer der kostengünstigste Weg!
Im Übrigen lohnt es sich dabei auf Grund der hohen Rabatte im 3-jährigen Plan nie, eine einjährige Reservierung von vornherein auf 2 Jahre zu planen – denn die Kosten einer 3-jährigen Reservierung sind auf 3 Jahre bereits knapp geringer als die 1-jährige Reservierung auf 2 Jahre! (gelb markiert bei der einjährigen Reservierung)

Man könnte also sagen:

• Bei einer geplanten Laufzeit ab ca. 19 Monaten ist der beste Weg die Reservierung für 3 Jahre
• Bei einer geplanten Laufzeit zwischen 9 und 18 Monaten bucht man eine einjährige Reservierung – den Rest der Laufzeit zahlt man dann einfach per Pay-per-Use
• Bei einer geplanten Laufzeit von 8 Monaten oder weniger ist Pay-per-Use der besser Weg

Als nächstes wollen wir uns anschauen, bei wie vielen Stunden täglichen Betriebes sich die Reservierung lohnt, wenn die Ressource über die volle Reservierungszeit existiert. Dazu sind dann nur noch die monatlichen Kosten als Berechnungsgrundlage interessant:

Wie man in den Tabellen erkennen kann, lohnt sich:

• die einjährige Reservierung bereits bei knapp über 14 Stunden…
• die dreijährige Reservierung bereits bei ca. 9 Stunden…

…Betrieb pro Tag. Also selbst wenn man die VM täglich 8 Stunden abschaltet (Betrieb z.B. von 06:00 bis 22:00 Uhr), dann lohnt sich auch die einjährige Reservierung immer noch. Die 3-jährige lohnt sich auch noch bei einer Abschaltung von 12 Stunden täglich!

Fazit

Ich denke, dass ich mit beiden Beispiel-Rechnungen zeigen konnte, dass man eine Reservierung auch dann buchen kann (und sollte) wenn man nicht vor hat, die Ressource über die vollen ein oder drei Jahre durchgehend zu betreiben, da die Amortisierung bereits deutlich früher eintritt. Natürlich sollte man eine Reservierung (insbesondere bei größeren Mengen) dennoch nicht ohne gute Planung buchen, auch wenn sich bei größeren Mengen noch ganz andere Effekte ergeben. In jedem Fall würde ich aber davon abraten, 100% der benötigten VMs durch eine Reservierung abzudecken. Hier ginge dann zu viel von der Flexibilität, die Cloud bieten kann, verloren.

Hier nun also die Neuerungen und Änderungen aus Juni 2024:

Neue GA Features

Azure Advisor

• Neue Azure Advisor Empfehlungen für Azure Database for PostgreSQL – Flexible Server. (Azure Advisor – Azure Database for PostgreSQL – Flexible Server)

Azure Database for PostgreSQL

• Online Migration im Migration Service für PostgreSQL Datenbanken. (Migration service in Azure Database for PostgreSQL – Azure Database for PostgreSQL – Flexible Server | Microsoft Learn)

Azure Kubernetes Service (AKS)

• OS Security Patch Channel für Linux-Systeme in AKS-Clustern erlaubt das Einspielen von Sicherheitsupdates, die für AKS getestet wurden. (Auto-upgrade Node OS Images – Azure Kubernetes Service)

Azure Load Testing

• Last-Tests (Load Testing) für Azure Functions, auch mit Debug-Mode (Erstellen von Auslastungstests in Azure Functions – Azure Load Testing und Ausführen eines Auslastungstests im Debugmodus – Azure Load Testing)

Azure Monitor

• Dedizierte Cluster (Dedicated Cluster) für Log Analytics nun auch im Azure Portal (Dedizierte Azure Monitor-Protokollcluster – Azure Monitor)
• Neue built-in Policies und Initiatives für das Aktivieren der Diagnostic Settings von Azure Ressourcen im großen Stil. (Enable diagnostics settings by category group using built-in policies. – Azure Monitor)

Azure Virtual Network Manager

• Azure Virtual Network Manager erlaubt das Konfigurieren von vollvermaschten, direkt verbundenen Netzwerken (auch wenn das bei Hub-and-Spoke oft eher nicht erwünscht ist) (Connectivity configuration in Azure Virtual Network Manager)

Neue Previews

Azure Monitor

• „Summary“-Regeln zum aggregieren von Log Analytics Daten für bessere Kostenkontrolle – bisher aber nur über REST Calls (Aggregieren von Daten in einem Log Analytics-Arbeitsbereich mit Hilfe von Zusammenfassungsregeln (Preview) – Azure Monitor)

Virtual Machines

• Windows Server 2025 als Preview-OS für Azure Virtual Machines. (Gain enhanced security and performance with Windows Server 2025—now in preview)
• Force-Detach zum Erzwingen der Abtrennung einer ZRS Data Disk von einer VM, um diese Disk bei einem lokalen Ausfall schnell an eine andere VM anbinden zu können. (Private Preview: Force detach zone redundant disks during zone outage)

Virtual Machine Scale Sets

• Neue Upgrade-Policies für VMSS mit flexibler Orchestrierung erlauben granulare Steuerung der Anpassung des Scale Sets auch für die Flexible Orchestration. (Verwalten von Upgraderichtlinien für Virtual Machine Scale Sets (Vorschau) – Azure Virtual Machine Scale Sets)

Neue und nahende Retirements

Support

• Das Azure Support Plan Angebot wird nach dem 30. Juni 2024 nicht mehr fortgeführt, EA Kunden müssen sich für einen bezahlten Support-Plan entscheiden, um weiterhin Support zu erhalten. (Enterprise Agreement Support Plan Offer)

Den Podcast findet ihr u.a. hier:

PS: Eric hat die Folge dem Thema „Mental Health“ gewidmet – ein wichtiges Thema! Schaut euch das gerne auch mal an!

https://missionsavealife.org

Neue GA Features

Azure Site Recovery

• Support für Debian 12 sowie Ubuntu 18.04 Pro (Generally available: Azure Site Recovery update rollup 73 – April 2024)

Azure Database for MySQL

• Defender for Cloud unterstützt jetzt den Flexible Server (Generally available: Defender for Cloud supports Azure Database for MySQL – Flexible Server)

Azure Database for PostgreSQL

• Unterstützung für Private Link für den Flexible Server erlaubt die Einbindung in Azure VNETs mittels Private Endpoint (General Availability: Azure Database for PostgreSQL – Flexible Server networking with Azure Private Link)

Azure Red Hat OpenShift

• Terraform Provider für ARO, Bring-your-own NSG, Integration in Azure Monitor und weitere Neuerungen (Azure Red Hat OpenShift April 2024 updates)

Azure Virtual Network Manager

• Security Admin Rule ist jetzt in 45 Regionen verfügbar und erlaubt das zentrale Vorgeben von Netzwerk-Regeln, die vor einer Anwendung von NSGs ausgewertet werden und somit die NSGs „übersteuern“ können. (Azure Virtual Network Manager Security Admin Rule generally available in 45 regions)

Virtual Network

• Azure Virtual Network Encryption ist jetzt in allen Azure Regionen verfügbar (aber nach wie vor nur für ausgewählte Azure VM Series wie Dv4, Dv5, Ev4, Ev5 sowie LSv3 und M-Series) (General availability: Azure Virtual Network encryption availability in all regions)

Neue Previews

Azure App Service

• Load Testing direkt aus dem Azure Portal gegen Azure Apps. (Run Azure Load Testing on Azure App Service web apps)
• Multi-Plan Subnet Join erlaubt es, mehrere App Service Pläne in das selbe Subnet zu integrieren. Bisher war für jeden App Service Plan ein eigenes Subnet notwendig. (App Service virtual network integration multi plan subnet join)

Azure Backup

• Backup und Wiederherstellung für VMs mit Private Endpoint enabled Disks. (Public preview: Backup and restore of virtual machines with private endpoint enabled disks)

Azure Database for MySQL

• Long-term Retention (Langzeitaufbewahrung) von Backups des Flexible Servers für bis zu 10 Jahre statt bisher nur kurzzeitiger Aufbewahrung für maximal 35 Tage. (Public Preview: Long-term retention for Azure Database for MySQL – Flexible Server)

Neue GA Features

Azure Container Apps

• Kostenfreie, verwaltete TLS/SSL Zertifikate für Custom Domains in Container Apps. (Generally Available: Free managed certificates on Azure Container Apps)

Azure Functions

• Azure SQL Trigger, um auf Events in SQL Datenbanken mit aktiviertem Change Tracking zu reagieren. (GA: Azure SQL Trigger support for Azure Functions)

Azure Kubernetes Service (AKS)

• AKS Cost Views erlauben nun Einblicke in die aggregierten Kosten für AKS Cluster und Namespaces sowie das Herunterbrechen der Kosten. (Generally Available: AKS cost views)

App Service

• Automatische Skalierung für Web Apps in App Services inklusive einiger Zusatzfunktionen wie Pre-Warmed-Instances (General Availability: Automatic Scaling for App Service Web Apps)

Azure SQL

• Advance Notification erlauben frühzeitige Information im Falle geplanter Wartungen mit Auswirkungen auf Azure SQL Databases, die nicht das „System Default“ Wartungsfenster benutzen. (Advance notifications for planned maintenance events – Azure SQL Database)

Virtual Machines

• Verbesserte Performance für Standard SSD (Disks unter 8TB haben jetzt bis zu 100MB/s statt 60MB/s (GA: Improved throughput performance on Azure Disks’ Standard SSD)

Neue Previews

Azure Advisor

• Resiliency Review zeigt Empfehlungen aus dem Well-Architected Framework in Bezug auf Verfügbarkeit und Zuverlässigkeit. (Public Preview: Resiliency Review on Azure Advisor)

Azure Container Apps

• Speicherung und Nutzung von TLS/SSL Zertifikaten in/aus Azure Key Vault. (Public preview: Support for Key Vault Certificates in Azure Container Apps)

Azure Database for MySQL

• Azure Database for MySQL – Flexible Server erlaubt jetzt die Langzeitaufbewahrung für Backups für bis zu 10 Jahre. (Public preview: Azure Backup supports long term retention for backup of Azure Database for MySQL– Flexible Server)

Azure Database for PostgreSQL

• Migration Service für Azure Database for PostgreSQL ist GA und erlaubt eine voll-verwaltete Migration von PostgreSQL Daten nach Azure. (General availability: Migration service in Azure Database for PostgreSQL)

Azure Files

• Azure Files als Teil des Storage Accounts erlaubt jetzt die Speicherung von Backups in einem Recovery Services Vault, um die Daten und deren Backups sauber voneinander zu trennen. (Public Preview: Azure Backup enables vaulted backups for Azure Files for comprehensive data protection.)

Azure Functions

Unterstützung für PowerShell 7.4 auf Azure Function Plänen (außer dem Linux Consumption Plan). (Public preview: PowerShell 7.4 support for Azure Functions)

Azure Kubernetes Service (AKS)

• Neue Funktionen in Azure Container Storage für AKS verfügbar inkl. der Möglichkeit, den Speicher je nach Bedarf dynamisch zu skalieren. (Preview: New Features in Azure Container Storage)

Azure SQL

• Maintenance Windows für Azure SQL Database Hyperscale Elastic Pools erlauben eine Steuerung und zeitlicher Eingrenzung der Wartungen durch Microsoft. (Public preview: Maintenance window support for Azure SQL Database Hyperscale elastic pools)

Virtual Machines

• On-demand capacity reservations für spezielle SKUs der Serien Mv3, NCv3 und neuer, NVv2 und neuer und Lsv2 erlauben das Reservieren von Kapazitäten für VMs dieser Größen nach Bedarf. Achtung, hier geht es nicht um „typische“ Reservierungen im Sinne von „Reserved Instances“ sondern um das Reservieren von Kapazitäten, um dann in diese Kapazitäten konkrete VMs deployen zu können und zu wissen, dass die nötige SKU dann auch bereitgestellt werden kann. (Public Preview: On-demand capacity reservations for Specialty SKUs)

Neue und nahende Retirements

Azure Functions

• Support für .NET 6 endet am 12. November 2024 – eine Umstellung auf .NET ist anzustreben. (Retirement: Support for .NET 6 ends on 12 November 2024—upgrade your Azure Functions apps to .NET 8)

Azure Front Door

• Azure Front Door (Classic) ist zum 31. März 2027 abgekündigt und sollte durch Standard oder Premium ersetzt werden. (Azure Front Door (classic) will be retired on 31 March 2027)

Azure Kubernetes Service (AKS)

• Windows Server 2022 als Betriebssystem für Nodes wird mit dem Supportende von K8s 1.34 zum 15. März 2027 auslaufen; Danach muss Windows Server 2025 oder Windows Server Annual Channel genutzt werden. (Retirement notice: Windows Server 2022 will retire with k8s 1.34 in March 2027)

Virtual Machines

• Diverse NC-Serie SKUs laufen zum 31. März bis 30. September 2025 ab, konkret NC24rs_v3, NC6s_v3, NC12s_v3 unnd NC24s_v3. (Standard_NC24rs_v3 virtual machines will be retired on March 31st, 2025 bzw. Standard_NC6s_v3, Standard_NC12s_v3 and Standard_NC24s_v3 Azure virtual machines will be retired on September 30, 2025)

Neue GA Features

Azure Application Gateway

• Nach einer Ewigkeit unterstützt das Application Gateway in der v2 nun endlich IPv6! (Generally available: Application Gateway (v2) IPv6 support)
• Unterstützung für die Verwaltung von TLS Zertifikaten direkt im Azure Portal. (General availability: Listener TLS certificates management in the Azure portal)

Azure Monitor

• Stateful Log Search Alerts werden zum 01.05.2024 GA. In diesem Zusammenhang startet auch das Pricing / Billing für diesen Dienst. (Billing for Azure Monitor stateful log search alerts)

Azure NetApp Files

• Unterstützung für 1TiB als neue minimale Größe eines Capacity Pools, wobei es Einschränkungen für Pools kleiner als 2 TiB gibt. (General Availability: Azure NetApp Files support for 1 TiB capacity pools)

Neue Previews

Azure Backup

• Agentless Multi-Disk Crash-consistent Backup erlaubt das Anlegen von Backups einer Azure VM mit mehreren Festplatten ohne die Installation eines Agenten. Das Backup ist dann zwar nur crash-Konsistent, dafür wird es schneller und mit deutlich weniger Auswirkungen auf die laufende VM angelegt. (Public Preview: Agentless multi-disk crash consistent backup by Azure Backup for VM)

Azure SQL

• Neue Generation („Next-gen“) für den General Purpose Tier mit gesteigerter Storage-Performance zum gleichen Preis wie die bisherige Generation. (Azure SQL Managed Instance Next-gen GP)
• Database Watcher für Azure SQL erlaubt verbessertes Monitoring binnen Minuten. (Public preview: Database watcher for Azure SQL)

Neue und nahende Retirements

App Service

• Support für Node 18 LTS endet zum 30. April 2025. Eine Umstellung auf Node 20 LTS ist angeraten. (Action required: Upgrade your App Service apps to Node 20 LTS by 30 April 2025)

Azure Cost Management

• Unterstützung für den AWS Connector im Azure Cost Management endet am 31. März 2025. Danach müssen Drittanbieter-Tools genutzt werden. (Support for Connector for AWS in Cost Management is ending on 31 March 2025)

Azure Functions

• Unterstützung für .NET 7 endet am 14. Mai 2024 – bestehende Azure Function Apps sollten bis dahin auf .NET 8 umgestellt werden. (Retirement: Support for .NET 7 ends on 14 May 2024—upgrade your Azure Functions resources to .NET 8)

Azure Monitor

• Grafana 9 wird zum 31. August 2024 außer Betrieb gehen. Eine Umstellung auf Grafana 10 sollte bis dahin erfolgen. (Action recommended: Update to using Grafana version 10 for Azure Managed Grafana)

Azure Synapse

• Unterstützung für Apache Spark 3.2 endet am 8. Juli 2024. Ein Upgrade auf 3.3 oder 3.4 wird bis dahin notwendig. (Azure Synapse Runtime for Apache Spark 3.2 End of Support)

Azure Virtual Machine

• Standard_M192idms v2 werden zum 31. März 2027 außer Betrieb gehen, eine Umstellung auf Standard_M176ds_4_v3 wird empfohlen. (Support for Standard_M192idms_v2 will be retired on 31 March 2027)

HDInsight

• A-Serie VMs der Basic und Standard SKU laufen zum 31. August 2024 ab – eine Umstellung auf A v2 wird bis dahin nötig. (Basic and Standard A-series VMs on HDInsight will retire on 31 August 2024)
• HDInsights 4.0 geht zum 31. März 2025 außer Betrieb und muss zeitgerecht durch HDInsights 5.1 ersetzt werden. (Azure HDInsight 4.0 will be retired on 31 March 2025 – migrate your HDInsight clusters to 5.1)

Neue GA Features

Allgemein

• Verzicht auf Erhebung der Data Egress Fee für den Fall, dass der Kunde Azure verlassen möchte – hier zieht Microsoft mit Google und AWS nach und will Kunden die Angst vor einem „Vendor-lock“ nehmen. (Now available: Free data transfer out to internet when leaving Azure | Azure updates | Microsoft Azure)
• Achtung: Für herkömmlichen Egress-Traffic (z.B. Wiederherstellung von on-premises Backups, die in der Cloud lagern) werden weiterhin Gebühren erhoben, nachdem die 100GB/Monat kostenfreies Kontingent erreicht sind
• Reservierungen können nun bei der Buchung mit einer automatischen Verlängerung versehen werden, so dass diese dann nicht mehr auslaufen sondern verlängert werden. Standardmäßig ist die automatische Verlängerung aber deaktiviert. (You can now opt in automatically renew your reservation at time of purchase.)

Azure Kubernetes Service (AKS)

• Unterstützung für bis zu 5000 Nodes im Standard und Premium Tier. Dies führt auch zu deutlich mehr unterstützen Pods. Microsoft spricht von 5000 bis 200.000 Pods pro Cluster! (Generally Available: Azure Kubernetes Service (AKS) support for 5K Node limit by default for standard tier clusters)
• Unterstützung für Kubernetes 1.29 (Generally Available: Kubernetes 1.29 support in AKS)
• Unterstützung für Generation 2 VMs für Windows in AKS – unterstützt jedoch nur Windows Server 2022 und nur bestimmte VM SKUs (Generally Available: Windows Gen 2 VM support in AKS)
• Cost Analysis Add-On für AKS zeigt heruntergebrochene Kosten z.B. pro Cluster oder pro Namespace. (Generally Available: Cost analysis add-on for AKS | Azure updates | Microsoft Azure)

Azure Monitor

• Azure Monitor managed service for Prometheus unterstützt jetzt TLS- und mTLS-basierendes Scraping. (Azure Monitor managed service for Prometheus now supports TLS & mTLS based scraping | Azure updates | Microsoft Azure)
• Azure Monitor managed service for Prometheus ist in 13 weiteren Regionen verfügbar. (Azure Monitor managed service for Prometheus is available in 13 additional Azure regions)

App Service

• Backup und Wiederherstellung über Azure VNET zu Storage Accounts mit Netzwerkbeschränkungen („Firewall“). (General Availability: App Service Backup and Restore over Azure Virtual Network | Azure updates | Microsoft Azure)

Azure Chaos Studio

• Unterstützung für neue Fehler im Event Hub (Generally Available: Azure Chaos Studio supports new fault for Azure Event Hubs | Azure updates | Microsoft Azure)

Azure Database for PostgreSQL

• Neues Log für den Fall eines Major Version Upgrades für Azure Database for PostgreSQL – Flexible Server verfügbar. (General Availability: Major version upgrade logs for Azure Database for PostgreSQL – Flexible Server)
• Neuer Azure Defender for Cloud Plan für Azure Database for PostgreSQL – Flexible Server verfügbar (General Availability: Azure Defender for Microsoft Azure Database for PostgreSQL – Flexible Server)

Azure Functions

• Azure Functions unterstützen jetzt Node.js 20 für Linux und Windows (Generally available: Azure Functions Support for Node.js 20)

Azure SQL

• Zonenredundanz kann nun für Azure SQL DB Hyperscale – Named Replica aktiviert werden (Public Preview: Azure SQL updates for mid-March 2024)
• Zonenredundanz für Azure SQL Managed Instance General Purpose. (Public Preview: Azure SQL updates for mid-March 2024)

Storage Accounts

• Für den Cold-Tier im Blob-Storage gilt jetzt auch ein SLA (Generally available: Service Level Agreements on Azure Blob Storage Cold Tier)

Virtual Network

• Azure Virtual Network Encryption ist nun in deutlich mehr Regionen – darunter auch North Europe und West Europe – verfügbar und erlaubt die transparente Verschlüsselung des Netzwerkverkehrs zwischen VMs und VMSS. (General availability: Azure Virtual Network encryption now in additional regions)

Neue Previews

Azure Container Apps

• Unterstützung für Tomcat (Public Preview: Tomcat support in Azure Container Apps)
• Unterstützung für Managed Java (Public Preview: Managed Java components in Azure Container Apps)
• Verbesserte JVM Memory Defaults (Public Preview: JVM memory fit in Azure Container Apps | Azure)

Azure Kubernetes Service (AKS)

• Unterstützung für Trusted Launch, wenn Gen 2 VMs für AKS eingesetzt werden (Public preview: Trusted launch support in AKS)
• Host-Kontrolle für Network Security Groups erlaubt es AKS, NSGs mit „Allow“ Regeln zu versehen, wenn der AKS Cluster mit einer öffentlichen IP betrieben wird. (Generally Available: Host Network Security Group (NSG) control in AKS)
• Dual-Stack support für Azure CNI erlaubt die Nutzung von IPv4 und IPv6 auf Linux-Nodes und -Pods (Generally Available: Azure CNI overlay dual stack Support in AKS (Linux only))
• Deployment Safeguards für AKS liefern passende Policies, die die Auswirkungen von Bugs und Konfigurationsfehlern minimieren sollen und eine bessere Übersicht über die Umgebung verschaffen. (Public preview: Deployment safeguards in AKS)
• Unterstützung für GPUs in Windows Node Pools (Public preview: Windows GPU support in AKS)

Azure Resource Graph

• Change Actor erlaubt es jetzt auch im Resource Graph, Änderungen nachzuverfolgen, allerdings leider auch hier nur für 14 Tage, dafür aber mit mehr Informationen als im Azure Monitor. (Public preview: Change Actor)

Neue und nahende Retirements

Allgemein

• Azure Classic Administrator Rollen sind zum 31. August 2024 abgekündigt. Dies betrifft vor allem Co-Administratoren und Service-Administratoren. Diese sollten zeitnah durch RBAC-Rollen ersetzt werden. (Azure Classic Administrator roles are retiring on 31 August 2024)

Application Gateway

• Web Application Firewall v2 Configuration ist zum 15. März 2027 abgekündigt und sollte durch WAF v2 Policy ersetzt werden. (Retirement: Support for Application Gateway Web Application Firewall v2 Configuration is ending)

Visual Studio App Center

• Das Visual Studio App Center ist zum 31. März 2025 abgekündigt. Danach werden keine Logins oder API calls mehr angenommen. (Visual Studio App Center retirement)

Neue GA Features

Virtual Machines / Azure Disk

• Encryption at host nun auch für Premium SSD v2 und Ultra Disk in weiteren Regionen verfügbar (u.a. West Europe) – erlaubt transparente Verschlüsselung direkt am Host, so dass die Daten zum Storage verschlüsselt übertragen werden. (General Availability: Encryption at host for Premium SSD v2 and Ultra Disks is now available in more regions)

Azure Kubernetes Service (AKS)

• Für AKS Node Pools können jetzt Capacity Reservations gebucht bzw. zugewiesen werden, um sicherzustellen, dass zeitnah benötigte zusätzliche Kapazitäten dann auch bereitgestellt werden können. (Generally Available: Capacity Reservations support in AKS)

Azure Database for PostgreSQL

• Der Azure Database for PostgreSQL – Flexible Server unterstützt ab sofort die neuen minor versions 16.1, 15.5, 14.10, 13.13, 12.17 und 11.22. Dadurch werden 2 Security Schwachstellen und über 40 Bugs behoben. (General availability: Latest PostgreSQL minor versions supported by Azure Database for PostgreSQL – Flexible Server)

Azure Cosmos DB for PostgreSQL

Für Azure Cosmos DB for PostgreSQL gibt es jetzt Unterstützung für die Azure CLI, um Verwaltungsaufgaben am Cluster, wie Cluster-Anlage, Parameteränderungen, Hinzufügen von Nodes und dergleichen mittels Kommandozeile und somit auch automatisierbar durchzuführen. (General availability: Azure CLI support for Azure Cosmos DB for PostgreSQL)

Neue Previews

Virtual Machines

• Neue Generation von AMD-basierten VMs für die D-, E- und F-Serie – werden alle als v6 bezeichnet, auch bei F-Serie! Die Serien basieren auf unterschiedlichen Typen der  4th Generation AMD EPYC 9004 (Genoa) CPU. Sie unterstützen Azure Boost und haben eine NVMe Schnittstelle fpr schnellen lokalen oder remote Storage. (Public preview: New Generation AMD VMs – Dasv6/Easv6/Fasv6 bzw. Public Preview: New AMD-based VMs with Increased Performance, Azure Boost, and NVMe Support – Microsoft Community Hub) Die VMs tauchen noch nicht im Preisrechner auf, der Pricing API lassen sich aber bereits seit ca. 3 Wochen die Preis entnehmen. Eine D4as v6 wird demnach in West Europe 0,185211€ pro Stunde kosten. Die vergleichbare D4as v5 kostet dort mit 0,363013@ fast das doppelte! Ob die Preis dann aber zur GA nochmal angezogen werden ist unklar. Die Preview steht vorerst nur für East US 2 zur Verfügung.

Azure Advisor

• Neue Well-Architected Framwork Assessments zur Überprüfung einzelner Subscriptions hinsichtlich Verfügbarkeit, Sicherheit, Kosten und co. (Public Preview: Well-Architected Framework assessment on Azure Advisor)

Azure Kubernetes Service (AKS)

• Kubernetes 1.29 wird in Preview für AKS unterstützt. (Public preview: Kubernetes 1.29 support in AKS)
• Betriebssystem-SKU in-place Migration für Linux-Knoten erlaubt eine Migration von einer Linux Distribution zu einer anderen ohne manuelles Neu-Deployment der Nodes. (Public preview: OS SKU in-place migration for Linux nodes)

Azure SQL Database

• Zonen-Redundanz für Azure SQL Database Hyperscale Elastic Pools ist nun in Preview verfügbar (Public Preview: Azure SQL updates for late-February 2024)