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.
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.)
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 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.