Azure tenants, subscriptions and resource groups: how the hierarchy fits together

Azure separates identity, billing and resource organisation into distinct layers. Compared with clouds that flatten these into a single account object, it is more structure to learn up front. In exchange, it maps much more cleanly onto how real organisations are shaped, and it makes delegation possible without handing out broad access.

The cost of learning it late is real, because some of these boundaries are difficult to move across afterwards.

The layers, from the outside in

Microsoft Entra tenant. The identity boundary. A tenant is a directory of users, groups, service principals and applications. It is where authentication happens. If your organisation already uses Microsoft 365, you already have a tenant, and it is almost certainly the one you should use.

Management groups. Optional containers that sit above subscriptions, used to apply policy and access rules to many subscriptions at once. A common shape is one management group per environment class, or per business unit, with policies attached at the level where they should apply to everything beneath.

Subscriptions. The billing and quota boundary. A subscription is what receives an invoice, and it is where service limits are counted. Resources live inside exactly one subscription.

Resource groups. Containers inside a subscription that hold resources with a shared lifecycle. A resource group has a region of its own, which stores the group’s metadata, though the resources inside it can live in other regions.

Resources. The actual things: virtual machines, storage accounts, databases, networks.

What each boundary is genuinely for

The distinction that matters most is between subscriptions and resource groups, because that is where most early mistakes happen.

Use a subscription boundary when you need separation of billing, of quota, or of blast radius. Production and non-production belong in different subscriptions, because you want their invoices separate, you do not want a runaway test job consuming production’s quota, and you want an access mistake in one to be unable to touch the other.

Use a resource group boundary when things share a lifecycle. The clearest test is deletion: if you would want to delete all of these together, they belong in one resource group. An application’s web tier, its database, its storage account and its networking are usually one group. Two unrelated applications are usually two.

Resource groups are also the natural unit for role assignments, for deployment templates and for cost views, so the lifecycle test tends to produce a structure that is convenient for everything else too.

The things that are hard to change later

Some of these choices are easy to revise. Others are not, and it is worth knowing which is which before you commit.

• Moving a resource between resource groups is usually straightforward, but not universally supported and occasionally disruptive.
• Moving a resource between subscriptions is supported for many resource types and awkward for others. Some require a rebuild.
• Changing the tenant a subscription is associated with is possible but genuinely disruptive: role assignments do not travel, and anything using managed identities needs attention afterwards.
• Region is effectively fixed for most resources. Changing it means creating new and migrating.

The practical implication is to spend a little more thought on subscription boundaries and regions than on resource group boundaries, because the first two are expensive to revisit and the third is cheap.

Naming, before you have hundreds of things

A naming convention feels like bureaucracy when you have six resources and becomes indispensable at sixty. The convention matters less than having one, but a workable pattern includes the workload, the environment, the resource type and, where relevant, the region.

Whatever you choose, apply it from the first resource. Retrofitting names is tedious and, for resources with globally unique names such as storage accounts, sometimes impossible without a rebuild.

Tags do the work that names cannot. A tag for cost centre, owner and environment on every resource turns the cost analysis view from a list of opaque names into an answerable question. Azure Policy can require specific tags at creation time, which is far more reliable than asking people to remember.

Access, at the right level

Role assignments inherit downward. A role granted at a management group applies to every subscription beneath it; granted at a subscription, it applies to every resource group; granted at a resource group, to every resource inside.

The temptation is to grant broadly at the top because it is less work. The discipline worth keeping is to grant at the narrowest level that lets someone do their job, and to prefer built-in roles over custom ones until a built-in role genuinely does not fit. Custom roles are maintenance you will own forever.

Groups, not individuals, should hold the assignments. Adding someone to a group is a routine action; editing role assignments across dozens of scopes when someone changes team is not.

A reasonable default shape

For a small team without existing structure, this is a sensible starting point:

• One tenant, the one your organisation already uses for identity.
• Two subscriptions: production and non-production.
• One resource group per application per environment.
• Tags for owner, cost centre and environment, enforced by policy.
• Role assignments held by groups, granted at the resource group level.

That is enough structure to stay comprehensible as you grow, and little enough to set up in an afternoon. Add management groups when you have enough subscriptions that governing them individually becomes tedious, which is usually somewhere past half a dozen.

For the vendor’s own reference on the services involved here, see the Azure documentation on Microsoft Learn.

Questions people ask