I’ve always learned to keep things simple and stupid (KISS) wherever possible, although it’s not always feasible. The same goes for Azure governance and management. Azure subscriptions are subject to numerous technical limits which sometimes forces you to spread resources across multiple subscriptions.

Another example: some organizations require subscription-level configurations or policies which conflicts other (sub)divisions or departments, which also leads to having multiple subscriptions. One of the biggest challenges with this kind of sprawl is the overhead in maintaining security and policies.

Luckily, this is where Azure Management Groups comes to the rescue!

Azure Management Groups provides a layer of management above the subscription level in which you can group and organize subscriptions as they are “containers”.

Azure Management Groups hierarchy
Azure Management Groups hierarchy

As you can see, Management Groups provides a simple and powerful way to control access and policies over subscriptions.
The cool thing about Management Groups is the fact they allow RBAC (role-based access control) inheritance over subscriptions. This provides a way to control RBAC top-down rather than assigning access individual on a per-subscription base.

Let’s kick-off with some facts and limits regarding to Management Groups:

Important facts about Management Groups

  • The top of the hierarchy (Root Management Group) is named “Tenant root group”, which enables the highest level of control and therefor cannot be deleted.
    • Each new subscription is automatically assigned to this root level.
    • It’s ID correlates with the Azure AD tenant ID.
  • Each Management Group can have many children.
  • A Management Group can support up to 6 levels of depth (Root level excluded).
  • Access Controls (RBAC) and Policies can be assigned to Management Groups.
  • Management Groups are free to use!

Pretty nice he… of course there are also some limitations:

  • Max. 10.000 Management Groups are supported within a single directory / tenant.
  • Each subscription and Management Group only supports one parent.
  • A hierarchy is bound to a single tenant, and therefore cannot contain subscriptions or groups that are spread across tenants.


The diagram above displays an example of a hierarchy for governance using Management Groups. For example, you can create a hierarchy to create a scope for data center regions, like West Europe. This policy will naturally inherit onto all underlying subscriptions and attached resources, like a VM. Also, the policy cannot be altered at subscription- or resource level, allowing for improved compliance and governance.

A second scenario where you would use Management Groups is to control access to subscriptions. This leverages the RBAC capabilities of Management Groups by letting subscriptions, resource groups and resources itself inherit access controls. A single assignment on Management Group level can enable specific users to have access to specific resources spreaded across subscriptions without having to script or manually update the RBAC assignments.

Getting started

If you’re trying to find a way to simplify your Azure administration, go check it out and try it yourself using this tutorial.

However, keep in mind that, like many other solutions, it’s certainly not a “silver bullet” solution to optimized governance, and you have to think carefully about the architecture every time you start designing Azure-based solutions.

Thanks for reading my blog post! If you have any questions or concerns, please feel free to contact me ;-).