Azure Reservations und Azure Savings Plans sind beide Commitment-Rabatte: Sie verpflichten sich zu ein oder drei Jahren Nutzung im Gegenzug für niedrigere Raten als bei nutzungsbasierter Abrechnung. Der Kernunterschied ist, worauf Sie sich festlegen. Eine Azure Reservation verpflichtet Sie auf eine bestimmte Größenfamilie virtueller Maschinen in einer bestimmten Region, was den tiefsten Rabatt kauft, aber die geringste Flexibilität. Ein Azure Savings Plan für Compute verpflichtet Sie auf einen Ausgabenbetrag pro Stunde, der automatisch über Regionen und Compute-Familien hinweg angewendet wird, und tauscht etwas Rabatttiefe gegen viel Flexibilität. Reservierungen passen zu stetigen, gut bekannten Workloads, die sich nicht bewegen werden; Savings Plans passen zu Workloads, deren Form sich immer wieder verschiebt. Was Sie auch wählen, dimensionieren Sie zuerst richtig, denn ein Commitment-Rabatt senkt nur die Rate, nicht die darunterliegende Verschwendung.
Das ist die kurze Antwort. Der Rest dieses Leitfadens behandelt, wie jede Option funktioniert, den Kompromiss zwischen ihnen, wie sie sich mit Azure Hybrid Benefit stapeln und den einen Fehler, der mehr verschwendet, als beide sparen können.
Wie Azure Reservations funktionieren
Eine Azure Reservation, manchmal auch reservierte Instanz genannt, verpflichtet Sie für eine bestimmte Konfiguration auf einen Zeitraum von einem oder drei Jahren. Für virtuelle Maschinen legen Sie sich auf eine Größenfamilie in einer Region fest, zum Beispiel eine Maschine der D-Serie in UK South, und erhalten im Gegenzug eine rabattierte Rate auf die passende Nutzung. Reservierungen sind ein Abrechnungskonstrukt: Sie ändern den Preis, den Sie zahlen, nicht die Art, wie die Ressource läuft. Drei Mechaniken sind wichtig, wenn Sie eine kaufen.
Scope. Eine Reservierung kann auf einem einzelnen Abonnement, einer einzelnen Ressourcengruppe, einem geteilten Scope über alle Abonnements im Abrechnungskontext oder einer Verwaltungsgruppe gelten. Ein geteilter Scope ist der nachsichtigste, denn der Rabatt sucht nach jeder passenden Ressource in der gesamten Umgebung, statt brachzuliegen, wenn ein Abonnement die Nutzung einstellt.
Instanzgrößenflexibilität. Eine für Instanzgrößenflexibilität optimierte Reservierung für virtuelle Maschinen gilt über die Größen in derselben Flexibilitätsgruppe hinweg, nicht nur für die exakte Größe, die Sie gekauft haben. Azure nutzt ein Verhältnis pro Größe, um zu ermitteln, wie weit die Reservierung reicht, sodass eine für eine größere Größe gekaufte mehrere kleinere in derselben Gruppe abdecken kann. Sie geht nicht in eine andere Familie über, sodass eine Reservierung für eine Serie eine andere nicht rabattiert.
Umtausch und Erstattung. Microsoft hat die Umtauschregeln mehr als einmal überarbeitet, bestätigen Sie also die aktuelle Richtlinie, bevor Sie sich darauf verlassen. Serien- und Regionsumtausch für Reservierungen von virtuellen Maschinen, dedizierten Hosts und App Service sollten auslaufen und wurden seither bis auf Weiteres verlängert, mit einer versprochenen Vorankündigung vor jeder Änderung, während die Instanzgrößenflexibilität für virtuelle Maschinen bestehen bleibt. Erstattungen sind möglich, doch das gesamte Commitment, das Sie stornieren können, ist innerhalb eines rollierenden Zwölf-Monats-Fensters pro Abrechnungsscope gedeckelt, sodass eine Erstattung ein Sicherheitsventil ist, kein einfacher Ausstieg. Behandeln Sie eine Reservierung als ein echtes Commitment und prüfen Sie beim Kauf die geltende Richtlinie.
Wie Azure Savings Plans für Compute funktionieren
Ein Azure Savings Plan für Compute verfolgt einen anderen Ansatz. Statt sich auf eine Größe und Region festzulegen, verpflichten Sie sich für ein oder drei Jahre auf einen festen Ausgabenbetrag pro Stunde. In jeder Stunde wendet Azure den Vorteil auf die berechtigte Compute-Nutzung an, beginnend mit dem, was den höchsten Rabatt trägt, bis das stündliche Commitment aufgebraucht ist. Alles über dem Commitment in dieser Stunde wird zu nutzungsbasierten Raten abgerechnet.
Der Vorteil ist breit. Ein Compute Savings Plan gilt für Infrastrukturkosten über viele Dienste hinweg, darunter virtuelle Maschinen, App Service, Container Instances, Container Apps, den Functions Premium Plan und dedizierte Hosts, automatisch über Regionen. Der Reiz ist, dass Sie nicht vorhersagen müssen, in welcher Familie oder Region eine Workload landet; der Savings Plan folgt der Ausgabe.
Zwei Vorbehalte sind wichtig. Der stündliche Vorteil gilt nach dem Prinzip verfallen oder nutzen, sodass eine Stunde, in der Sie unter Ihrem Commitment laufen, diesen Anteil unwiederbringlich lässt, er rollt nicht in die nächste Stunde. Und ein Savings Plan kann nach dem Kauf nicht storniert oder erstattet werden, sodass die Dimensionierung des stündlichen Commitments mehr zählt als bei einer Reservierung. Dimensionieren Sie es anhand eines Rückblicks auf reale Nutzung, was genau das ist, worauf die Empfehlungen von Azure Advisor und im Portal aufbauen.
Eine schnelle Art zu entscheiden: zuerst richtig dimensionieren, reservieren, was stabil und fest ist, und einen Savings Plan für alles nutzen, das sich noch bewegt.
Rabatttiefe gegenüber Flexibilität
Die Wahl zwischen beiden ist ein Kompromiss zwischen Tiefe und Flexibilität. Eine vollständig ausgelastete Reservierung liefert den tiefsten verfügbaren Rabatt, denn Sie haben Microsoft die größte Gewissheit übergeben: eine bekannte Größe, eine bekannte Region, für einen bekannten Zeitraum. Ein Savings Plan gibt etwas von dieser Tiefe auf, um sich automatisch überall dort anzuwenden, wo Ihr berechtigtes Compute läuft.
Die verborgene Variable ist die Auslastung. Eine Reservierung zahlt sich nur aus, wenn die passende Ressource weiterläuft, sodass eine für eine Maschine gekaufte, die Sie später neu dimensionieren, verschieben oder abschalten, den tiefen Rabatt in ein ungenutztes Commitment verpuffen lässt. Ein Savings Plan ist schwerer zu stranden, denn er jagt der Ausgabe nach, statt auf eine bestimmte Maschine zu warten. Der ehrliche Vergleich ist nicht Überschriftsrate gegen Überschriftsrate; es ist die tiefere Reservierungsrate multipliziert mit dem Maß Ihrer Zuversicht, dass die Workload stillhält.
Wann jede passt
Wählen Sie eine Reservierung, wenn eine Workload kontinuierlich und vorhersagbar läuft, ohne erwartete Änderung an Größe, Familie oder Region. Domänencontroller, eine dauerhaft laufende Line-of-Business-Datenbank, eine stetige Anwendungsschicht, die seit einem Jahr ihre Form gehalten hat: Das ist Reservierungsgebiet und dort, wo die tiefsten Azure Commitment-Rabatte landen.
Wählen Sie einen Savings Plan, wenn Workloads dynamisch sind oder sich weiterentwickeln, einen Mix aus Familien oder Compute-Diensten nutzen oder zwischen Regionen wechseln. Wenn Sie nicht sagen können, wo die Ausgabe in sechs Monaten sein wird, absorbiert der Savings Plan diese Unsicherheit auf eine Art, die eine Reservierung nicht kann.
Die meisten Umgebungen sind nicht ganz das eine oder das andere. Ein gängiges Muster ist eine Basisschicht aus Reservierungen über dem stabilen Kern, mit einem Savings Plan, der die variable Schicht darüber abdeckt: Die Reservierungen holen maximale Tiefe aus den Teilen, die sich nie bewegen, und der Savings Plan wischt den Rest auf.
Kombination mit Azure Hybrid Benefit
Weder eine Reservierung noch ein Savings Plan für Compute deckt die Softwarelizenzierung ab; beide rabattieren die Infrastruktur. Hier kommt Azure Hybrid Benefit ins Spiel. Wenn Sie bereits Windows Server oder SQL Server Lizenzen mit Software Assurance halten, erlaubt er Ihnen, sie auf Azure-Workloads anzuwenden und die entsprechende Lizenzgebühr von der Rechnung zu entfernen.
Der wichtige Punkt ist, dass sich diese stapeln. Eine Reservierung oder ein Savings Plan senkt die Compute-Rate; Hybrid Benefit entfernt die Windows- oder SQL-Lizenzkosten auf derselben Ressource. Zusammen genutzt verstärken sie sich, sodass die vollständig optimierte Position bei einer stetigen Windows- oder SQL-Workload in der Regel eine Reservierung plus Azure Hybrid Benefit ist.
Der klassische Fehler: sich festlegen, bevor Sie richtig dimensionieren
Der teuerste Fehler ist, sich festzulegen, bevor die Umgebung richtig dimensioniert ist. Ein Commitment-Rabatt senkt die Rate, die Sie zahlen, nicht die Menge an Ressource, für die Sie zahlen. Legen Sie eine Drei-Jahres-Reservierung auf eine virtuelle Maschine, die doppelt so groß ist, wie sie sein müsste, dann haben Sie kein Geld gespart, sondern einen längeren Vertrag auf Verschwendung unterschrieben.
Microsofts eigene empfohlene Reihenfolge bringt das in Ordnung: zuerst richtig dimensionieren und überdimensionierte oder ungenutzte Ressourcen entfernen, wenig genutzte Reservierungen neu zuweisen oder umtauschen, starre Reservierungen zu flexiblen Savings Plans hin tauschen, wo die Nutzung variabel geworden ist, dann neue Reservierungen für die stabile Baseline kaufen und schließlich Savings Plans hinzufügen, die auf diese optimierte Umgebung dimensioniert sind. Rabatte kommen zuletzt. Bringen Sie die Form in Ordnung, dann kaufen Sie den Rabatt, der zu ihr passt.
Deshalb gehört Azure VM Right-Sizing vor jede Commitment-Entscheidung: Jede Maschine zuerst an ihrer beobachteten Auslastung zu dimensionieren bedeutet, dass die Reservierung oder der Savings Plan, den Sie kaufen, gegen den realen Bedarf bepreist ist, nicht gegen eine Spitze, die nie zurückkehrt.
Was bei der Verlängerung zu tun ist
Commitments enden, und die Verlängerung ist eine Entscheidung, keine Formalität. Reservierungen können sich automatisch verlängern, aber eine Verlängerung wird zu der Rate bepreist, die bei der Verlängerung verfügbar ist, nicht zu der, die Sie ursprünglich festgelegt haben, sie ist also keine Garantie für denselben Deal. Bevor ein Zeitraum überrollt, prüfen Sie die Auslastung erneut, denn eine Reservierung, die vor einem Jahr zur Umgebung passte, zeigt nun vielleicht auf eine Maschine, die neu dimensioniert oder außer Betrieb genommen wurde.
Behandeln Sie die Verlängerung als Chance zur Neuoptimierung: Schalten Sie die automatische Verlängerung dort ab, wo sich die Workload geändert hat, dimensionieren Sie erneut richtig und überdenken Sie die Frage Reservierung gegenüber Savings Plan mit frischen Nutzungsdaten. Eine Workload, die von fest zu variabel gedriftet ist, ist ein Kandidat, hin zu einem Savings Plan zu tauschen, statt sich erneut auf eine Form festzulegen, der sie entwachsen ist.
Wo EtherInsights ansetzt
Zwischen Azure Reservations und Savings Plans zu entscheiden ist für eine Workload unkompliziert und über eine ganze Umgebung hinweg, oder über viele Kunden-Tenants für einen Managed-Service-Provider, schwierig. Das Commitment zahlt sich nur aus, wenn es gegen eine richtig dimensionierte Baseline dimensioniert ist, und diese Baseline ist das, was meist fehlt. EtherInsights ist gebaut, um diese Lücke zu schließen: Es macht überdimensionierte und ungenutzte Azure-Ressourcen sichtbar, sodass Sie richtig dimensionieren, bevor Sie sich festlegen, und verfolgt dann das Vorher und Nachher, sodass die Entscheidung auf Evidenz ruht statt auf einem Bauchgefühl.
Auf der Compute-Seite verwandelt Azure VM Right-Sizing die Auslastung in von Eigentümern getragene Neudimensionierungsmaßnahmen, den Schritt, der stets vor einem Kauf einer Reservierung oder eines Savings Plans kommen sollte. Da Commitment-Rabatte nur ein Hebel sind, lohnt es sich, die weitere Sicht in unserem Leitfaden zur Senkung der Kosten für Microsoft 365 und Azure zu lesen, der Commitments neben die Lizenz- und die ungenutzten Ressourcen daneben stellt, und zu sehen, was EtherInsights über die Umgebung hinweg meldet.
Reservierungen und Savings Plans sind zwei Werkzeuge für zwei Workload-Formen: zuerst richtig dimensionieren, reservieren, was fest ist, den Rest mit einem Savings Plan abdecken, Azure Hybrid Benefit dort hinzufügen, wo die Lizenzen existieren, und den Mix bei jeder Verlängerung erneut betrachten.
Cloud-Kostenoptimierung entdecken, um Ihre Umgebung zuerst richtig zu dimensionieren und dann den Azure Commitment-Rabatt zu kaufen, der tatsächlich zu ihr passt.