Cost Management Grundlagen

Ziel: Kosten sind ein Produktmerkmal

Kostenkontrolle funktioniert in Azure nur, wenn sie als Teil des Plattformbetriebs verstanden wird – mit Datenqualität (Tags), Verantwortlichkeiten und regelmäßigen Reviews.

Baustein 1: Struktur für Showback/Chargeback

Zwei Dimensionen sind in der Praxis entscheidend:

• Hierarchie: Management Group / Subscription / Resource Group spiegeln Verantwortlichkeit.
• Metadaten: Tags ergänzen die Hierarchie um Kostenstelle/Owner/Service.

Empfohlene Pflicht-Tags (minimal):

• costCenter
• owner (Team/Verteiler, nicht Einzelperson)
• environment (prod/nonprod)
• application oder service

Wichtig: Tags sind nur dann hilfreich, wenn sie konsistent sind. Ein “Freitext-Tag” ist kein Steuerungsinstrument.

Praktische Ergänzung: Wenn Tags steuerungsrelevant sind, müssen sie auch erzwingbar sein. Das heißt:

• Tagging als Teil der IaC-Standards
• Guardrails über Policy (Audit → Modify/DeployIfNotExists, je nach Reife)
• klare Ownership für Ausnahmen (sonst werden Tags “optional”)

Baustein 2: Budgets und Alerts

Budgets sind nicht nur “Warnungen”, sondern ein Steuerungsmechanismus:

• Budgets pro Subscription/Resource Group je nach Ownership.
• Alerts an Teams + FinOps/Plattform, nicht nur an eine Person.
• Klare Erwartung: Was passiert beim Erreichen von 80%/100%?

In der Praxis lohnt sich zusätzlich:

• Budgets nicht nur auf Subscription, sondern ggf. auch auf Cost Center/Tags auszuwerten (Showback)
• ein definiertes Incident-Playbook bei Anomalien (wer prüft, wer stoppt, wer informiert)

Baustein 3: Kostenanomalien und schnelle Ursachen

Ein realistischer Incident-Check:

• Ist es Usage oder Price (z. B. andere SKU/Region)?
• Sind neue Ressourcen hinzugekommen (Deployments)?
• Läuft etwas “dauerhaft” statt geplant (z. B. Data Factory, Synapse, VM ohne Shutdown)?
• Hat sich Logging/Ingestion verändert (Log Analytics kann schnell teuer werden)?

Häufige “Hidden”-Treiber:

• Datentransfer (Cross-Region/Internet Egress)
• Unbeabsichtigte Skalierung (Autoscale, Premium SKUs)
• Defender/Sentinel/Log-Retention Änderungen

Baustein 4: Savings Plans / Reservations

Für stabile Basiskomponenten lohnt sich Optimierung, aber mit Governance:

• klare Ownership der Commitments
• Reporting über Auslastung (Coverage/Utilization)
• keine Optimierung “auf Verdacht” (sonst finanzielles Risiko)

Prozesse, die wirklich wirken

• Monatlicher Cost Review je Team (Top-Kosten, neue Peaks, Ausnahmen).
• Plattformseitig: Standard-Guardrails (Allowed SKUs/Regions, Diagnostics-Standards) reduzieren unerwartete Kosten.
• Transparente Dashboards (Kosten nach App/Team/Umgebung).

Ein gutes FinOps-Mindestmaß

• Wöchentliche Anomalie-Sichtung (klein, aber regelmäßig)
• Monatlicher Review mit den größten Treibern und konkreten Maßnahmen
• Quartalsweise Commitment-Review (Reservations/Savings Plans) inkl. Utilization