Cloud-Kosten ohne Blindflug steuern

Vor einiger Zeit habe ich Cost Management für einen Tenant durchgesehen, den ich vorher noch nie angefasst hatte, und eine Standard_D8s_v5 bei durchschnittlich 12 % CPU-Auslastung gefunden. Monatelang hatte niemand hingeschaut. Das war kein Einzelfall, es ist im Grunde der Normalzustand jeder Azure-Subscription, die ich geöffnet habe und bei der niemand aktiv aufpasst. Reden wir also darüber, warum das passiert und was wirklich hilft.

Die Sache ist: Es ist selten ein Preisproblem. Es ist ein Sichtbarkeitsproblem. Der Verbrauch liegt in Cost Management, aber die Entscheidungen, die ihn tatsächlich treiben, Größe, Redundanz, Region, Skalierung, fallen in Architekturmeetings, die nie auf die Rechnung schauen. Wenn jemand im Controlling fragt, warum die Rechnung gestiegen ist, ist die VM, die das verursacht hat, längst produktiv, und alle sind schon beim nächsten Thema.

Ich habe genug Cost-Management-Blades geöffnet, um zu wissen: Die Lösung ist kein einmaliges Cleanup. Sie besteht darin, Kosten in denselben Feedback-Loop einzubauen, den Sie ohnehin für Verfügbarkeit und Security nutzen, etwas, das man laufend mit Tooling beobachtet, nicht einmal im Quartal neu entdeckt. Ich zeige Ihnen, wie ich das angehe.

Kosten sind ein Nebeneffekt technischer Entscheidungen

Jede Architekturentscheidung hat einen Preis, auch wenn ihn niemand aufgeschrieben hat:

• Größe und SKU-Wahl. Die D8s_v5 von oben ist nicht günstig, nur weil sie stabil läuft. Sie ist eine ungenutzte D4s_v5 mit Zusatzkosten.
• Redundanzstufe. GZRS-Storage kostet etwa doppelt so viel wie LRS. Richtig für ein produktives Ledger, Verschwendung bei einem Dev-Container.
• Datenbewegung. Egress- und Cross-Region-Traffic sind die Posten, die man erst modelliert, wenn die Monatsrechnung ohne offensichtlichen Grund springt.
• Aufbewahrung. Log Analytics und Application Insights berechnen pro aufgenommenem GB und pro Aufbewahrungstag. Eine zu ausführliche Diagnoseeinstellung bei den Standard-90-Tagen summiert sich still jeden Monat weiter.
• Absichtlicher Leerlauf. Dev/Test-VMs, die 24/7 laufen, obwohl das Team nur von 9 bis 17 Uhr arbeitet, zahlen für rund 120 ungenutzte Stunden pro Woche und Ressource.

Nichts davon taucht als Posten “schlechte Architektur” auf. Es zeigt sich als eine etwas höhere Zahl in Cost Management, für deren Ursachenforschung niemand Zeit hat. Der einzige Weg, den ich kenne, um das zu erkennen, ist Sichtbarkeit auf Ressourcenebene, nicht nur auf Rechnungsebene.

Eine Kostenbasis statt fünf Tabellen

Eine belastbare Kostenbasis verbindet an einem Ort:

• Azure-Kosten nach Workload, Umgebung und Owner, mit konsistenten Tags
• Abdeckung durch Reservierungen und Savings Plans gegenüber Pay-as-you-go-Ausgaben
• tatsächliche Auslastung (CPU, Memory, Storage-IOPS) pro Ressource, nicht nur provisionierte Größe
• Wachstumsannahmen aus der Roadmap, nicht aus dem Durchschnitt des Vorjahres
• technische und regulatorische Vorgaben, die begrenzen, was überhaupt verändert werden darf (Datenresidenz, Mindestaufbewahrung, HA-SLAs)

In der Praxis heißt das: Cost-Management-&-Billing-Exporte fließen in einen Log-Analytics-Workspace oder ein Power-BI-Modell, konsistent genug getaggt, um ohne manuellen Abgleich nach Owner zu pivotieren. Wenn Sie schnell prüfen wollen, ob diese Tagging-Disziplin hält, nutze ich oft diese Resource-Graph-Abfrage, sie zeigt in Sekunden jede VM ohne Kostenstellen-Tag:

Resources
| where type =~ 'microsoft.compute/virtualmachines'
| where isempty(tags['cost-center'])
| project name, resourceGroup, subscriptionId, location

Einmal pro Woche über die Management Group laufen lassen, und ungetaggte Kosten sind kein Rätsel mehr. Kombiniert mit den Kostenempfehlungen von Azure Advisor (Leerlaufressourcen, unterausgelastete VMs, verwaiste Public IPs, nicht angehängte Disks) entsteht eine Kostenbasis, die sich selbst ehrlich hält, statt in der Woche nach dem Aufbau schon wieder veraltet zu sein.

Pay-as-you-go, Reservierungen und Savings Plans sind nicht derselbe Rabatt im anderen Gewand

Ich sehe diese drei immer noch oft als austauschbar behandelt, dabei verhalten sie sich grundverschieden, und welche die richtige ist, hängt davon ab, wie stabil der Workload wirklich ist.

• Pay-as-you-go ist die Referenz: volle Flexibilität, jederzeit Größe ändern oder löschen, kein Rabatt. Richtig für alles, was sich noch verändert, neue Workloads, Migrationen, kurzlebige Umgebungen.
• Reserved Instances (RI) binden Sie für 1 oder 3 Jahre an eine konkrete VM-Familie und Region. Bester verfügbarer Rabatt, bis zu rund 72 % gegenüber PAYG, aber am wenigsten Bewegungsspielraum: Wechselt der Workload auf eine andere VM-Serie oder Region, greift die Reservierung einfach nicht mehr. Innerhalb derselben Serie lässt sich die Größe tauschen, das nennt sich Instance Size Flexibility, aber die Familie nicht wechseln. Ich greife nur zu RIs, wenn ich sicher bin, dass etwas wirklich stabil ist: Domain Controller, Kerndatenbanken, immer laufende Kernsysteme.
• Azure Savings Plans for Compute binden Sie überhaupt nicht an eine SKU. Stattdessen committen Sie sich auf eine stündliche Ausgabenhöhe auf Subscription- oder Billing-Account-Ebene, und der Rabatt greift automatisch, egal ob die VM wächst, schrumpft, die Familie wechselt oder der Workload zu App Service oder einem geeigneten Container-Dienst wandert. Der Rabatt ist etwas niedriger als bei einer RI, rund 65 % statt 72 %, dafür keine Bindung an eine konkrete Instanz. Das ist mein Standardhebel für alles, was sich noch weiterentwickelt.

Kurz gesagt: Eine RI ist an die VM gebunden, Skalierung außerhalb ihres Bereichs kostet den Rabatt. Ein Savings Plan ist an die Ausgabenhöhe gebunden, Größe und Familie bleiben frei wählbar. Ein Commitment vor dem Rightsizing zementiert nur die Verschwendung zu einem etwas niedrigeren Preis. Erst rightsizen, dann committen, und im Zweifel mit dem Savings Plan anfangen.

Das braucht laufendes Monitoring, keine einmalige Prüfung

Die Größe einer VM ist keine einmalige Entscheidung beim Deployment. Sie sollte laufend an die tatsächliche Last angepasst werden.

• Azure Monitor VM Insights zeigt die CPU-, Memory- und Disk-Kurve über 30 Tage. Bleibt sie dauerhaft unter 30 %, ist die SKU zu groß, egal welcher Commitment-Rabatt obendrauf liegt.
• Azure Advisor macht aus genau dieser Telemetrie automatisch Rightsizing- und Shutdown-Empfehlungen, ohne dass Sie eigene Schwellenwerte definieren müssen.
• Autoscale bei VM Scale Sets und App Service Plans skaliert mit der Last automatisch hoch und wieder herunter, statt dass Sie dauerhaft für die Spitzenlast provisionieren. Das ist der Unterschied zwischen für Black Friday dimensioniert und das ganze Jahr für Black Friday bezahlt.
• Start/Stop-Automatisierung für Dev/Test-VMs, per Azure Automation, Logic Apps oder der Start/Stop-VMs-Lösung, setzt den Feierabend-Leerlauf aus der obigen Liste tatsächlich um, statt ihn nur als gute Absicht stehen zu lassen.

Hochskalieren ist der einfache Teil, das macht jeder, sobald eine Anwendung langsam wird. Was ich bei Teams oft übersehen sehe, ist das Herunterskalieren, sobald die Last wieder sinkt, und genau das bleibt ohne Monitoring und Automatisierung zuverlässig aus.

Ein Regelkreis statt ein Projekt

Ein einmaliges Cleanup bringt ein Quartal Ersparnis und erodiert dann still, weil neue Projekte und neue Workloads die Ausgangslage laufend verändern. Was es langfristig unter Kontrolle hält, ist ziemlich unspektakulär, und genau das ist der Punkt:

1. Budgets und Action Groups in Cost Management, pro Subscription oder Resource Group, damit eine Überschreitung zuerst bei Ihnen einen Alert auslöst, bevor sie eine Eskalation im Controlling auslöst.
2. Anomalieerkennung, die integrierten Alerts von Cost Management oder eine geplante Abfrage gegen den Kostenexport, um eine falsch konfigurierte Autoscale-Regel innerhalb weniger Tage zu erkennen, nicht erst zum Monatsende.
3. Tag-Durchsetzung per Azure Policy, nicht Tagging als höfliche Bitte. Eine deny- oder append-Policy auf cost-center und environment auf Management-Group-Ebene hält die obige Resource-Graph-Abfrage überhaupt aussagekräftig.
4. Ein monatlicher Kostenreview mit einem Owner pro Workload, der Auslastung, Commitment-Abdeckung und Rightsizing-Empfehlungen gemeinsam betrachtet, nicht drei getrennte Reports, die niemand zusammenführt.

Nichts davon ist exotisch. Es ist dieselbe Betriebsdisziplin, die Sie längst auf Verfügbarkeit und Patching anwenden, nur auf die Rechnung gerichtet. Was mir daran gefällt: Der Gewinn ist nicht nur eine kleinere Zahl am Ende der Rechnung, sondern ein Architekturteam, das mit Daten belegen kann, warum ein Workload kostet, was er kostet, und das gezielt verändern kann, statt zufällig.

Öffnen Sie diese Woche mal Ihr eigenes Cost-Management-Blade. Ich wäre ehrlich überrascht, wenn Sie dort nicht Ihre eigene Version dieser D8s_v5 finden.