Die 5 bewährten Taktiken, die unsere Azure-Kosten um 30 % gesenkt haben

Im Jahr 2017 gab ShareGate 250.000 US-Dollar für Azure aus. Selbst mit einem Azure-MVP in unserem Team, der uns half, die Kosten so niedrig wie möglich zu halten, stieg unsere Rechnung in weniger als 12 Monaten um 45 %.

Wir wussten, dass massive Einsparungen möglich waren, also baten wir unsere Experten, uns eine Liste mit praktischen und effektiven Methoden zur Cloud-Kostenkontrolle zu erstellen, um unsere Azure-Ausgaben zu reduzieren.

Wir haben unsere Ergebnisse in diesem Leitfaden zusammengestellt, damit auch Sie sofort damit beginnen können, potenzielle Azure-Einsparungen in den Umgebungen Ihres Unternehmens zu ermitteln.

Consider B-Series virtual machines

While platform-as-a-service (PaaS) offerings have been gaining significant ground over the past few years, virtual machines—be it for legacy reasons or due to specific software requirements—still represent a large portion of cloud usage.

Cloud-basierte VMs stellen eine Herausforderung in Bezug auf die Kostenkontrolle dar: Sie benötigen in der Regel nur minimale Spezifikationen für den Betrieb und sind oft im Leerlauf mit periodischen Nutzungsspitzen, verursachen aber weiterhin die vollen Kosten, solange sie eingeschaltet sind.

Im September 2017 kündigte Microsoft die Familie der virtuellen Maschinen der B-Serie an, auch bekannt als burstable virtual machines. Diese Maschinen wurden speziell für Workloads entwickelt, die immer verfügbar sein müssen, aber typischerweise im Leerlauf mit gelegentlichen Spitzen in der Nutzung sind. VMs der B-Serie bieten ein erhebliches Kostensenkungspotenzial: zwischen 15 und 55 % des Preises einer entsprechenden Maschine der D-Serie, je nach verwendetem Betriebssystem.

Leseempfehlung: Azure-Kostenspartipps: Dos und Don’ts von Brancheninsidern, von Leigh Ryan

Ich sollte also alle meine vorhandenen VMs in die B-Serie konvertieren und viel Geld sparen?

Vorsicht jetzt! Nicht alle Workloads können blindlings auf die B-Serie umgestellt werden. Sie müssen ein Gleichgewicht zwischen Kosten und CPU-Verbrauch finden. Der B-Serie wird eine bestimmte Grundmenge an CPU-Leistung zugewiesen. Solange die Nutzung unter der Baseline liegt, sammelt die VM Guthaben an, die dann dazu verwendet werden können, CPU-Leistung zu verbrauchen, die über die Baseline hinausgeht. Wenn Ihre virtuelle Maschine jedoch zu CPU-intensiv wird, wird sie auf die Basisleistung gedrosselt, bis genügend Guthaben zur Verfügung steht.

Basiswerte und Guthabengrenzen variieren je nach Größe der einzelnen VM der B-Serie. Außerdem gehen alle angesammelten Credits verloren, wenn die VM abgeschaltet wird. Daher sind VMs der B-Serie wirklich für wenig genutzte oder vorhersehbare Arbeitslasten konzipiert, die jederzeit verfügbar sein müssen.

Um festzustellen, ob Ihre virtuelle Maschine sicher in eine VM der B-Serie konvertiert werden kann, können Sie benutzerdefinierte Skripte wie das Azure-Burst-Check-Skript von Dave Hall ausführen.

Identifizieren Sie ungenutzte Ressourcen und nutzen Sie sie

Dank Azure war es noch nie so einfach, eine neue Umgebung in kürzester Zeit in Betrieb zu nehmen, wenn ein neuer Bedarf in Ihrem Unternehmen besteht. Fast-forward a few years, however, and you’ll start noticing a buildup of resources in your Azure subscription that are likely racking up a hefty bill. It isn’t always easy to tell which workloads are still being used and which ones can safely be decommissioned.

The best solution would be to go back in time and implement a basic cloud asset governance plan. In unserem Leitfaden zur Erstellung eines Cloud Cost Governance-Plans finden Sie einen Überblick über die zu berücksichtigenden Kernelemente: Sichtbarkeit, Eigentum und Berechtigungen, Lebenszyklus und Optimierung – oder, wie wir sie gerne nennen, VOLO.

Zusammenfassend lässt sich sagen, dass Sie für jede Ressource, die Sie erstellen, Folgendes tun sollten:

• Verwenden Sie Tags und andere Strategien, um zu kategorisieren, wie die Ressource verwendet wird (Entwicklung, Test, Produktion usw.))
• Bestimmen Sie einen einzigen Eigentümer für die Ressource (in der Regel die Person, die die Ressource angefordert hat)
• Bestimmen Sie ein Ablauf- oder Überprüfungsdatum für die Ressource (und stellen Sie sicher, dass Sie den Zeitplan einhalten und überflüssige Ressourcen umgehend entfernen)

Wenn Sie diese Informationen haben, ist es viel einfacher festzustellen, ob eine bestimmte Ressource noch benötigt wird und entsprechend zu handeln.

Leseempfehlung: How to start and stop your VMs with Azure Automation, von Antoine Jagueneau

Ich habe keinen Plan zur Kostenkontrolle. Was nun?

Azure bietet Ihnen Zugriff auf eine Reihe von Nutzungsstatistiken, die messen, wie viel Aktivität Ihre Ressourcen erfahren. Diese Werte können über das Azure-Portal, durch Zugriff auf die Azure-API und die Verwendung von benutzerdefiniertem Code oder über eine spezielle Kostenmanagementlösung untersucht werden. Anhand dieser Nutzungszahlen können Sie feststellen, welche Ressourcen nicht mehr (oder deutlich zu wenig) genutzt werden, und entsprechende Maßnahmen ergreifen. Denken Sie auch daran, dass die Verwaltung der Cloud-Kosten ein iterativer Prozess ist, so dass es nie zu spät ist, mit der Arbeit an einem Plan zu beginnen.

Finden Sie die richtige Ressourcengröße

Ein häufiges Problem bei der Erstellung neuer Cloud-Ressourcen ist die Frage nach der richtigen Größe für die Verwendung. Azure bietet eine Vielzahl von Optionen für unterschiedliche Anforderungen (mehr RAM, mehr CPU-Leistung, SSD-Laufwerke, GPUs usw.), aber selbst innerhalb derselben Maschinenfamilie ist die Wahl der richtigen Größe von Bedeutung.

Leseempfehlung: How does Azure VM pricing work? von Leigh Ryan

Wenn Sie es falsch machen, zahlen Sie entweder mehr, als Sie brauchen, während Ihre Maschine im Leerlauf läuft, oder Sie haben am Ende eine Maschine, die zu 100 % mit der CPU ausgelastet ist (oder, noch schlimmer, in den virtuellen Speicher auslagert, weil sie keinen physischen RAM mehr hat). All dies kann sich natürlich erheblich auf die Anwendungsleistung auswirken.

Es ist nicht immer einfach, die Anforderungen eines bestimmten Systems im Voraus zu ermitteln, so dass es verlockend sein kann, sicherheitshalber etwas mehr zu wählen als nötig. Häufig vergisst man es dann und lässt es überdimensioniert, was Monat für Monat zu unnötigen Kosten führt.

Wie kann man das vermeiden? In diesem Artikel stellen wir Ihnen einige Strategien vor.

Am einfachsten können Sie jedoch vermeiden, Geld für unnötigen Ressourcenverbrauch zu verschwenden, indem Sie Ihren Tenant durch ein spezielles Cloud-Optimierungstool überwachen lassen und Sie benachrichtigen, wenn sich die Möglichkeit bietet, eine bestimmte Ressource zu verkleinern, herunterzuskalieren oder anderweitig zu reduzieren.

Wann sollte man herunterskalieren

Wenn Sie glauben, dass dies bei Ihrer Umgebung der Fall sein könnte, keine Panik! Es gibt ein paar einfache Möglichkeiten, um festzustellen, ob Sie eine bestimmte VM verkleinern sollten. Die einfachste Methode ist ein Blick auf die Diagramme für den CPU-Anteil und den Speicheranteil für jede Ressource im Azure-Portal.

Typischerweise verdoppelt sich die Instanzgröße in Azure mit jeder Stufe: Eine S1 hat einen CPU-Kern und 1,75 GB RAM, während eine S2 zwei Kerne und 3,5 GB RAM hat. Dasselbe Muster gilt auch für Datenbankgrößen und DTUs.

Wenn Sie über einen längeren Zeitraum feststellen, dass beide Nutzungsstatistiken unter 50 % liegen, können Sie Ihre Instanz getrost herunterskalieren, ohne sich Gedanken über Leistungseinbußen zu machen.

Warum kann ich die Speichernutzung für meine VM nicht sehen?

Bedauerlicherweise erhalten Sie die Diagramme zum Speicherprozentsatz für virtuelle Maschinen, egal ob klassisch oder verwaltet, nicht direkt nach der Installation. Um auf diese Informationen zuzugreifen, müssen Sie die Überwachung auf Gästeebene aktivieren und die richtigen Leistungszähler überprüfen. Sie sollten insbesondere MemoryCommitted Bytes überprüfen. Mit diesen Informationen sollten Sie in der Lage sein, festzustellen, ob ein Dienst sicher herunterskaliert werden kann oder nicht.

Ungenutzte Festplatten lokalisieren und löschen

Wenn Sie Azure schon eine Weile nutzen, haben Sie wahrscheinlich eine ganze Reihe von virtuellen Maschinen erstellt und gelöscht. Aber Ihre Rechnung wird immer höher, und Sie wissen nicht genau, warum. Ein wahrscheinlicher Schuldiger sind die Speicherplatten, insbesondere die Festplatten für gelöschte virtuelle Maschinen, die immer noch in Ihrem Konto verweilen und Sie Monat für Monat Geld kosten. Dies ist umso wahrscheinlicher, wenn Sie klassische virtuelle Maschinen und nicht die neue ARM-Variante verwendet haben. Der Grund dafür ist ganz einfach: Azure löscht Ihre Festplatten nicht systematisch, wenn Sie eine virtuelle Maschine löschen. Dies soll Sie vor versehentlichem Datenverlust schützen, bedeutet aber auch, dass Sie, wenn Sie nicht aufpassen, weiterhin für Festplatten bezahlen, die Sie nicht mehr benötigen.

Sie können dieses Problem über das Azure-Portal lösen. The procedure will be a bit different depending on whether you’re dealing with managed disks or classic disks.

Managed disks

For managed disks, go to the Azure portal, search for Disks in the search bar, and select „Disks“.

This will display all your managed disks. If the Owner column is empty, it means that the disk is not currently attached to anything and you can probably delete it.

To delete the disk, select the row, go to Overview and click Delete in the top bar.

Classic disks

For classic disks, go to the Azure portal, click in the Search bar up top and search for Disks. Select „Disks (classic)“.

You’ll see all of your disks and a column indicating which VM each disk is currently attached to. If you see a disk that isn’t attached to a VM, you can probably delete it safely.

Deleting classic disks is a bit of a process, as the underlying file (the VHD), which is stored in a storage account, will still be there until you manually remove it. Here are the steps:

1. Click on the classic disk and take note of its Storage account and Media link information

2. Click Delete and confirm

3. Verwenden Sie die Azure-Suchleiste, um das in Schritt 1 notierte Speicherkonto zu finden, und öffnen Sie dann den Bereich Eigenschaften

4. Klicken Sie auf Blobs und wählen Sie dann die Zeile mit dem richtigen Speichercontainer aus

5. Markieren Sie das Kästchen mit dem richtigen Dateinamen und klicken Sie dann im oberen Menü auf Löschen

Vergessene VHDs

Selbst wenn Sie all diese Schritte zur Identifizierung nicht angeschlossener Festplatten befolgen, können Sie dennoch vergessene VHDs übersehen, die im klassischen Speicher vernachlässigt werden. Normalerweise erstellt das Azure-Portal einen „vhds“-Container und legt sie dort in einem Speicherkonto ab. Um sie zu finden, suchen Sie in jedem klassischen Speicherkonto unter Blobs nach einem vhds-Container. Sehen Sie sich innerhalb des Containers die Spalte Lease state für jede Datei an. Wenn dort „Available“ steht, bedeutet dies, dass keine VM diese VHD derzeit verwendet, und Sie können sie bedenkenlos löschen (Sie sollten jedoch immer den Inhalt überprüfen, um sicherzugehen!).

Leverage elastic pool databases

Wahrscheinlich haben Sie Ihr Cloud-Migrationsprojekt damit begonnen, Arbeitslasten, die zuvor vor Ort oder in einem privaten Rechenzentrum gehostet wurden, nach Azure zu verschieben. Ein großer Teil dieser Arbeitslasten verwendete wahrscheinlich SQL Server-Datenbanken, die vor dem Aufkommen der Cloud und der NoSQL-Bewegung das Rückgrat der meisten Softwareprojekte bildeten. Sie haben wahrscheinlich auch bemerkt, dass die Preise für SQL-Datenbanken in Azure ziemlich schnell sehr hoch werden können.

Während Sie früher vielleicht einen einzigen Datenbankserver verwendet haben, um Dutzende, wenn nicht Hunderte von Datenbanken für Ihre verschiedenen Projekte oder Kunden zu hosten, können die Kosten für die Aufteilung dieser Datenbanken in separate Azure-SQL-Datenbanken um Größenordnungen höher sein, als Sie erwartet haben. Das liegt daran, wie Datenbanken in Azure funktionieren. Bei On-Prem waren Sie es gewohnt, dass sich mehrere Datenbanken die begrenzten Ressourcen eines einzigen Servers teilen. Mit Azure SQL verfügt jede Datenbank über eine reservierte Menge an Ressourcen, die Ihnen auch dann in Rechnung gestellt werden, wenn die Datenbank im Leerlauf ist. Das Modell ist ideal, wenn Sie mehrere Datenbanken mit gleichmäßiger, vorhersehbarer Auslastung haben. Wenn Sie jedoch eine große Anzahl von Datenbanken mit einem unregelmäßigen Nutzungsmuster haben, finden Sie den Preis vielleicht nicht so attraktiv. Sie haben dann zwei Möglichkeiten:

• Verwenden Sie eine größere, teurere Datenbankebene, um die Spitzenauslastung der Datenbanken zu bewältigen
• Verwenden Sie eine niedrigere Ebene, um Kosten auf Kosten der Leistung in Spitzenzeiten zu sparen

Um die Ressourcen für alle Datenbanken gemeinsam zu nutzen, waren die ersten Azure-Anwender gezwungen, ihre eigenen virtuellen Maschinen mit installiertem SQL Server zu erstellen und zu warten und im Wesentlichen die Bedingungen zu replizieren, unter denen sie vor Ort oder in einem privaten Rechenzentrum ausgeführt wurden. Diese Methode funktionierte zwar gut, ermöglichte aber nicht den Zugang zu all den großartigen Funktionen, die Azure SQL zu bieten hat, wie z. B.:

• Integrierte Hochverfügbarkeit (keine Konfiguration der Replikation erforderlich)
• Aktive Georeplikation
• Punkt-zu-Punkt-Wiederherstellung

Diese Funktionen sind nicht trivial, um sie selbst zu implementieren, und können eine Herausforderung bei der Wartung darstellen.

Besser: Managed Instances

Azure bietet eine neuere Stufe von SQL-Datenbankdiensten an, die sogenannten Managed Instances, bei denen es sich im Wesentlichen um verwaltete virtuelle Maschinen handelt, die einen SQL Server hosten. Verwaltete Instanzen bieten Ihnen nicht alle Funktionen, die in den Azure-SQL-Einzeldatenbankdiensten enthalten sind, aber Sie müssen sich auch nicht um das Betriebssystem oder die SQL Server-Installation kümmern. Im Grunde erhalten Sie eine virtuelle Maschine, deren Konfiguration und Wartung weitgehend für Sie erledigt wird.

Best: SQL Elastic Pools

Aber es gibt noch eine weitere Option in Azure, um dieses häufige Szenario zu lösen: SQL Elastic Pools. Anstatt eine bestimmte Menge an Ressourcen für eine einzelne Datenbank zu reservieren, können Sie mit SQL Elastic Pools eine Reihe von Ressourcen reservieren und diese auf Hunderte von Datenbanken verteilen. Dieses Modell bietet alle Vorteile von Azure SQL und ermöglicht es Ihnen, sporadische Nutzungsmuster über mehrere Datenbanken hinweg angemessen zu handhaben. Elastische Pools haben sich als unglaublich beliebt erwiesen und sind eine ideale Option für Anwendungen mit mehreren Mandanten.

Allerdings sollten Sie bei der Verwendung von elastischen Pools vorsichtig sein. Wenn Sie eine oder mehrere Datenbanken haben, die wesentlich stärker ausgelastet sind als die anderen Datenbanken in einem Pool, sind Sie möglicherweise gezwungen, eine teurere Elastic-Pool-Stufe zu erwerben, um die Nutzungsspitzen zu bewältigen. In einigen Fällen kann es tatsächlich kostengünstiger sein, diese Datenbanken mit hoher Auslastung in einzelne Datenbankangebote aufzuteilen (sie aus dem Pool herauszunehmen) und für die verbleibenden Datenbanken mit geringerer Auslastung eine kleinere Stufe des Elastic Pools zu bezahlen. Eine gute Faustregel ist die Betrachtung der Datenbank-DTU-Nutzung: Wenn eine einzelne Datenbank zu einem bestimmten Zeitpunkt 40 % oder mehr der DTUs des elastischen Pools verbraucht, können Sie möglicherweise Kosten einsparen, indem Sie sie aus dem Pool abspalten und dann den Pool auf eine weniger teure Ebene herunterstufen.

Wie immer ist das Azure-Portal Ihre Anlaufstelle für die Identifizierung von Datenbanknutzungsmustern.

Time to take action and start saving on Azure

By acting on the five areas outlined in this guide, our team managed to shrink our Azure spend by 30%.

Can you do better?