Verwaltungsgruppen und Abonnements

Azure organisiert Ressourcen in einer vierstufigen Hierarchie. An der Spitze stehen Management Groups – Container, die Abonnements für Richtlinien und Zugriffssteuerung im großen Maßstab gruppieren. Darunter befinden sich Subscriptions – Einheiten für Abrechnung und Ressourcengrenzen. Innerhalb der Abonnements liegen Resource Groups – logische Container für zusammengehörige Ressourcen. Auf der untersten Ebene befinden sich Resources – einzelne Dienste wie VMs, Datenbanken und Speicherkonten. Richtlinien und Berechtigungen, die auf höheren Ebenen angewendet werden, werden nach unten weitergegeben.

Ein Azure-Abonnement ist sowohl eine Abrechnungseinheit als auch eine logische Ressourcengrenze. Die gesamte Ressourcennutzung eines Abonnements wird auf einer einzigen Rechnung abgerechnet. Abonnements legen über Kontingente fest, wie viele Ressourcen eines bestimmten Typs bereitgestellt werden können. Organisationen erstellen häufig separate Abonnements für verschiedene Umgebungen (Produktion, Entwicklung, Tests), verschiedene Geschäftsbereiche oder verschiedene geografische Regionen – jeweils mit eigener Kostenberichterstattung und Zugriffssteuerung.

Große Unternehmen verwenden aus mehreren Gründen mehrere Abonnements. Isolation – Produktionsressourcen sind vollständig von Entwicklungs- und Testressourcen getrennt; eine Fehlkonfiguration in der Entwicklungsumgebung kann die Produktion nicht beeinträchtigen. Granularität der Abrechnung – das Abonnement jeder Abteilung erzeugt eine eigene Rechnung und ermöglicht so eine klare Kostenverteilung. Abonnementlimits – Azure verfügt über Kontingente pro Abonnement (z. B. 250 VMs pro Region); große Workloads benötigen möglicherweise mehrere Abonnements, um diese Limits einzuhalten.

Eine Verwaltungsgruppe ist ein Container oberhalb von Abonnements in der Azure-Hierarchie. Sie können Abonnements in Verwaltungsgruppen organisieren und Azure Policy-Definitionen sowie RBAC-Rollenzuweisungen auf der Ebene der Verwaltungsgruppe anwenden. Diese werden auf jedes Abonnement und jede Ressource innerhalb der Gruppe vererbt. Dadurch müssen Sie dieselbe Richtlinie oder Rollenzuweisung nicht auf Dutzende einzelner Abonnements anwenden.

Verwaltungsgruppen können bis zu sechs Ebenen tief verschachtelt werden. Jedes Azure-Verzeichnis verfügt an oberster Stelle über eine einzelne Stammverwaltungsgruppe, der alle anderen Verwaltungsgruppen und Abonnements untergeordnet sind. Eine typische Unternehmenshierarchie könnte so aussehen: Stamm → Unternehmen → Plattform → Produktion → Landing Zones → Abonnements für einzelne Workloads. Richtlinien, die auf der Stammebene angewendet werden, wirken sich auf jedes Abonnement im gesamten Verzeichnis aus.

Zugriffssteuerungszuweisungen auf jeder Ebene der Hierarchie werden nach unten vererbt. Wenn Sie einem Benutzer in einer Verwaltungsgruppe die Rolle „Leser“ zuweisen, erhält er automatisch Lesezugriff auf jedes Abonnement und jede Ressourcengruppe innerhalb dieser Verwaltungsgruppe. Diese Vererbung ist additiv – Sie können eine geerbte Berechtigung auf einer niedrigeren Ebene nicht entziehen, sondern nur weitere Berechtigungen hinzufügen. Ablehnungszuweisungen bilden eine Ausnahme: Sie blockieren Aktionen auch dann, wenn eine Rollenzuweisung diese eigentlich erlauben würde.

Ebenso gelten Azure Policy-Zuweisungen auf der Ebene einer Verwaltungsgruppe für alle Abonnements, Ressourcengruppen und Ressourcen innerhalb dieser Gruppe. Häufig wird eine unternehmensweite Basisrichtlinie auf der Stamm- oder Unternehmensverwaltungsebene zugewiesen, um Standards wie zulässige Regionen, erforderliche Tags oder notwendige Diagnoseeinstellungen in der gesamten Organisation durchzusetzen. Besitzer einzelner Abonnements können darunter spezifischere Richtlinien hinzufügen, ohne die unternehmensweite Basisrichtlinie außer Kraft zu setzen.

Azure-Abonnements können erstellt, umbenannt, gekündigt und zwischen Verwaltungsgruppen verschoben werden. Das Verschieben eines Abonnements in eine andere Verwaltungsgruppe ändert, welche Richtlinien und Rollenzuweisungen dafür gelten. Änderungen an Richtlinien werden sofort auf alle Ressourcen im Abonnement angewendet. Durch das Kündigen eines Abonnements wird das Erstellen von Ressourcen deaktiviert. Nach Ablauf einer Kulanzfrist werden schließlich alle darin enthaltenen Ressourcen gelöscht. Daher sollte diese Aktion nur nach sorgfältiger Planung durchgeführt werden.

Große Organisationen greifen über Abrechnungsvereinbarungen auf Azure zu, die beeinflussen, wie Abonnements strukturiert sind. Ein Enterprise Agreement (EA) stellt Abonnements im Rahmen einer Registrierung mit einem zentralen Abrechnungskonto für große zugesagte Ausgaben bereit. Ein Microsoft Customer Agreement (MCA) ist der moderne Nachfolger und bietet eine stärker auf Self-Service ausgerichtete Abonnementverwaltung. Bei beiden können Sie mit Abrechnungsprofilen und Rechnungsabschnitten die Kosten von Abonnements verschiedener Abteilungen gruppieren.

Jedes Azure-Abonnement verfügt über Dienstkontingente – weiche Grenzwerte dafür, wie viele Ressourcen eines bestimmten Typs pro Region vorhanden sein dürfen. Beispiele für Standardwerte: 20.000 vCPUs pro Region, 980 Ressourcengruppen pro Abonnement und 800 verwaltete Datenträger pro Abonnement. Wenn sich Ihre Workload einem Kontingent nähert, können Sie im Azure-Portal eine Anforderung zur Erhöhung des Kontingents einreichen (Support + Problembehandlung > Neue Supportanfrage). Für eine massive horizontale Skalierung empfiehlt Microsoft, Workloads auf mehrere Abonnements zu verteilen.

Microsoft empfiehlt mehrere bewährte Methoden für den Entwurf von Verwaltungsgruppen. Vermeiden Sie mehr als drei bis vier Verschachtelungsebenen – zu viele Ebenen erschweren die Problembehandlung bei Richtlinien. Erstellen Sie eine dedizierte Plattform-Verwaltungsgruppe für gemeinsam genutzte Dienste (Identität, Konnektivität und Verwaltung), getrennt von Landing-Zone-Workloads. Trennen Sie Produktion und Nichtproduktion in unterschiedliche Verwaltungsgruppen, damit nur für die Produktion geltende Richtlinien (z. B. das Deaktivieren des öffentlichen Internetzugriffs) nicht versehentlich auf Entwicklungsumgebungen angewendet werden.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Die Azure-Ressourcenhierarchie verläuft von Verwaltungsgruppen über Abonnements und Ressourcengruppen bis zu den Ressourcen, Richtlinien und RBAC-Zuweisungen auf Ebene der Verwaltungsgruppe werden auf alle untergeordneten Abonnements vererbt und mehrere Abonnements ermöglichen eine isolierte Abrechnung, die Trennung von Umgebungen und eine Umgehung von Kontingenten auf Abonnementebene. Als Nächstes sehen wir uns Azure Policy im Detail an.