Azure subscriptions

What is an Azure subscription, really?

You pick one in every create dialog and rarely think about it again. But the subscription is not a billing detail — it is three boundaries wearing one name, and where you draw it shapes cost, governance, and scale for everything inside.

New to cloud? CAMPUX is a free, build-first course. Start here →

Most people meet the subscription as an annoyance: another required dropdown before Azure will let you build. That framing hides how load-bearing it is. Microsoft's definition is compact and worth memorising: "Subscriptions are a unit of management, billing, and scale within Azure." Three boundaries, one object. Understand each and the subscription stops being a dropdown and becomes a design decision.

Boundary one: billing

The most familiar face. Costs roll up to the subscription — it is the thing an invoice is drawn against. When finance asks "what did this cost?", the subscription is the natural first cut of the answer, which is exactly why organizations often give a team, a project, or an environment its own subscription: it makes the money legible without any extra tooling. (Tags slice cost within a subscription; the subscription slices it between teams.)

Figure — A subscription is a container that sits in the middle of the Azure hierarchy. Above it, a tenant (Microsoft Entra ID) holds identity and one or more management groups push policy down. The subscription itself is the billing and scope boundary — costs, quotas, and many limits are drawn here. Inside it, resource groups hold the actual resources (VMs, storage, and the rest). New workload, new blast radius, or separate bill? That is when you make a new subscription.

Boundary two: management and governance

This is the one beginners miss, and it is the most important. A subscription is "a management boundary for governance and isolation that clearly separates concerns." RBAC role assignments and Azure Policy assignments both apply at the subscription scope and flow down to everything inside it. That is why dev, test, and prod so often live in separate subscriptions: production can carry strict policy and tight access while development stays looser, and neither leaks into the other. Draw the subscription boundary and you have drawn a governance boundary at the same time.

Boundary three: scale

The one nobody warns you about until you hit it. A subscription is "a scale unit," and it has limits and quotas — a ceiling on cores, on certain resource counts, on capacity. A large, hungry workload can bump into those ceilings, which is why Microsoft advises giving big specialised workloads their own subscription: not for tidiness, but so they can grow without starving everything else of quota. If you have ever been told "we're out of vCPU quota in this subscription," you have met this boundary in person.

A subscription is where your money, your governance, and your growth all hit the same wall — so choose where that wall goes on purpose.

Where it sits in the hierarchy

The subscription is the middle of a stack, and its neighbours explain it:

Above it — the Microsoft Entra tenant. Every subscription is linked to exactly one Entra tenant, which is its identity provider: the tenant is who can sign in, the subscription is what they can touch and what it costs.
Above it — management groups. Subscriptions are grouped under management groups so that policy and access can be assigned once, high up, and inherited by every subscription beneath. That is how an enterprise governs fifty subscriptions without configuring fifty.
Below it — resource groups, then resources. Inside the subscription, resource groups organize resources by lifecycle, and the actual VMs, databases, and storage accounts live in those.

A subscription is not a region

A common surprise: subscriptions are not tied to a region. Microsoft is explicit — they are "global subscriptions," logical constructs for billing, governance, and identity, and a single subscription can hold resources from many regions at once. You do not need a subscription per region. (One thing that does stop at the boundary: virtual networks cannot span subscriptions — worth knowing when you plan connectivity.)

So when do you make a new one?

Not for every app — that way lies a hundred subscriptions nobody can govern. Create a new subscription when one of the three boundaries demands it:

Billing: a team or environment whose cost must be cleanly separated and owned.
Governance: a workload that needs a distinctly different policy or access posture — production versus development, or a regulated workload with stricter rules.
Scale: a large workload that would otherwise crowd others against subscription limits and quotas.

Then group whatever you create under management groups so governance stays inherited rather than hand-copied. Do that and the subscription stops being the dropdown you click past — it becomes a deliberate line you draw around a slice of your estate, chosen because the cost, the rules, or the scale of that slice deserved its own wall.

Questions people also ask

What is the difference between an Azure subscription and a tenant?

The tenant is your Entra ID directory: it holds the users, devices, and groups that can sign in, and it is your identity boundary. The subscription is linked to exactly one tenant and controls what those signed-in identities can touch and what it costs. One tenant can hold many subscriptions; a subscription belongs to only one tenant.

Is an Azure subscription the same as a resource group?

No. The subscription sits above the resource group in the hierarchy. A subscription is the billing, governance, and scale boundary; resource groups live inside a subscription and organize the actual VMs, databases, and storage accounts by lifecycle. You can have many resource groups inside one subscription.

How many Azure subscriptions can I have?

A tenant can hold multiple subscriptions, and Microsoft does not fix a small hard cap for most account types. The real constraint is not the count but your ability to govern them: each new subscription is another billing, policy, and access boundary someone has to own, which is why you create one only when billing, governance, or scale demands it.

Can one Azure subscription span multiple regions?

Yes. A subscription is not tied to a region. Microsoft calls them global subscriptions, logical constructs for billing, governance, and identity, and a single subscription can hold resources spread across many regions at once. You do not need a separate subscription per region.

Why would you create separate Azure subscriptions for dev and production?

Because RBAC and Azure Policy assignments apply at the subscription scope and flow down to everything inside it. Separate subscriptions let production carry strict policy and tight access while development stays looser, with neither environment able to leak permissions or policy into the other.