In meinen Azure-Kursen stoßen wir im Bereich Azure-Governance früher oder später immer auf das Thema Kostenmanagement. Hier stellen Teilnehmer häufig die Frage, worin der Unterschied zischen Kostenverwaltung und Abrechnung im Azure Portal liegt.
Bekanntlich können entsprechend autorisierte Nutzer im Azure-Portal von einer Management-Gruppe oder einem Azure-Abonnement im Menü-Abschnitt „Cost Management / Kostenanalyse“ zur Kostenverwaltung abbiegen. Von einer Management-Gruppe aus erreichen Sie nur „Cost Management / Kostenanalyse“ …
… während Sie von einem Azure-Abonnement auch das Abrechnungsmodul erreichen
Kostenanalyse
Jedenfalls zeigt zeigt Ihnen die Kostenanalyse Summen, Diagramme, Budgets usw., aber keine Rechnung. Hierzu benötigen Sie das Blade „Abrechnung“ im Azure-Portal.
Cost Management dient wie der Name schon sagt dem Reporting und versteht sich in erster Linie als eine Reihe von FinOps-Tools, mit denen Organisationen die Microsoft Cloud-Kosten analysieren, überwachen und ggf. optimieren können. Wenn Sie Zugriff auf ein Abrechnungskonto, ein Abonnement, eine Ressourcengruppe oder eine Verwaltungsgruppe haben ist auch das Cost Management verfügbar, entweder m Kontext der Ressourcenverwaltungsfunktionen oder als eigenständiges, für FinOps-Teams optimiertes Tool, mit dem diese die Kosten über mehrere Bereiche hinweg verwalten können.
Das Billing (Abrechnung)
Abrechnung“ (Billing) hingegen ist ein kommerzielles Konstrukt (Vertrag, Invoice, Zahlung) und quasi der Ort, an dem Sie Ihre Konten, Rechnungen und Zahlungen verwalten. Die Abrechnung ist für alle Nutzer zugänglich, die Zugriff auf ein Abrechnungskonto oder einen anderen Abrechnungsbereich haben, z. B. Abrechnungsprofile und Rechnungsabschnitte. Typische Use-Cases, die in/mit „Abrechnung“ verfügbar sind:
- Erstellen und Organisieren von Abonnements zwecks Anpassung von Rechnungen
- Verwalten der Abrechnungsinformationen, z. B. juristische Person, Steuerinformationen und Vereinbarungen.
- Konfigurieren von Zahlungsoptionen und Zahlungsrechnungen.
- Proaktives Überwachen von Kosten mittels Budgets und geplanten Warnungen
- Exportieren der Daten, um Kosten im Azure-Portal, Microsoft 365 Admin Center oder extern zu verwalten.
Wie Cost Management und Billing zusammenhängen
Noch Mal in Kürze: Cost Management stellt eine Reihe von FinOps-Tools bereit, mit denen Sie Ihre Kosten analysieren, verwalten und optimieren können. Billing bietet alle Werkzeuge, die Sie zum Verwalten Ihres Abrechnungskontos und zur Zahlung von Rechnungen benötigen.
Cost Management ist in der Oberfläche von Abrechnungsabonnements, sowie in den Blades von Abonnements und Verwaltungsgruppe im Azure-Portal verfügbar, sodass jeder Verantwortliche jederzeit vollständige Transparenz über die Kosten hat, für die „zuständig“ ist. Sie können daraus Erkenntnisse ableiten und z. B. ihre Workloads optimieren, um die Effizienz zu maximieren.
Die Kostenverwaltung ist zudem auch unabhängig verfügbar, um den Prozess für die Verwaltung von Kosten für mehrere Abrechnungskonten, Abonnements und Verwaltungsgruppen zu optimieren.
EA versus MCA und welche Rolle Verwaltungsgruppen für Abrechnung und Kostenverwaltung spielen
Sprechen wir jetzt über die Rolle von Verwaltungsgruppen. Solche „Management Groups“ in Azure dienen bekanntlich u. a., bzw. in erster Linie als valider „Scope“ in der Azure-Organisationsstruktur „oberhalb“ der Azure-Subscriptions, um mehreren Azure-Abonnement dank Vererbungsmechanismus identische RBAC-Rollen, Azure-Policies oder Tags zuweisen zu können.
Sie spielen aber auch eine wichtige Rollen bei der Kostenverwaltung, da sie die Möglichkeit schaffen, die Kosten auf Management-Group-Ebene zu aggregieren. Hier gibt es deutliche Unterschiede, ob Sie EA-Kunde sind oder ob KMUs, Selbständige bzw. Privatnutzer ihre Azure-Subscriptions über Microsoft Customer Agreement (MCA) beziehen. (CSP ist bei der Abrechnungsbetrachtung im Azure-Portal außen vor. Hier obliegt die Rechnungstellung dem CSP.)
Eine Microsoft-Kundenvereinbarung für eine Einzelperson unterstützt maximal fünf Subscriptions, für ein Unternehmen hingegen bis zu 10.000 Abonnements. Details dazu liefert übrigens die Dokumentation zur Azure-Abrechnung. Aus der stammen auch die beiden folgenden Abbildungen:
Beim Enterprise-Agreement ist ein Abrechnungskonto eine Enterprise Agreement-Registrierung, die Abteilungen und Konten umfasst.
Hier stellt das Abrechnungskonto eine Vereinbarung dar, die ein Kunde für die Verwendung von Produkten und Diensten von Microsoft akzeptiert und umfasst mindestens ein Abrechnungsprofil, dass wiederrum mehrere Abrechnungsabschnitte aufweisen kann.
Jetzt müssen Sie folgendes verinnerlichen: Heute gibt es das Abrechnungs-Modul im Azure-Portal gleichermaßen für EA- wie für MCA-Kunden. Es bietet aber jeweils nicht dieselben Funktionen.
EA-Abrechnungs-Logik
Für EA-Kunden ist und bleibt zunächst die Abrechnungssemantik im EA‑Portal maßgeblich und damit betriebswirtschaftlich relevant. Im klassischen Enterprise Agreement (EA) gibt es eine klar strukturierte kaufmännische Hierarchie, wie oben beschrieben: Diese ist
Enrollment → Department → Account → Subscription
Allerdings ist die EA-Billing-Logik historisch gewachsen. „Früher“ d. h. bevor Microsoft mit der Migration der EA‑Experience ins Azure-Portal begann, war die Sache eindeutig. Billing gab es nur im EA‑Portal (ea.azure.com). Heute ist Billing für EA zwar im Azure‑Portal integriert, funktioniert dort aber (im Unterschied zu MCA) „EA-spezifisch“, d. h. EA‑Administratoren arbeiten im Azure‑Portal mit dem Menü „Cost Management + Billing → Billing scopes“. Dort verwalteten Sie dann „Enrollment“, „Billing Account“, „Enrollment-Einstellungen“ usw. .
Manche Aufgaben bleiben aber EA-spezifisch (Zuweisung von Department Admins, Account Owner Changes etc.). Auch Rechnungen selbst sind EA-spezifisch und hängen weiterhin am EA‑Enrollment, nicht an Azure.
Damit sind für Enterprise-Kunden die beiden Verwaltungs-Bäume „Governance“ (Policy, RBAC, Compliance) und „Cost Analysis“ komplett unabhängig voneinander. Letzteres kann dann zwar auf MG‑Ebene erfolgen, aber nicht die faktische Rechnung.
Das o. e. von Microsoft empfohlene Spiegeln dient primär dem Vermeiden solcher Doppelstrukturen wie
- Billing-Org = EA
- Governance-Org = MG
und fördert damit organisatorischen Klarheit.
Für Enterprise-Kunden stellt sich die Verwaltungssituation also etwa so dar:
|
Bereich |
EA‑Portal |
Azure‑Portal |
|
Vertragsdaten |
Ja |
Ja |
|
Enrollment-Verwaltung |
Ja |
Ja |
|
Billing‑Scopes (EA) |
– |
Ja (modern) |
|
Rechnungen |
Ja |
teilweise → bzw. weiterhin weiter EA-spezifisch |
|
Subscription-Anlage |
Ja |
Ja (für EA Admins) |
|
Governance (MGs, RBAC, Policy) |
– |
Ja |
MCA: Gleiche Logik – aber andere Billing-Bausteine
Beim Microsoft Customer Agreement (MCA) hingegen ist die Vertragslogik moderner. Zitat Microsoft „simplified purchase agreement … doesn’t expire and automatically updates as you add products“, d. h. hier wird Billing typischerweise über …
Billing Accounts → Billing Profiles → Invoice Sections
organisiert und eben nicht über Departments/Accounts wie im EA. Der zentrale Punkt bleibt aber auch hier:
- Die Billing-Struktur (MCA) ist die Rechnungsebene.
- Management-Gruppen dienen auch hier als Governance-Hierarchie oberhalb von Subscriptions, inklusive Vererbung von Policy/RBAC.
- Das Cost Management kann demnach auch hier auf Ebene der Verwaltungsgruppen organisiert werden, um Kosten über mehrere Subscriptions zu aggregieren.
Es ist also auch im MCA-Umfeld sehr sinnvoll, Azure-Subscriptions in Management-Gruppen nach Organisation (Business Unit/Cost Center/Environment) zu strukturieren – damit quasi Governance und Kostenanalyse „auf derselben Landkarte“ stattfinden. Der Hauptzweck von Managementgruppen ist und bleibt aber: Sie sind ein gültiger Governance-Scope oberhalb der Azure-Abonnements für die Vererbung von RBAC und Policies.
Wie sieht es in der Praxis aus?
Bei meinen kleinen und mittelgroßen Kunden beobachte ich indes in der Regel ein Modell, „Billing-Tree“ und „Governance-Tree“ bewusst zu trennen, also
1. Billing-Tree (kommerzielle Sicht)
- EA: Enrollment/Department/Account
- MCA: Billing Account/Profile/Invoice Section
→ Hier liegen: Invoice, Payment, Tax, Rechtsrahmen, Zahlungsinstrumente.
2. Governance-Tree (technische Sicht)
- Tenant Root MG → (Platform/Workloads/Environments/Cost Centers…) → Subscriptions
→ Hier liegen: Policy, RBAC, Compliance, Standardisierung, Landing Zones.
Warum Management-Gruppen für FinOps extrem wertvoll sind, egal EA oder MCA
Wir haben jetzt also herausgearbeitet, das Verwaltungsgruppen (MGs) nichts mit „Billing“ zu tun haben, in der Praxis aber trotzdem einen wertvollen FinOps-Hebel darstellen, weil:
- Cost Analysis steht auf MG-Scope zur Verfügung: Sie aggregieren Kosten über viele Subscriptions hinweg in einem Blick.
- Budgets/Alerts/Exports lassen sich entlang der gleichen Struktur ausrollen, abhängig vom Agreement/Scope-Feature.
- Governance + Cost Alignment: Heißt z. B. eine Management-Gruppe „BusinessUnit‑X“, können Sie dort gleichzeitig:
- Tagging/Policy erzwingen
- RBAC zentral steuern
- Kostenanalyse/Budgets passend auswerten
- Auch das CAF (Cloud Adoption Framework), bzw. ALZ (Azure Landing Zones) empfehlen eine durchdachte, eher flache MG-Struktur und die Nutzung für Policy-Zuweisungen, statt alles in tiefen Bäumen zu duplizieren.
Praxisbeispiel (KMU-tauglich)
Zum Abschluss nun noch ein für KMUs geeignete Struktur, die meine Meinung nach gut funktioniert mit dem Ziel, wenig Overhead bei maximale Klarheit zu implementieren:
Management-Gruppen
Tenant RootPlatform(Identity/Connectivity/Management/Security – falls relevant)WorkloadsProdNonProd
SandboxDecommissioned
Ergänzend dazu erzwingen Sie dann Tags für „Cost Center“, „Owner“ oder „Environment“ per Policy auf Ebene der MG „Workloads". Budgets & Kostenansichten machen Sie dann auf "Prod“ und „NonProd".
Ihr RBAC implementieren Sie dann eher auf der Ebene …
- Plattform-Teams auf
Platform - App-Teams auf ihren Subscriptions oder Ressourcengruppen
.