Azure For Beginners

Management Groups, Subscriptions, and Resource Groups: The Azure Hierarchy

gaurav.ece.nitw@gmail.com2 weeks ago1 week ago096 mins

Management Groups, Subscriptions, and Resource Groups: The Azure Hierarchy

A beginner-friendly guide to how Azure organises everything you create, who can do what at each level, how rules and costs flow downward, and how to design a structure that stays tidy as you grow.

Imagine moving into a huge house with thousands of rooms, cupboards, and drawers, all full of things. Without labels, folders, and rules about who holds which key, you would soon lose track of everything. Azure faces the same challenge for every company that uses it. A large business may create tens of thousands of virtual machines, databases, networks, and storage accounts, and hundreds of people need to work with them. Azure solves the problem with a simple tree of containers, called the hierarchy.

At the top of the tree are management groups. Below them sit subscriptions. Below those sit resource groups, and inside those are the resources you actually use. This guide explains each level from the ground up, with no earlier knowledge needed. Every new word is explained when it first appears, with an everyday comparison and a practical example. By the end you will know how the levels fit together, how permissions, rules, and costs travel down the tree, and how to design a structure that works for a small project or a large company.

Limits and features change

Microsoft updates Azure’s limits, features, and recommended tools from time to time. This guide teaches the lasting ideas and uses typical figures as examples. Before making a real design decision, confirm current limits and product status in Microsoft’s official Azure documentation.

1The Big Idea: A Tree With Four Levels

Azure organises everything as a tree. Settings placed higher up automatically apply to everything below.

The four levels in one picture

Azure’s resource organisation has four main levels, from largest to smallest:

2Why Azure Needs a Hierarchy: Four Good Reasons

A tidy structure is not decoration. It solves four serious problems that appear as soon as more than a few people use the cloud.

Reason 1

Control who can do what

Different people need different powers. A developer should manage a test setup but not delete the company’s production database. Containers let you grant access at the right level.

Reason 2

Apply rules consistently

A company may require that data stays in certain regions or that every disk is encrypted. A hierarchy lets one rule cover hundreds of places instead of being repeated by hand.

Reason 3

Understand and split costs

Bills must be traced back to teams and projects. Separate subscriptions and groups make it clear who spent what.

Reason 4

Manage things together

Resources that belong to one application can be created, updated, and deleted together as a group, which keeps cleanup simple.

An example for each reason

Access: a bank’s developers

A bank gives its developers full control of their development subscription, but only read access to production. If a developer makes a mistake, it affects a practice area and not real customers.

Rules: a hospital group

A hospital group requires that all patient data stays inside one country. It sets a policy once, at a high level, that blocks creation of resources in other countries. Every present and future subscription below obeys it automatically.

Cost: a software company

A software company has one subscription per product. At the end of the month, the finance team can see exactly how much each product’s cloud use cost, without sorting through thousands of lines of mixed charges.

Management: a short-lived experiment

A team creates twenty resources to test a new idea in one resource group. When the idea is dropped, they delete the single group, and every resource inside it disappears together.

3Core Concepts: The Words You Need

A small vocabulary makes the whole subject easy. Learn these terms once.

Term	What it means	Everyday comparison
Tenant	A dedicated directory of users and identities, provided by Microsoft Entra ID, that your organisation owns	The company’s staff register
Root management group	The single top container of the tree, created automatically for each tenant	The head office
Management group	A container for subscriptions and other management groups	A regional board
Subscription	A container that carries billing, limits, and access, and holds resource groups	A separate account with its own bill
Resource group	A logical folder that holds related resources	A project folder
Resource	One item you create, such as a virtual machine or a database	One document or machine inside the folder
Scope	The level at which a permission or rule applies	The area a key opens
Inheritance	Settings at a higher level flowing down to lower levels	A company rule reaching every branch
Role-based access control (RBAC)	The system that decides who may do what at each scope	Staff badges with different access
Azure Policy	A system of rules that audits or controls how resources can be created	A building code with inspectors

Two different “who can do what” systems

Beginners often mix up two separate systems. Microsoft Entra ID roles control things about the identity directory itself, such as creating users and resetting passwords. Azure RBAC roles control what people can do to Azure resources, such as creating a virtual machine or reading a database. They are different systems, with different roles and different scopes, even though both are about permissions.

Analogy

In an office building, the human resources department decides who is an employee and who can reset passwords (Entra ID roles). The facilities department decides who can open which doors and use which machines (Azure RBAC). Being an excellent HR manager does not automatically give you the key to the server room.

Tip

When you read an Azure document, notice the word “scope”. It tells you exactly where in the tree a statement applies. Most confusion about permissions and policies disappears once you ask, “At which scope was this set?”

4The Top of the Tree: Tenant and Root Management Group

Above everything sits your tenant, and the single root group created inside it.

The tenant

When an organisation signs up for Microsoft cloud services, it receives a tenant, which is a private directory of users, groups, and applications. The tenant is managed by Microsoft Entra ID. It has a unique identifier and usually a domain name. Every Azure subscription trusts exactly one tenant for sign-in. That is how Azure knows who is a legitimate user of your subscriptions.

The root management group

Azure automatically creates one root management group for each tenant, often shown as “Tenant Root Group”. All other management groups and all subscriptions sit below it. The root cannot be moved or deleted. By default, a person with high rights in the directory does not automatically have access to resources, but they can switch on a special setting to grant themselves access across the whole tree. This is powerful, so it should be used rarely and carefully.

flowchart TB
  T["Tenant: your organisation's identity directory"]
  R["Root Management Group: one per tenant"]
  A["Management Group A"]
  B["Management Group B"]
  S0["Subscription placed directly under root"]
  T --> R
  R --> A
  R --> B
  R --> S0

Every tenant has one root group. Rules placed on the root reach every subscription in the organisation.

Analogy

The tenant is the country’s citizen register, and the root management group is the national government. Everything inside the country falls under its laws, but an ordinary citizen would never be given the power to change those laws casually.

Be careful at the root

A policy or permission placed on the root group reaches everything. A small mistake there can block or expose the whole organisation. Many teams apply only a few, carefully tested, rules at the root and place most rules one or two levels lower.

Default settings

Azure lets you set a default management group for new subscriptions, and lets you require extra permission before anyone can create new management groups. Without these, new subscriptions land directly under the root, and anybody could create groups. Setting them early keeps the tree orderly.

5Management Groups in Depth

Management groups are the highest level you can design yourself. They turn a pile of subscriptions into an organised family.

What they are for

A management group is a container that holds subscriptions and other management groups. Its purpose is to let you apply access rules and policies to many subscriptions at the same time. Without management groups, you would have to repeat the same assignment on every subscription separately, and one forgotten subscription would escape the rule.

The rules of the tree

Each management group and each subscription has only one parent.
A management group can have many children, which may be subscriptions or other management groups.
Management groups can be nested, typically up to six levels deep below the root, not counting the root level or the subscription level.
A single tenant can hold a large number of management groups, in the thousands.
All management groups and subscriptions of a tenant belong to a single tree, with one root.
Management groups hold no resources directly. They hold only subscriptions and other groups.

Analogy

A management group is like a shelf label in a big library. Putting a “Reference only” label on a whole shelf applies to every book on it, now and in the future. You do not need to place the label on each book yourself, and new books added to the shelf are covered at once.

What you can attach to a management group

Access

Role assignments

Give a team a role, such as Reader, over every subscription below, in one step.

Rules

Azure Policy

Apply rules such as allowed regions or required tags to every subscription in the group.

Money

Cost views and budgets

Look at total spending across all subscriptions in the group, and set alerts for it, depending on your billing arrangement.

Overview

Reporting and queries

Search and report across all subscriptions in the group using tools like Azure Resource Graph.

Tip

Management groups work best when they reflect how you govern, not simply how your company chart looks. Group subscriptions that should share the same rules, such as “production” versus “sandbox”, rather than copying every department name.

6Subscriptions in Depth

The subscription is the most important level for beginners, because it is where billing, limits, and access meet.

What a subscription is

A subscription is a logical container, backed by an agreement with Microsoft, in which you create resources. Every resource in Azure belongs to exactly one subscription. Think of it as a separate account with its own bill and its own boundaries.

Three boundaries in one

Boundary 1

Billing boundary

Costs are collected per subscription. Each subscription produces its own charges, so splitting subscriptions splits the bill.

Boundary 2

Access boundary

You can give people access to one subscription and not another. It is a strong dividing line for permissions.

Boundary 3

Scale boundary

Azure sets limits, called quotas, on each subscription, such as the number of processor cores in a region. When a workload grows, a new subscription provides fresh limits.

Kinds of subscription

Subscriptions come with different commercial arrangements. A free account or student offer is for learning. Pay-as-you-go bills your card for what you use. An Enterprise Agreement or a Microsoft Customer Agreement suits large organisations with negotiated terms. A partner-provided subscription is sold through a Microsoft cloud partner. The technical hierarchy works the same way in all of them. Only the billing arrangement differs.

Analogy

A subscription is like a separate mobile phone connection. Each has its own number, its own plan, its own data limit, and its own bill. A family may have several connections under one household, just as an organisation has several subscriptions under one tenant.

The trust relationship

Each subscription trusts one tenant to handle sign-in. Many subscriptions can trust the same tenant, which is the usual case in a company. You can move a subscription to another tenant, but this is a big step, since it changes who can sign in and removes existing role assignments, so plan it carefully.

Real-world example: separate subscriptions per environment

A company creates three subscriptions for one product: development, testing, and production. Developers can do almost anything in development. Only a small, trusted group can change production. The production subscription has its own budget and its own higher quotas. A mistake in development can never exhaust the limits or the budget of production.

Quotas matter

Default limits per subscription, such as the number of cores per region or the number of resource groups, protect you and Microsoft from accidents, but they can block a big launch. Check limits early and request increases well before launch day.

7Resource Groups in Depth

Resource groups are the everyday workhorse of Azure. You will create and delete them constantly.

What a resource group is

A resource group is a logical folder inside a subscription that holds related resources. “Related” usually means resources that share the same life: they are created together, updated together, and deleted together. A typical group holds everything for one application or one environment of an application.

The rules of resource groups

Every resource must be in exactly one resource group.
A resource group cannot contain another resource group. There is no nesting.
Deleting a resource group deletes every resource inside it.
Resources in one group can be in different regions, and can connect to resources in other groups.
The group itself has a location, which is where its information, called metadata, is stored.
Many resource types can be moved between groups and subscriptions, though not all types can.
A subscription can hold many groups, up to a documented limit that is in the hundreds.

Analogy

A resource group is like a labelled box for moving house. You pack all the kitchen items into one box. When you unpack, you open that box and everything is there together. If you throw the box away, everything inside goes too, so you should look carefully before you do it.

The resource group location confusion

The group’s location is separate from the locations of the resources inside. A group labelled “East US” can contain a database in “West Europe”. If the group’s region has an outage, you may be unable to manage the group, such as adding or changing resources, even though the resources themselves keep running elsewhere. For this reason, many teams place the group in the same region as most of its contents.

How to decide what goes together

The best guide is lifecycle. Put resources in one group when they should live and die together. A virtual machine, its disk, its network card, and its public address belong together. A shared network that many applications use belongs in its own group, because deleting one application must not delete the shared network.

Grouping idea	Example	Good when
By application and environment	shop-prod-rg, shop-dev-rg	One team owns the whole application
By tier	shop-web-rg, shop-data-rg	Different tiers change on different schedules
By shared service	network-hub-rg, monitoring-rg	Many applications depend on the same service
By short-lived project	lab-experiment-rg	You want a one-step cleanup

8Resources and Scope: How Azure Names a Place in the Tree

Every item in the tree has an address. Understanding scope turns the address into a tool.

What a resource is

A resource is the actual thing you use. It could be a virtual machine, a database, a storage account, a network, a web app, or a key vault. Each resource has a name, a type, a region, and belongs to one resource group, which belongs to one subscription.

What scope means

A scope is a level at which something applies. Azure has four common scope levels, listed from broadest to narrowest:

Management group scope

Applies to every subscription, resource group, and resource beneath that group.

Subscription scope

Applies to every resource group and resource inside one subscription.

Resource group scope

Applies to every resource inside one resource group.

Resource scope

Applies to a single resource only.

Analogy

Postal addresses work the same way. “India” covers everyone in the country, “Maharashtra” covers a state, “Pune” covers a city, and “Flat 4B, Rose Apartments” covers one home. A notice can be addressed at any of these levels, and the narrower the address, the fewer people it reaches.

Choosing the right scope

Assign things at the narrowest scope that still does the job. A person who only needs to manage one application should receive a role on that application’s resource group, not on the whole subscription.

9Inheritance: How Settings Flow Down the Tree

The great power of the hierarchy is that what you set at the top is automatically true below.

Inheritance means that a setting applied at a higher scope also applies to every scope beneath it, including new things created later. Several important features follow this rule.

flowchart TB
  MG["Management Group: Policy - allowed regions, Role - Security Reader"]
  SUB["Subscription: inherits both, adds Role - Contributor for Team A"]
  RG["Resource Group: inherits all, adds Lock - cannot delete"]
  RES["Resource: inherits everything above"]
  MG -- "flows down" --> SUB
  SUB -- "flows down" --> RG
  RG -- "flows down" --> RES

Assignments accumulate as they move down. A resource experiences the combined effect of every level above it.

Feature	Does it inherit?	What to remember
Role assignments (RBAC)	Yes	A role at a higher scope applies to everything beneath it. You cannot remove an inherited role at a lower level, you must remove it where it was given.
Azure Policy	Yes	Assignments flow down, and you can exclude specific lower scopes from a policy where needed.
Resource locks	Yes	A lock on a group protects every resource within it from deletion or change, depending on the lock type.
Tags	No, by default	A tag on a resource group does not automatically appear on the resources inside. A policy can add or copy tags if you want that.
Budgets and cost views	Roll up	Costs add up from resources to groups to subscriptions, so you view totals at any level.

Analogy

It is like rules in a school system. A national education rule applies to every school. A school rule applies to every class in it. A teacher’s classroom rule applies only to that classroom. A student experiences all of them together, and a classroom cannot cancel a national rule.

Tags are an exception

Many beginners expect tags to flow down like permissions. They do not. If you want every resource to carry its group’s tag, use Azure Policy to add or enforce it, or set tags through your deployment templates.

10Access Control: Roles at Every Level

The hierarchy decides where permissions apply. Roles decide what those permissions allow.

How a role assignment is made

An Azure role assignment joins three things: who receives the access (a user, a group, or an application identity), what they may do (a role), and where it applies (a scope). For example: “the Data Team group (who) is a Reader (what) on the Analytics subscription (where).”

The basic built-in roles

Role	What it allows	Typical use
Owner	Full control, including giving access to others	A very small number of trusted administrators
Contributor	Create and manage resources, but not grant access to others	Engineers who build and run workloads
Reader	View everything, change nothing	Auditors, managers, support staff
User Access Administrator	Manage who has access, but not the resources themselves	Access management teams
Specific roles	Narrow powers, such as managing only virtual machines or only reading storage data	Least-privilege access for specialised jobs

Analogy

In a hotel, the owner can do anything, a manager can run the hotel but not change ownership, an inspector can look but not touch, and the reception staff can only use the booking system. Each badge opens different doors, and the master key is given to very few people.

Good habits for role assignments

Assign to groups, not individuals. When someone joins or leaves a team, you only change group membership.
Use the narrowest scope. Prefer a resource group over a subscription, and a subscription over a management group.
Give the least privilege. Use Reader or a specific role before Contributor, and Contributor before Owner.
Use just-in-time access. A service called Privileged Identity Management lets people activate powerful roles only for a short time, with approval and a record.
Use managed identities for applications. Applications can receive their own identity and roles, so no passwords need to be stored in code.
Review regularly. Remove access that is no longer needed.

Roles add up

A person’s effective access is the sum of every role assignment that reaches them, from every scope above the resource. If someone has Reader at the management group and Contributor on a resource group, they can change things in that group. Audit the combined result, not just a single assignment.

11Azure Policy and Governance Across the Tree

Roles say who may act. Policies say what is allowed to exist. Together they keep a large cloud under control.

What Azure Policy does

Azure Policy checks resources against rules and either reports problems or stops them. Examples of rules are “only allow these regions”, “storage accounts must use secure connections”, and “every resource must carry a cost-centre tag”. A rule is described in a policy definition. When you apply it to a scope, that is a policy assignment. A set of related policies bundled together is called an initiative.

What a policy can do

Report

Audit

Allows the resource but records it as non-compliant. A gentle way to find problems without breaking anyone’s work.

Block

Deny

Refuses to create or change a resource that breaks the rule. Strong and immediate.

Fix

Modify and Append

Changes or adds properties automatically, such as adding a missing tag.

Fix

DeployIfNotExists

Creates a missing companion resource, for example turning on diagnostic logging whenever a new database appears.

Analogy

Think of a city’s building code. Inspectors can write a warning (audit), refuse a building permit (deny), or require a fire exit to be added before approval (fix). The code applies to every new building in the city, and inspectors check old buildings from time to time as well.

How to roll out policies safely

Start in audit mode

See how many resources would break the rule before blocking anything.

Test on a small scope

Apply the rule to a sandbox or a single resource group first.

Communicate

Tell teams what is coming and why, and give them a way to ask for exceptions.

Switch to deny at the right scope

Move to enforcement, ideally at a management group, so every subscription below follows.

Remediate and review

Fix existing non-compliant resources and watch the compliance dashboard over time.

Exemptions and exclusions

Sometimes one resource has a genuine reason to break a rule. Azure lets you exclude a scope from an assignment or create a time-limited exemption, with a recorded reason. This is much safer than weakening the rule for everyone.

12Cost Management and Billing Across the Hierarchy

Every cost starts at a resource and rolls up through the tree. Knowing how it rolls up makes the bill understandable.

How costs roll up

Each resource produces usage. Usage is priced and added to its resource group, then to its subscription, and in many arrangements up through management groups and to the billing account at the top. At each level you can see totals, break them down, and set alerts. The billing arrangement, such as an enterprise agreement or a customer agreement, decides how invoices are produced and how the billing account is organised above the subscriptions.

Level	What you can see or do	Typical user
Billing account	All invoices and payment settings	Finance and procurement
Management group	Total cost across many subscriptions, in supported setups	Cloud governance and finance
Subscription	Total cost, budgets, forecasts, and alerts	Product or department owners
Resource group	Cost of one application or environment	Application teams
Resource and tag	Cost of one item, or all items sharing a tag	Engineers and cost analysts

The three tools that matter most

See

Cost analysis

Charts and tables that let you group costs by resource group, resource type, location, or tag.

Warn

Budgets and alerts

Set a spending target at a chosen scope and receive messages at chosen percentages, or even trigger automatic actions.

Label

13How It Works Inside: What Happens When You Create a Resource

Behind a single click, Azure checks the whole tree above your resource before it builds anything.

Every request to create, change, or delete a resource goes to Azure Resource Manager, the management layer of Azure. It acts like a careful front desk: it checks who you are, what you may do, which rules apply, and whether anything protects the target. Only then does it hand the request to the service that builds the resource.

sequenceDiagram
  participant U as You
  participant E as Microsoft Entra ID
  participant A as Azure Resource Manager
  participant R as Role Check across all scopes
  participant L as Lock Check
  participant P as Policy Check across all scopes
  participant S as Resource Provider
  U->>E: Sign in
  E-->>U: Identity token
  U->>A: Create a storage account in a resource group
  A->>E: Is this token valid
  E-->>A: Yes
  A->>R: Does this person have a role that allows it
  R-->>A: Yes, from a role at the subscription scope
  A->>L: Is the group or subscription locked
  L-->>A: No lock blocks this
  A->>P: Do any policies from management group down allow it
  P-->>A: Allowed
  A->>S: Build the resource
  S-->>A: Created
  A-->>U: Success

Resource Manager checks identity, roles, locks, and policies, using every level of the tree, before the resource is built.

What this teaches

A “forbidden” error can come from a missing role, a lock, or a policy. Each needs a different fix.
Role assignments and policies from every scope above the target are considered, which is why a rule at a management group can stop something in a deep resource group.
Policy is checked even if you are an Owner. Roles say who you are allowed to be, but policy says what is allowed to exist at all.
Locks can block even an Owner, until the lock itself is removed by someone with the right to do so.

Analogy

Building a new shop is like this. The city checks your identity, your licence to build, whether the plot is protected as a heritage site, and whether your plan fits the zoning rules. Only when every check passes does the builder start work.

Troubleshooting order

When a request fails, ask in order: Am I signed in to the right tenant and subscription? Do I have the right role at the right scope? Is a lock in place? Did a policy deny it? The error message often names the policy or the missing permission.

14Lifecycle and Data Flow: From Birth to Retirement

Every container in the tree has a life. Planning it, from creation to deletion, avoids messes.

The life of a subscription

Request

A team asks for a new subscription, giving purpose, owner, cost centre, and environment.

Create and place

The subscription is created and put in the right management group, so it receives the right policies and roles at once.

Prepare

Baseline items are added: budgets, alerts, networking, logging, and role assignments for the owning team.

Operate

Teams build, deploy, and run their workloads, while governance rules keep things safe.

Change

The subscription may move to another management group, for example from a sandbox group to a production group, which changes its inherited rules.

Retire

Resources are deleted or archived, the subscription is cancelled or disabled, and it is placed in a holding group during the waiting period.

The life of a resource group

Create it with a clear name, a location, and tags that say who owns it and why it exists.
Fill it using repeatable templates rather than manual clicks, so the same setup can be rebuilt.
Protect important groups with locks and appropriate roles.
Move resources between groups if ownership or lifecycle changes, remembering that not all resource types can move.
Delete the whole group when the project ends, after checking that nothing shared lives inside.

Analogy

A new shop branch follows a similar life. It is requested, opened under the right regional board, furnished with the standard fittings, run day to day, sometimes moved to a new region, and finally closed with its stock and records handled properly.

How a deployment flows through the tree

When a team deploys an application, the template or pipeline targets a scope, usually a resource group. Azure Resource Manager reads the template, checks permissions and policies as described earlier, and creates each resource in the group, in the right order. Tools such as deployment stacks can keep track of everything a deployment created, so that a later removal cleans up all the pieces together.

15Designing a Hierarchy: The Landing Zone Idea

Microsoft’s Cloud Adoption Framework suggests a well-tested starting shape. It is called an Azure landing zone.

A landing zone is a prepared, governed environment in which a workload can be placed safely. The recommended shape uses management groups to separate shared platform services from the application subscriptions that use them, and to separate experiments from serious production.

flowchart TB
  ROOT["Tenant Root Group"]
  ORG["Management Group: Your Organisation"]
  PLAT["Management Group: Platform"]
  LZ["Management Group: Landing Zones"]
  SBX["Management Group: Sandbox"]
  DEC["Management Group: Decommissioned"]
  ID["Subscription: Identity"]
  MAN["Subscription: Management and Monitoring"]
  CON["Subscription: Connectivity"]
  CORP["Management Group: Corp - internal apps"]
  ONL["Management Group: Online - internet-facing apps"]
  A1["Subscription: App 1 Prod"]
  A2["Subscription: App 2 Prod"]
  ROOT --> ORG
  ORG --> PLAT
  ORG --> LZ
  ORG --> SBX
  ORG --> DEC
  PLAT --> ID
  PLAT --> MAN
  PLAT --> CON
  LZ --> CORP
  LZ --> ONL
  CORP --> A1
  ONL --> A2

A typical landing zone shape: platform services, application landing zones, a sandbox for experiments, and a holding group for retired subscriptions.

What each branch is for

Shared

Platform

Holds shared services: identity, central monitoring, and the network hub that connects everything. Few people have access, and mistakes here affect everyone.

Apps

Landing zones

Holds the application subscriptions, often split into groups for internal apps and internet-facing apps, each with suitable rules.

Play

Sandbox

A freer area where people can experiment with fewer restrictions and tight budgets, disconnected from real data.

Retire

Decommissioned

A holding area for subscriptions that are being shut down, with very strict rules, until they are finally removed.

Analogy

A good city has roads, power stations, and water systems built first (the platform). Then it opens plots of land with those services already connected (landing zones), where families can build houses without digging their own pipes. A park (the sandbox) lets children play safely, and a demolition area (decommissioned) keeps old buildings fenced off.

Do not copy blindly

A small company with two or three subscriptions does not need this entire structure. Start with the ideas, such as separating shared services, separating production from non-production, and giving experiments their own place, and grow the shape when you truly need it.

16Common Design Patterns: How to Split Your Subscriptions

There is more than one way to divide an organisation. Each has strengths and weaknesses.

Pattern	How it splits	Strength	Watch out for
By environment	Separate subscriptions for development, testing, and production	Strong isolation between risky and safe work	Many subscriptions to manage as products multiply
By workload or application	One subscription per application or product	Clear cost and ownership per product	Shared services need careful connections
By team or department	One subscription per team	Matches the company chart, easy chargeback	Reorganisations force changes, and one team may run many apps
By geography or regulation	Separate subscriptions per country or compliance zone	Supports data residency and legal boundaries	More duplication of shared services
Hybrid of the above	For example, per application and per environment	Combines clear ownership with safety	Needs good naming and automation to stay manageable

The “subscription as a unit of scale” idea

Large organisations often treat subscriptions as disposable building blocks. When a new application needs a space, a process called subscription vending creates a ready-to-use subscription, already placed in the right management group, already given the right policies, networking, and budgets. This keeps each subscription small, avoids hitting limits, and gives every team clean boundaries.

Real-world example: a growing online retailer

An online retailer starts with one subscription for everything. As it grows, a developer’s mistake in testing takes down a part of production, and finance cannot tell which product causes the cost increase. The retailer introduces separate production and non-production subscriptions, then one subscription per major product, all under management groups with shared policies. Mistakes become smaller, and costs become visible.

Guiding question

To decide whether two things belong in the same subscription, ask: should they share the same budget, the same access list, the same limits, and the same rules? If the answer to any of these is “no”, a separate subscription is probably the better choice.

17Naming and Tagging Conventions

Good names and tags are a free form of documentation. They make everything easier to find, secure, and charge.

Naming that tells a story

A consistent naming scheme packs useful information into each name. A common pattern combines a short code for the resource type, the workload, the environment, and the region. For example, a resource group for the production version of a shop in a Central India region might be named “rg-shop-prod-centralindia”. Microsoft publishes recommended abbreviations for resource types, and following them helps new team members understand names at a glance.

Type

Resource type prefix

A short code, such as “rg” for resource group or “sub” for subscription, tells you what the thing is.

What

Workload name

Names the application or product, such as “shop” or “payroll”.

Where in life

Environment

Says whether it is development, test, or production.

Where on Earth

Region

Names the location, which helps with disaster recovery and cost reviews.

Tags that earn their keep

A tag is a name and value pair attached to a resource, such as “owner” with the value “team-payments”. Tags are free-form labels that cut across the tree. They answer questions the tree cannot, such as “which resources belong to this cost centre, across all subscriptions?” Useful standard tags include owner, cost centre, environment, application, and data sensitivity. Azure limits the number of tags per resource, so choose a small standard set.

Analogy

In a big warehouse, the shelf location tells you where an item is, and a coloured sticker tells you who it belongs to. The tree is the shelf location, and tags are the stickers. Both are useful, and neither replaces the other.

Names are hard to change

Many Azure resources cannot be renamed after creation, and some names must be globally unique. Decide the scheme before you create resources, write it down, and use Azure Policy to enforce required tags.

18Security Across the Hierarchy

The tree is also a security structure. Each boundary is a chance to limit damage.

Boundaries limit the blast radius

The blast radius is the amount of damage a single mistake or attack can cause. Separate subscriptions and groups shrink it. If an attacker steals the credentials of a developer who only has access to a development subscription, they cannot reach production. If a policy mistake is made in a sandbox group, real customers are not affected.

Lock

Resource locks

A “cannot delete” lock stops accidental deletion, and a “read-only” lock prevents changes. Locks apply even to Owners until someone removes the lock.

Time

Just-in-time access

Powerful roles are activated only when needed, for a short period, with approval and a record.

Rescue

Emergency access accounts

A couple of strongly protected accounts are kept aside to regain control if normal access fails. They are monitored closely and used rarely.

Rules

Security policies

Policies at high scopes enforce encryption, block public access to storage, and restrict regions across every subscription.

Watch

Cloud security posture

Microsoft Defender for Cloud scores your subscriptions against security best practice and recommends improvements.

Identity

Strong sign-in

Multi-factor authentication and conditional access protect the tenant, since everything in the tree depends on it.

Analogy

Ships are built with watertight compartments. If one compartment floods, the walls stop the water from sinking the whole ship. Subscriptions and management groups are the watertight walls of your cloud.

The identity directory is the crown jewel

Whoever controls the tenant’s most powerful identities can often reach every subscription. Protect these accounts the most, keep their number tiny, and monitor every sign-in.

19Monitoring, Auditing, and Finding Things

A tree with thousands of items needs tools to search it, watch it, and prove what happened.

Tool	What it tells you	Use it when
Activity Log	Who created, changed, or deleted what, and when, at subscription level	You need an audit trail or find out who deleted something
Azure Resource Graph	Fast queries across all your subscriptions and resources	You need an inventory, for example all untagged resources
Policy compliance view	Which resources break which rules	You manage governance and track fixes
Cost analysis	Where money is going, by any grouping	You review spending
Defender for Cloud	Security score and recommendations	You track security improvements
Azure Monitor	Health and performance of the resources themselves	You operate workloads

Useful questions the tree helps you answer

Which subscriptions sit under the Production management group?
Who has Owner rights anywhere in the tree?
Which resources have no owner tag?
Which resource groups cost the most this month?
Which resources break the “encryption required” policy?
Who deleted that resource group last night?

Analogy

A big library needs a catalogue to find books (Resource Graph), a visitors’ register to see who entered (Activity Log), an inspection report to check rules (Policy compliance), and a ledger for its spending (Cost analysis). Each tool answers one kind of question.

Send logs somewhere durable

The Activity Log keeps records for a limited time by default. Send important logs to a central workspace or storage account, so you can investigate older events and meet audit needs.

20Advantages, Disadvantages, and Trade-offs

A richer hierarchy gives more control, but it also gives more to manage. The right amount depends on the size of your organisation.

Advantages of a well-built hierarchy

One rule, many places: policies and roles at high levels reach everything below.
Clear ownership: every resource sits under an owner and a purpose.
Visible costs: bills can be split by product, team, or environment.
Smaller blast radius: mistakes and attacks stay inside one boundary.
Easy scaling: a new subscription brings fresh limits.
Simple cleanup: delete a group and its contents go with it.

Disadvantages and costs

Extra planning: a good design needs thought up front.
More objects to manage: many subscriptions need automation.
Hard to change later: moving resources between subscriptions is possible only for some types, and takes care.
Connections needed: separate subscriptions need networking and sharing set up between them.
Policy side effects: a strict rule at a high level can block legitimate work.
Skills needed: teams must learn scopes, inheritance, and troubleshooting.

One subscription or many?

Situation	Reasonable structure	Why
Learning or personal project	One subscription, one resource group per experiment	Simple, cheap, easy cleanup
Small team with one product	Separate production and non-production subscriptions	Protects real users from test mistakes
Growing company with several products	Subscription per product and environment, under a few management groups	Clear cost, access, and rules
Large enterprise	Landing zone design with platform and application groups, and automated subscription creation	Governance at scale with team independence

Legitimate deployments across the whole company suddenly fail, and teams lose trust in governance.

Better approach

Start in audit mode, test at a small scope, communicate, and then enforce at the right level.

Smaller slips to watch for

Leaving new subscriptions directly under the root group, where they pick up no useful rules.
Forgetting that tags do not inherit, then wondering why costs are unlabelled.
Using personal accounts instead of groups for role assignments.
Moving resources between groups without checking whether the type is movable and whether dependent resources are affected.
Having no budget or alert on a subscription.

22Best Practices and a Design Checklist

Good hierarchies are built from a few dependable habits, applied early.

Do this

Separate production from non-production.
Use management groups for governance, not for the org chart.
Keep the tree shallow and simple.
Assign roles to groups at the narrowest sensible scope.
Group resources by lifecycle.
Standardise names and a small set of required tags.
Enforce rules with Azure Policy, starting in audit mode.
Set budgets and alerts on every subscription.
Protect critical groups with locks.

Avoid this

One giant subscription for everything.
Giving Owner widely.
Putting shared and disposable things in one group.
Placing risky rules at the root without testing.
Relying on people to add tags by hand.
Using deep, department-based management group trees.
Creating resources by clicking, with no templates.
Forgetting to review access and cost regularly.

A design checklist in order

Identify your tenant and owners

Decide who owns the identity directory and the root, and keep that group very small.

Sketch the governance needs

List the different sets of rules you need, such as production, non-production, sandbox, and regulated workloads.

Create management groups to match

Make the smallest tree that carries those rule sets, and set a default group for new subscriptions.

Decide the subscription pattern

Choose environment, workload, team, or a mix, and document how new subscriptions are requested.

Set the baseline policies and roles

Apply allowed regions, required tags, and security rules, plus group-based role assignments.

Define naming, tags, and resource group rules

Write them down and enforce them by policy where possible.

Automate and review

Use templates and pipelines to create resources, and review access, cost, and compliance on a schedule.

23Limits and Numbers Worth Knowing

A few limits shape real designs. The figures below are typical, so confirm the current values before planning.

Item	Typical limit or rule	Why it matters
Parents per container	Exactly one	Nothing can be in two places at once, so design with one clear home for each thing
Management group depth	About six levels under the root, not counting root and subscription	Encourages a shallow, simple tree
Management groups per tenant	Thousands	Rarely a problem, but do not create hundreds for no reason
Root groups per tenant	One	All governance rules share one top
Resource groups per subscription	In the hundreds, with a documented maximum	Large estates may need more than one subscription
Resource group nesting	Not allowed	Use naming and tags to show relationships instead
Tags per resource	A fixed maximum, typically fifty	Choose a small standard set
Quotas	Set per subscription and per region	New subscriptions give fresh limits, and some need requests to raise
Role assignments per subscription	A documented, large maximum	Using groups keeps you far below it

Verify before you rely

Limits are raised and occasionally changed over time. The numbers in this table are only meant to show the shape of the system. Always check Microsoft’s current documentation on Azure subscription and service limits.

Analogy

Limits are like the capacity rules of a building: a maximum number of people per room, per floor, and per lift. Knowing them in advance helps the architect design wide corridors and extra lifts before the crowd arrives, instead of after.

24Real-World and Industry Examples

The scenarios below show typical ways organisations of different sizes arrange their Azure hierarchy. They are general patterns, not descriptions of any named company.

A student or hobby learner

One subscription from a free account, with one resource group per practice lab. After each lab, the learner deletes the group. A budget alert guards against accidental spending. No management groups are needed.

A small startup

Two subscriptions: one for production and one for everything else. Developers are given Contributor rights in the non-production subscription, and only two senior engineers can change production. Costs of the two subscriptions are reviewed monthly.

A mid-size software company

One subscription per product and environment, grouped under “Production” and “Non-Production” management groups. Policies at those groups require tags, allow only approved regions, and enforce encryption. A central platform team runs shared networking and monitoring in its own subscriptions.

A large bank

A full landing zone structure, with strict policies and few Owners. New application subscriptions are created automatically with network connections, logging, budgets, and policies already in place. Regulated workloads sit in groups with extra rules about regions and encryption.

A university

Each faculty receives a subscription with a budget. A sandbox management group lets students and researchers experiment with strict spending limits and no connection to real data. Research projects that finish are moved to a holding group and then deleted.

A managed service provider

A company that runs cloud services for many customers keeps each customer in separate subscriptions, often in separate tenants, and uses delegated access tools to manage them without sharing credentials.

25Three Mini Labs to Learn by Doing

Each lab is small and safe, and ends with cleanup. A free account is enough for the first two. The third needs permission to create management groups.

Lab 1: Explore your own hierarchy

Open the Azure portal and search for “Subscriptions”. Note the name, identifier, and offer type of yours.
Open “Resource groups” and create one named for the lab, choosing a nearby location.
Create a small, low-cost resource, such as a storage account, inside that group.
Open the group and see its resources, its tags area, and its access control page.

What you learn: how the subscription, resource group, and resource levels look and relate in the portal.

Lab 2: See inheritance in action

Open the access control page of your subscription and see who has roles there.
Open the access control page of your resource group. Notice that the subscription-level roles also appear, marked as inherited.
Add a resource lock of type “cannot delete” to the resource group. Try to delete the group and see that Azure refuses.
Remove the lock, then delete the group and watch its contents disappear.

What you learn: that roles flow downward, that locks protect against deletion, and that deleting a group deletes everything inside.

Lab 3: Build a tiny management group tree

If you have the rights, open “Management groups” and create two groups, one named “Sandbox” and one named “Production”.
Move a test subscription into “Sandbox”, and observe how it appears in the tree.
Assign a simple, harmless policy, such as one that audits missing tags, to the “Sandbox” group, and check later how it shows compliance on resources in the subscription.
Move the subscription back and delete the extra groups when you finish.

What you learn: how management groups organise subscriptions and how a policy at the top reaches everything below.

Careful with real environments

Do not try Lab 3 in a company tenant without permission. Changing management groups and policies can affect many people. Use a personal or training tenant.

26A Beginner’s Glossary

Every important word from this guide in one place, each with a plain comparison.

Term	Plain meaning	Everyday comparison
Tenant	Your organisation’s directory of identities	A staff register
Microsoft Entra ID	The service that manages those identities and sign-ins	The identity office
Root management group	The single top container of the tree	The head office
Management group	A container for subscriptions and other groups	A regional board
Subscription	A billing, access, and scale boundary	A separate phone connection with its own bill
Resource group	A folder for related resources	A labelled moving box
Resource	One thing you create, like a database	One item in the box
Scope	The level at which something applies	A postal address level
Inheritance	Settings flowing downward	A national rule reaching every school
RBAC	Role-based access control for Azure resources	Staff badges
Role assignment	Who gets which role at which scope	Giving a badge for a certain floor
Least privilege	Giving only the access needed	A key that opens only your room
Azure Policy	Rules about what may exist and how	A building code
Initiative	A bundle of policies	A full rulebook
Resource lock	A guard against deleting or changing	A padlock on a cupboard
Tag	A name and value label on a resource	A sticker on a box
Azure Resource Manager	The management front desk of Azure	A reservation desk
Landing zone	A prepared, governed place for workloads	A serviced plot of land
Subscription vending	Automatically creating ready-to-use subscriptions	A ready-made flat handed over with keys
Blast radius	The damage one mistake or attack can cause	The size of the area a fire can reach
Showback and chargeback	Showing or billing departments for their usage	A shared household bill

27Frequently Asked Questions

Plain answers to what beginners ask most often.

Q1What is the order of the Azure hierarchy?

From top to bottom: management groups, subscriptions, resource groups, and resources. Above them sits the tenant, with a single root management group.

Q2Do I need management groups?

Not for a single subscription or a small project. They become valuable when you have several subscriptions that should share the same policies and access rules.

Q3Can a subscription belong to two management groups?

No. Every subscription and every management group has exactly one parent. You can move a subscription to another group, but it can only be in one at a time.

Q4Can a resource group contain another resource group?

No. Resource groups cannot be nested. Use clear names and tags to show relationships, and use management groups and subscriptions for larger structure.

Q5What happens if I delete a resource group?

Every resource inside it is deleted too. Some protection may exist, such as locks, but you should always check what is in a group before deleting it.

Q6Do tags and permissions flow downward in the same way?

No. Role assignments, policies, and locks inherit downward. Tags do not inherit by default, so use a policy or your deployment templates to apply them to resources.

Q7Why would I create more than one subscription?

To separate billing, access, and limits. Typical reasons are separating production from development, splitting products or teams, meeting legal boundaries, and getting fresh quotas.

Q8Can I move resources between resource groups or subscriptions?

Many resource types can be moved, but not all, and there are conditions. Check the move support for each type before planning, and expect a short period in which the resources are locked during the move.

Q9What is the difference between Azure RBAC and Entra ID roles?

Azure RBAC controls what people can do to Azure resources and uses the tree’s scopes. Entra ID roles control directory tasks such as managing users. They are separate systems.

Q10Where should I start if I am designing a new setup?

Start simple: separate production from non-production, use groups for access, agree on names and tags, set budgets, and add management groups and policies as you grow.

28Summary and Key Takeaways

Key Takeaways

Azure organises everything as a tree: tenant and root group, management groups, subscriptions, resource groups, and resources, and each container has exactly one parent.
Management groups apply rules to many subscriptions at once, subscriptions are the billing, access, and scale boundary, and resource groups hold resources that share a lifecycle.
Scope tells where something applies, and inheritance carries roles, policies, and locks downward, while tags do not inherit by default.
RBAC controls who can do what, Azure Policy controls what may exist, and locks guard against accidents. Resource Manager checks all of them before building anything.
Use least privilege, assign roles to groups at the narrowest sensible scope, and use just-in-time access for powerful roles.
Split subscriptions to separate cost, access, limits, and risk, starting with production versus non-production, and consider a landing zone shape as you grow.
Standardise names and tags, set budgets and alerts, and roll out policies in audit mode before enforcing them.
Keep the design as simple as your needs allow, and confirm current limits and recommended tools on Microsoft’s official documentation.