One Azure subscription is easy to manage. Ten is manageable with discipline. Fifty, spread across departments that each spin up their own subscriptions, apply their own security practices, and deploy into whatever region is convenient that week, is not something any team manages by hand. Without a structure above the subscription, governance becomes a copy-paste exercise repeated dozens of times, and it inevitably drifts: one subscription gets the policy update, another doesn’t, and nobody notices until an audit or an incident forces the question.<\/p>\n
Azure management groups exist to solve exactly this. They sit above subscriptions in the resource hierarchy and let you apply policy, access control, and budgets once, at a level that every subscription and resource beneath it inherits automatically. This guide covers what management groups are, how inheritance actually works, how they differ from subscriptions and resource groups, how to create them through the portal and through code, and the design mistakes that turn a governance asset into a governance liability.<\/p>\n
An Azure management group is a governance-scoped container that sits above subscriptions in the Azure resource hierarchy. You organize subscriptions into management groups that mirror how your organization actually operates, whether that is by environment, business unit, or compliance boundary, and then apply Azure Policy assignments and role-based access control (RBAC) at the management group level. Every subscription and resource nested beneath that management group inherits the assignment automatically.<\/p>\n
The full Azure resource hierarchy, from broadest to narrowest, looks like this:<\/p>\n