Azure Management Groups and Subscriptions - Simply Explained

0:00 Azure is one big tree and most people only ever see the leaves. You click around the portal, build a virtual machine and it works so you never stop to ask what holds it all together. Then your company adds a second subscription and a third, and nobody can say who's paying for what or which rules apply where. Underneath it all sits a structure that decides who controls what, and the moment you can see it, Azure stops feeling random. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Today we're walking that tree from the root down, starting with management groups and subscriptions in plain English. Why Azure turns into a mess without a map. Every Azure story starts the same way with one subscription, one team, and one bill. So everything feels simple.

0:40 Then a project needs its own space, so someone creates a second subscription. A developer who wants to test something without touching production spins up a third. By the time you look up, the marketing team has won, the data team has won, and your tenant holds dozens of subscriptions that nobody can map out. That's the real tension here. Azure isn't hard because the individual pieces are complicated because most of them aren't. It gets hard because the pieces multiply and multiplication without structure turns into noise. Think about what breaks first. Permissions get rebuilt by hand for every new subscription. There's no single place to say that the security team should be able to read everything. Policies get missed, so one subscription quietly allows resources in a region the others block. Cost turns into a mystery, too, because the bill arrives one subscription at a time.

1:23 Nobody is adding it all up in one place. Picture a real week inside one of those companies. A team creates a storage account in a region another team has banned and nobody notices for a month. When someone finally runs an audit, the problem is easy to fix. Finding every gap like it across dozens of subscriptions is where the hours disappear. Microsoft names this exact problem in its own documentation. Management groups, it writes, exist for organizations with many subscriptions. They give you one place to manage access policies and compliance across all of them. That sentence tells you what management groups are for before you ever see one. Governance, by the way, is just the rules and permissions you put on your cloud. Who can create what, where they can create it, and how much it's allowed to cost. With one subscription, you can hold all of that in your head, but with dozens you can't.

2:05 And the mistakes start costing real money. The fix isn't a new service or a clever tool. It's a hierarchy, which is a plain word for putting things in order so you can act on a whole branch at once. Azure gives you one, and it runs from a single point at the top down to the smallest virtual machine. So let's build that map from the ground up, starting with the thing that actually holds your work and pays your bill. The subscription is where your Azure actually lives. A subscription is the center of gravity in Azure, and it wears three hats. The money hat comes first. Every resource you create sits inside a subscription, and every charge attaches to it. When someone asks what a project costs, the honest answer usually starts with which subscription it lives in. The bill arrives per subscription, which is why finance teams care about this layer more than you might expect.

2:47 When the subscription is the unit of billing, the way you organize subscriptions becomes the way your costs show up. Then comes the limits. Hat. Azure puts a ceiling on how much of a given thing you can use, and those ceilings are counted per subscription. You can have up to nine hundred and eighty resource groups inside one, for example. And limits like that are exactly why large workloads sometimes need their own space. A quota is just the maximum amount of something you're allowed to use. The rules hat is the third. Policies and permissions are assigned at a scope, and the subscription is one of the scopes you can choose. Two workloads can sit inside the same company and follow completely different rules as long as they live in different subscriptions. Now here is where it gets interesting. A subscription isn't tied to a region. We tend to picture Azure as a list of places like East US or West Europe, and we assume each subscription belongs to one of them.

3:31 That's not how it works. A subscription is a logical container, so a single one can hold resources spread across several regions at once. The region belongs to the resource, not to the subscription. There's one more detail that beginners almost never know, and it matters for security. Each subscription is linked to exactly one Microsoft Entra Tenant, which is your organization's identity directory. That tenant decides who you are when you sign in. So a subscription is not only a place to put things, it's also the point where your identity and your cloud meet. This is why real companies collect so many subscriptions. They separate production from development, so a mistake in one can't touch the other. They give each workload team its own billing line, so cost is easy to read. They built dedicated platform subscriptions for shared jobs like monitoring, security, networking and identity so those services can follow their own rules.

4:16 You might think more subscriptions means more control, but the opposite is true because more subscriptions means more places for the rules to drift. And there's a rule about where a brand new subscription lands the moment you create it that catches almost everyone off guard. Hold on to that one because it's the key to the layer above. Management groups are the folder above your subscriptions. The shelf above your subscriptions is the management group, and its single job is governance. It never holds a resource of its own. A management group holds subscriptions and other management groups, and that's all it does. Now for that rule I promised every directory has one built in management group at the very top, and its default name is tenant root group. When you create a new subscription, Azure drops it straight into that root group. By default, nobody asks you and it just happens.

4:58 If you've ever created a subscription and wondered why it landed somewhere you didn't choose. That's why the shape of the tree follows a few simple rules. Every management group and every subscription can have only one parent, but a single management group can have as many children as you like. That combination is what makes it a tree instead of a web, everything folds up into one root and there's only one tree per directory, so you can't end up with two disconnected azure worlds inside the same company. The limits are generous. One directory can hold up to ten thousand management groups. The tree can go six levels deep, and that count doesn't include the root level or the subscription level. One management group can hold as many subscriptions as you want. Those numbers matter less than they look. You will almost never approach ten thousand groups, and the real constraint is human, because a tree nobody can explain is worse than a flat one.

5:41 Everybody understands the root group behaves differently from every other group. You can't move it and you can't delete it because it anchors everything else. It's also locked down in a way that surprises people since nobody has access to it out of the box, only a global administrator can elevate themselves to reach it, and once they do, they can hand out roles to others. The caution makes sense, because anything you set at the root applies to every subscription in the entire tenant. Microsoft treats it as a last resort, not a starting point. The honest answer about whether you need any of this is that management groups are optional. With one subscription and one team, you can ignore them completely and nothing breaks. Once you have a handful of subscriptions, though, they stop being optional in practice because they're the simplest way to apply one rule to many subscriptions at once.

6:24 Microsoft's advice is to keep the tree flat. They suggest aiming for three or four levels, and they warn against copying your org chart into a deep, tangled structure. A management group exists to group subscriptions that need the same rules not to draw a picture of your company. So the tree exists and the shape is simple. Now for the part that makes it worth building. Because when you put something at the top, it doesn't stay there. How permissions and policies flow down the tree. The payoff of the whole hierarchy is inheritance, which means that whatever you assign at a higher scope automatically applies to everything below it. Microsoft's own wording is that governance conditions cascade by inheritance to all associated subscriptions. Picture a concrete example. Say you set a policy on a management group that limits virtual machines to a couple of approved regions. You don't touch the subscriptions below it, or the resource groups or the machines.

7:08 You set it once at the top, and it reaches every nested management group, every subscription, and every resource underneath a virtual machine can only be built in the regions you allowed. That idea comes in two flavors, and beginners mix them up all the time. The first is permissions, which Azure calls role based access control or RBac. The second is policy. RBac answers one question which is who is allowed to do this? You assign a role to a person or a group at a scope, and the role inherits down the tree. The VM contributor role is a good example. Assign it on a management group and it does nothing to the management group itself. Because a management group holds no virtual machines, but it inherits to every virtual machine under that group. So a single assignment covers them all and you never rebuild the same permission across a whole branch.

7:50 Policy answers a different question, which is whether something is allowed to exist. A policy definition is a rule written down, and you can bundle several rules into an initiative. So they travel together as one package. Then you assign that rule or package to a scope and everything below inherits it. A small example makes it concrete. A company wants every resource tagged with a cost center, so the finance team can charge the right department. Instead of emailing every team to remember, they assign a modified policy that adds the tag whenever someone forgets and the rule does the reminding for them. The difference between the two is the whole point. RBac is about who can act, and policy is about what is allowed to exist. No matter who built it, Microsoft puts it plainly, saying that together, RBac and policy give you full control of a scope, even when you personally have permission to create something, a policy can still block it if it breaks the rules.

8:36 Two details are worth knowing, so nothing surprises you later. You can assign a policy at the management group level, but only resources at the subscription level or lower actually get checked because the rule is inherited from above and evaluated further down. Policy is also a deny system, which means that if a rule at the top says no, a friendlier rule lower down can't override it. To loosen things up, you have to exempt that lower scope from the strict rule. And that design is deliberate because it stops a lower level from quietly undoing a company wide guardrail. Policies can do more than block two. A rule can simply audit and flag a problem without stopping anything. It can modify a resource to add a missing setting, or it can deploy a related resource that should exist alongside the one being created.

9:17 You don't need to memorize those, but it helps to know that policy isn't only a wall, it can also be a helping hand. So that's the mechanism. You set the rules once high up and the tree carries them down for you. But that's only half the story, because a hierarchy you design badly is just a tidier version of the same mess. So let's look at what a good one actually looks like, what a good structure actually looks like. When you want a real answer instead of theory, Microsoft hands you a blueprint called a landing zone. A landing zone is their proven way to govern, secure, and scale an Azure environment that has many subscriptions. It comes in two halves a platform landing zone, and the workload landing zones that sit on top of it. The platform is the shared foundation. It holds the subscriptions everyone depends on like networking, security, monitoring, and identity.

9:58 The workloads are where your actual business systems live, and each team gets its own landing zone. Inside the guardrails, the platform set up. The backbone of the whole thing is a management group hierarchy, and once you've seen it, you'll recognize it everywhere. Under the tenant root group sits an intermediate root group, usually named after the company. Beneath that come four branches, platform, landing zones, sandboxes, and decommissioned. That extra group exists for a practical reason. It gives the organization a place to hold its own structure without ever touching the built in route, so everyday management never has to reach the one group that affects the whole tenant. The platform branch splits into the shared services, each with its own subscription. Security holds the tools the security team watches, and management holds the monitoring and log workspace.

10:38 Connectivity holds the network hub, the firewall, and the private DNS that everything else connects through. Identity is reserved for the domain services that sign people in. Keeping them apart is not tidiness for its own sake. The networking team, the security team, and the identity team all need different rules and separate subscriptions. Let each one get exactly the guardrails it needs. The landing zones branch splits by workload type online is for workloads that face the internet directly, or that don't need a private network at all. Corp is for workloads that need to reach back into the company network. Local is for workloads running on Azure local clusters, which carry different rules than the rest. Microsoft's own note here is reassuring because for a lot of organizations, the default corp online and local groups are a fine place to start.

11:21 Then there are the two special branches. Sandboxes is a dedicated group for experiments kept apart from the corporate and online workloads, and given a lighter set of rules so people can try things without putting production at risk. Decommissioned is where you park a landing zone. You're retiring, and Azure cleans it up after thirty to sixty days. Two habits keep this from turning into a maze. Keep the hierarchy flat and resist the urge to build a branch for every team or every region. Because Microsoft says not to create management groups just to model different regions unless data residency rules force you to. And keep everyday access out of the management groups because policies belong up there. While day to day permissions belong down at the subscription or resource group. That's the shape of a well-run environment, and it's the same skeleton underneath almost every Azure tenant that scales without falling apart.

12:05 Naming cost boundaries and keeping it sane. Two practical questions remain, and they're the ones you'll actually face on day one. The first is what to call these things, and the second is how cost works across the tree. Start with names. Every management group has an ID and that ID is a globally unique string. Basically a long code that you don't get to pick. The display name is yours though, and it's the part humans read. So make it describe what lives inside. Names like platform, identity, or Corp. Tell anyone who opens the portal exactly how the place is laid out. Subscriptions work the same way. That display name is editable, and Microsoft suggests a simple pattern that combines the function and the environment. So you end up with names like marketing, web app production, connectivity, or security. Resource groups follow a similar habit with names like RG webapp Prod, where the prefix says it's a resource group and the rest says what it holds.

12:52 One rule here is firm. Don't put personal, sensitive, or confidential information into resource names or tags. Those strings are visible to more people than you expect, and they're not the place for a customer name or an employee number. Now for cost. Because this is where the hierarchy quietly pays for itself. A management group rolls up the usage costs from every subscription nested underneath it. So you can open one view and see what an entire branch of your company is spending without adding up bills by hand. Say a business unit runs ten subscriptions under one management group, instead of opening ten bills to see what that unit costs. The management group view hands you the total in one place. There's an honest catch and I want you to know it before you trust. A number that roll up covers usage charges, but it leaves out purchases like reservations and third party marketplace items.

13:35 So a management group total and a billing account total can legitimately disagree. Neither one is wrong. They're counting different things. It's also worth knowing that management group scopes aren't supported in cost management for Microsoft customer Agreement subscriptions. So if that's your agreement type, use the billing scope instead. The clean way to remember it is this. The subscription is where a charge is anchored, and the management group is where the view adds up. One is the bill and the other is the report. That's the last piece of the map. So let's pull the whole thing together. A quick recap and one question. So here is the whole tree in one breath management groups sit on top and carry the rules. Subscriptions carry the money, the limits and the identity. Resource groups and resources sit at the bottom where the work lives, and a rule set at the top flows all the way down.

14:17 If you drew your own Azure environment as a tree today with the branches, stay clean or tangle. Subscribe to the M365 FM podcast for more simply explained Microsoft topics.