Immer mehr Firmen betreiben einen Teil ihrer IT-Dienste in der Public Cloud, und somit auch bei Microsoft Azure. Dadurch sind die Kosten für Cloud-Ressourcen („Consumption“) zu einem wesentlichen Anteil der IT-Ausgaben geworden. In sofern ist es auch sinnvoll und wichtig, regelmäßig auf die Ausgaben zu schauen und nach Optimierungsmöglichkeiten zu suchen. Hierfür stehen in Azure ganz verschiedene Ansätze zur Verfügung, zum Beispiel:
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
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.
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“)
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.
Da ich es offenkundig nicht mehr schaffe, hier wöchentlich etwas zusammenzufassen, habe ich mich entschieden, den Wetterbericht nur noch monatlich mit den wesentlichen und wichtigen Neuerungen und Entwicklungen fortzusetzen.
Hier nun also die Neuerungen und Änderungen aus Juni 2024:
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)
Dieser Tage war ich bei Eric Berg’s GeekSprech zu Gast und konnte mit ihm über die Migration nach Azure und die damit verbundenen Erfahrungen und Herausforderungen sprechen.
Den Podcast findet ihr u.a. hier:
Viel Spaß beim Reinhören und lieben Dank an Eric für die Einladung!
PS: Eric hat die Folge dem Thema „Mental Health“ gewidmet – ein wichtiges Thema! Schaut euch das gerne auch mal an!
Wie üblich (wenn auch nicht immer pünktlich) möchte ich euch hier wieder die aktuellsten Entwicklungen aus dem Azure Infrastruktur-Umfeld seit dem letzten Wetterbricht aufzeigen…
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)
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)
Bedingt durch den Microsoft MVP Summit in Redmond habe ich es leider nicht geschafft, in den letzten beiden Wochen einen Wetterbericht zu veröffentlichen. Das möchte ich nun heute nachholen. Auf Grund der vielen Neuerungen in den letzten Wochen trenne ich die Artikel aber dennoch auf.
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)
Bedingt durch den Microsoft MVP Summit in Redmond habe ich es leider nicht geschafft, in den letzten beiden Wochen einen Wetterbericht zu veröffentlichen. Das möchte ich nun heute nachholen. Auf Grund der vielen Neuerungen in den letzten Wochen trenne ich die Artikel aber dennoch auf.
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.)
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)
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)
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)
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)
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.
Da es Anfang der Woche noch keine Neuigkeiten gab, habe ich den Wetterbericht diese Woche etwas verschoben. Nun sind es zumindest ein paar wenige News…
Nachträglich hinzugefügte Disks für VMWare VMs können nun zu Azure Site Recovery hinzugefügt werden. Bisher musste dafür der Schutz der VM komplett abgebrochen und neu eingerichtet werden. (Enable replication for added VMware VM data disks)
Neue Previews
Application Gateway
Unterstützung für TLS und TCP Protokolle ist in Public Preview – damit erlaubt das Application Gateway auch Non-HTTP-Anwendungen auf der Basis von TCP und TLS, z.B. SQL, MQTT oder AMQP. Außerdem können eigene Domänen unter dem TLS Zertifikatmanagement des Application Gateways verwendet werden. In beiden Fällen ist ein v2 Gateway nötig. (Public preview: Azure Application Gateway introduces support for TLS and TCP protocols)
Configuration-as-Code erlaubt Anpassungen der Dev Box Umgebungen mittels Code. Somit lassen sich Konfigurationen einfach und mit für Entwickler gängigen Methoden anpassen und Umgebungen exakt nach den Anforderungen bereitstellen. (Public preview: Configuration-as-code customizations in Microsoft Dev Box)
Storage Account
Azure Storage Actions erlaubt ein serverloses Datenmanagement durch eine voll-verwaltete Plattform und No-Code-Experience. Es lassen sich auf einfache Weise Aufgaben definieren, die dann eine Datenverarbeitung z.B. auf Metadaten und Dateieigenschaften erlaubt. Leider steht diese Preview derzeit nur in Kanada und Frankreich zur Verfügung. (Public Preview: Azure Storage Actions — Serverless storage data management)
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Ich, Haiko Hertes (Wohnort: Deutschland), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht mir aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl:
Ich, Haiko Hertes (Wohnort: Deutschland), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht mir aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl:
