Wie Sie eine Azure-Verwaltungsgruppenhierarchie entwerfen, ohne Ihr Organigramm zu kopieren

Von Mirko Peters · 2026-10-21

Erfahren Sie, warum die Abbildung Ihres Unternehmensorganigramms in Azure-Verwaltungsgruppen zu Governance-Problemen führt und wie Sie eine skalierbare Cloud-Hierarchie entwerfen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Eine wirksame Azure-Verwaltungsgruppenhierarchie zu entwerfen, gehört für jeden Cloud-Architekten zu den wichtigsten Grundlagenaufgaben. Statt einen weitläufigen Baum zu errichten, der Ihre Berichtsstruktur aus der Personalabteilung nachbildet, gruppiert eine erfolgreiche Cloud-Architektur Abonnements nach gemeinsamen Sicherheits-, Richtlinien- und Compliance-Anforderungen. So gelingt skalierbare Governance ohne administratives Chaos.

Das Wichtigste in Kürze

• Vermeiden Sie es, Unternehmensorganigramme in Ihrem Azure-Verwaltungsgruppenbaum abzubilden. Sonst entstehen unnötiger Verwaltungsaufwand und starre Governance-Engpässe.
• Richten Sie Ihre Azure-Hierarchie an gemeinsamen Regelwerken, Sicherheitsgrenzen und der Durchsetzung von Richtlinien aus, nicht an Berichtslinien.
• Halten Sie Ihren Verwaltungsgruppenbaum flach (idealerweise drei bis vier Ebenen tief), damit er im gesamten Mandanten übersichtlich und wartbar bleibt.
• Nutzen Sie die integrierten Landing Zones platform, corp, online, sandboxes und decommissioned als bewährtes, skalierbares Fundament.

Die Falle der Organigramm-Governance

Wenn Unternehmen erstmals in die Cloud wechseln, liegt es nahe, das Unternehmensverzeichnis oder das Organigramm als Blaupause für die Azure-Architektur zu verwenden. Sie könnten eine oberste Gruppe für das Marketing anlegen, eine weitere für die Finanzabteilung und darunter verschachtelte Untergruppen für jede Unterabteilung. Das wirkt am ersten Tag intuitiv, führt aber schnell zu erheblichen betrieblichen Reibungsverlusten.

Organisationen verändern sich ständig. Abteilungen werden zusammengelegt, umbenannt, ausgegliedert oder alle paar Quartale umstrukturiert. Folgt Ihre Azure-Verwaltungsgruppenhierarchie strikt dem Organigramm, zwingt jede Neuordnung im Unternehmen dazu, auch Ihre Cloud-Infrastruktur umzubauen. Abonnements müssen verschoben werden, Vererbungsmodelle brechen auseinander, und Sicherheitsrichtlinien müssen komplett neu bewertet werden. Noch wichtiger ist: Unterschiedliche Abteilungen haben oft dieselben technischen Governance-Anforderungen. Gruppiert man sie nach personellen statt technischen Grenzen, verfehlt man den eigentlichen Zweck von Verwaltungsgruppen.

Ausrichtung an Regeln, nicht an Personen

Der eigentliche Zweck einer Verwaltungsgruppe besteht darin, einheitliche Regeln, Richtlinien und die rollenbasierte Zugriffssteuerung (RBAC) gleichzeitig über mehrere Abonnements hinweg anzuwenden. Ihre Hierarchie sollte deshalb an betrieblichen Grenzen ausgerichtet sein und nicht an den Berichtsstrukturen des Unternehmens. Fragen Sie sich stattdessen, welche technischen Regeln eine Workload einhalten muss, und nicht, wer das Budget verantwortet.

Erfordert eine bestimmte Gruppe von Workloads eine strikte PCI-Konformität und eine Isolierung vom öffentlichen Internet? Benötigen bestimmte Entwicklungsumgebungen gelockerte Richtlinien, damit Experimente möglich sind? Diese technischen Anforderungen bestimmen Ihre Ordnerstruktur. Wenn Sie Abonnements gruppieren, die identische Compliance-Anforderungen, Sicherheitsbasislinien und Netzwerkverbindungsprofile haben, wird Ihre Governance-Strategie deutlich einfacher zu verwalten.

Das bewährte Landing-Zone-Modell

Damit Sie nicht bei null beginnen müssen, wenn Sie eine Struktur entwerfen, stellt Microsoft eine praxiserprobte Blaupause bereit: die Enterprise-Scale Landing Zone. Diese Referenzarchitektur legt eine saubere, vorhersehbare Hierarchie fest, die sich problemlos über Hunderte von Abonnements skalieren lässt, ohne dass es zu organisatorischer Drift kommt.

Unterhalb der Tenant Root Group und Ihrer unternehmensspezifischen übergeordneten Stammgruppe gliedert sich die Architektur typischerweise in vier Kernzweige:

• Platform: Enthält gemeinsam genutzte Dienste wie Abonnements für Konnektivität, Identität, Sicherheit und Verwaltung.
• Landing Zones: Beherbergt Ihre eigentlichen Geschäfts-Workloads, die häufig in die Gruppen corp (intern ausgerichtet) und online (internetorientiert) aufgeteilt werden.
• Sandboxes: Bietet einen isolierten Bereich, in dem Entwickler und Ingenieure Ideen mit minimalen Schutzvorkehrungen testen können.
• Decommissioned: Dient als vorübergehender Sammelbereich für Abonnements, die außer Betrieb genommen werden, bevor Azure sie endgültig entfernt.

Dieses Layout stellt sicher, dass gemeinsam genutzte Basisdienste, die von spezialisierten Teams wie Netzwerk und Sicherheit betreut werden, vollständig von den täglichen Geschäftsanwendungen getrennt bleiben. Jeder Zweig kann genau die Richtlinien übernehmen, die er benötigt, ohne Einschränkungen in unzusammenhängende Bereiche des Unternehmens zu übertragen.

Die Hierarchie flach und wartbar halten

Eine häufige Falle bei der Implementierung von Azure-Verwaltungsgruppen ist die Überkomplexität. Ingenieure erstellen oft tiefe, mehrstufige Verschachtelungen mit sechs, sieben oder acht Ebenen von Unterordnern, in der Annahme, dass extreme Granularität mehr Sicherheit bedeutet. Tatsächlich erschweren tiefe Hierarchien jedoch die Übersicht und machen die Fehlersuche komplizierter.

Microsoft empfiehlt, den Baum der Verwaltungsgruppen flach zu halten, und begrenzt ihn in der Regel auf drei bis vier Ebenen. Denken Sie daran, dass die Richtlinienvererbung von oben nach unten verläuft und Deny-Zuweisungen, die auf höheren Ebenen festgelegt sind, sich weiter unten nicht ohne explizite Ausnahmen einfach außer Kraft setzen lassen. Ist Ihr Baum zu tief, wird die Ursachenforschung, warum eine bestimmte Ressourcenbereitstellung blockiert wurde, zu einer frustrierenden Schatzsuche.

Achten Sie außerdem auf das Standardverhalten beim Erstellen neuer Abonnements. Jedes neue Abonnement wird automatisch direkt in der Tenant Root Group abgelegt, sofern Sie es nicht ausdrücklich an einer anderen Stelle zuweisen. Da die Stammgruppe Ihren gesamten Mandanten verankert und sich global auf jede Ressource auswirkt, sollten Sie betriebliche Schutzmechanismen einrichten, um neue Abonnements sofort in Ihre strukturierten Landing Zones zu verschieben.

Fazit

Der Entwurf Ihrer Azure-Verwaltungsgruppenhierarchie erfordert einen Perspektivwechsel. Statt sich zu fragen, wie Ihr Unternehmen auf dem Papier aussieht, sollten Sie darauf achten, wie sich Ihre Workloads im Code verhalten. Indem Sie Ihre Cloud-Umgebung um technische Landing Zones statt um menschliche Organigramme herum strukturieren, eliminieren Sie den administrativen Mehraufwand und schaffen ein belastbares Fundament, das sich sauber skalieren lässt.

Wenn Sie eine vollständige, fachchinesisch-freie Erläuterung darüber hören möchten, wie Azure-Verwaltungsgruppen und Abonnements zusammenwirken, um Cloud-Wildwuchs in den Griff zu bekommen, hören Sie sich die vollständige Folge des M365 FM Podcasts an und meistern Sie noch heute Ihre Cloud-Architektur!

Häufige Fragen

Warum sollte ich die Organigramm-Struktur meines Unternehmens nicht in Azure-Verwaltungsgruppen abbilden?

Organigramme ändern sich häufig durch Umstrukturierungen, Übernahmen und Umbenennungen von Abteilungen. Wenn Ihre Azure-Hierarchie Ihren HR-Berichtslinien entspricht, müssen Sie ständig Abonnements verschieben, Richtlinien neu schreiben und Vererbungsmodelle stören. Verwaltungsgruppen sollten sich an betrieblichen Regeln und Sicherheitsanforderungen orientieren, nicht an Personen.

Wie viele Ebenen sollte eine Azure-Verwaltungsgruppenhierarchie tief sein?

Microsoft empfiehlt, den Baum der Verwaltungsgruppen eher flach zu halten, typischerweise mit drei bis vier Ebenen unterhalb der Tenant Root Group. Zu tiefe Strukturen erzeugen ein verworrenes Geflecht aus Vererbung, das sich nur schwer prüfen, fehlerbehebend nachvollziehen und neuen Administratoren erklären lässt.

Was ist der Unterschied zwischen Plattform- und Workload-Verwaltungsgruppen?

Plattform-Verwaltungsgruppen enthalten gemeinsam genutzte Basis-Abonnements wie Konnektivität, Sicherheit, Identität und Überwachung, auf die sich die gesamte Organisation stützt. Workload-Verwaltungsgruppen enthalten die eigentlichen Geschäftsanwendungen und Dienste. Sie sind je nach Netzwerk- und Exponierungsbedarf in Kategorien wie corp, online oder sandbox unterteilt.

Wo landen neu erstellte Azure-Abonnements automatisch?

Wenn Sie ein neues Abonnement in Azure erstellen, ohne dessen Speicherort anzugeben, wird es standardmäßig direkt der Mandantenstammgruppe (Tenant Root Group) zugeordnet. Da globale Regeln, die auf der Stammgruppe angewendet werden, jedes Abonnement im Unternehmen betreffen, empfiehlt es sich, neue Abonnements sofort in passende untergeordnete Verwaltungsgruppen zu verschieben.