Almost every Azure subscription design conversation opens with the same question, which is how many subscriptions an organisation should have. It has no answer, because subscription count is an output rather than an input. Ask it first and you get a number that someone then has to defend for the next five years.
The useful question is what a subscription is a boundary for. Microsoft’s Cloud Adoption Framework answers it directly: subscriptions are boundaries for scale, quota, cost, governance, security and identity controls. Once you accept that, the count works itself out, and so does the far more common problem, which is estates that created subscriptions along an axis that does not correspond to any boundary at all.
The most expensive mistake is regional
Start here, because it is the one we correct most often and it is stated unambiguously in the guidance.
Subscriptions are not tied to a region. They are logical constructs for billing, governance, security and identity, and Microsoft is explicit that you can treat them as global. You do not need a separate subscription for each region.
A single subscription can hold resources from several regions. In a geo-disaster recovery design you can and generally should keep the primary and secondary region in the same subscription, because they are logically one workload. Use resource groups to organise by region inside it.
Create a per-region subscription only when there is a region-specific governance or management requirement, such as data sovereignty, or when you need to scale past a quota limit. Those are real reasons. “We operate in four regions” is not one of them.
There is a related rule at the resource group level that runs the other way and is genuinely strict. A resource group should not contain resources from different regions, and the resource group’s own region should match the resources inside it. Mixing them causes management and availability problems. So the correct pattern is one subscription spanning regions, with resource groups that do not.
The worst sprawl we have inherited was organised entirely this way: one subscription per country the business operated in. A single application ended up split across four subscriptions for no reason other than where its users happened to sit. Each of those four carried its own policy assignments, its own role assignments and its own cost view, and none of it corresponded to an actual boundary.
That is what makes the regional model expensive. It does not just add subscriptions, it multiplies everything attached to a subscription, and buys no isolation in return.
The four triggers for a new subscription
When a new subscription is genuinely warranted, it is for one of four reasons. This is the list I would put on the wall.
Scale limits. Subscriptions are a scale unit, and workloads have to fit inside platform subscription limits. Large specialised workloads such as high performance computing, IoT and SAP should get their own subscription specifically to avoid colliding with those ceilings.
Management boundary. A subscription separates concerns for governance and isolation. Development, test and production are usually separated at this level for exactly that reason.
Policy boundary. Azure Policy assignments land on subscriptions. A regulated workload, a PCI estate for instance, typically needs additional policy that you do not want applied to everything else. Separating it means the extra overhead does not spill outward. The same logic runs in reverse: development environments have looser policy requirements than production, and a shared subscription forces you to pick one.
Target network topology. Virtual networks cannot be shared across subscriptions. They can be connected, through peering or ExpressRoute, but not shared. So the question of which workloads need to talk to each other is a subscription design input, not a networking detail to sort out afterwards. It is also an integration design input, because the pattern you choose for those conversations decides whether a boundary between two systems is a boundary or a dependency.
Notice what is absent. Business unit, cost centre, application owner and region are all absent. Those are reporting dimensions, and reporting dimensions belong in tags, which is where Azure cost governance actually lives. Encoding them in the subscription topology hard-codes today’s org chart into a structure that outlives it.
Applying the four to an estate you already have
Running these over an existing estate is almost always a reduction rather than an expansion. Consolidating the per-country estate described above onto trigger-based subscriptions cut the count by more than half, and nothing the organisation actually needed was lost in the process.
The exercise itself is unglamorous and can be done in a spreadsheet. For each subscription, write the single sentence that says which of the four triggers it satisfies. Where that sentence turns out to name a reporting dimension rather than a boundary, you have a consolidation candidate, and the resources inside it usually move without incident precisely because nothing about them ever depended on the split.
What you recover is not tidiness. It is that policy assignments stop being duplicated across boundaries that were never boundaries, and every remaining cost view corresponds to something a person actually owns.
Platform subscriptions are four, not one
This one is stated as a recommendation rather than a preference, and the reasoning is worth reading twice.
Establish separate dedicated platform subscriptions for management, security, connectivity and identity. Management hosts the global capabilities such as Log Analytics workspaces and Automation runbooks. Security hosts Microsoft Sentinel and the supporting integrations. Connectivity hosts the Virtual WAN hub, private DNS and ExpressRoute circuits. Identity hosts domain controllers where they are needed.
The instruction that follows is the important half: do not combine platform responsibilities into a single subscription. Keeping them separate is what lets you apply different policy and different role assignments to each, and it separates the billing.
That last point is underrated. A single combined platform subscription produces a monthly figure for “the platform” that nobody can decompose, which means nobody can challenge it. Split into four, the connectivity spend is visible as connectivity spend, and ExpressRoute circuits stop hiding inside a general overhead line.
What actually happens instead
Worth saying plainly, because the guidance describes the destination and most estates are not at it.
In practice most clients collapse the four into one or two subscriptions early on. The usual shape is management and security together, with connectivity and identity folded in “temporarily”. And it rarely gets unwound once it is working, even though the guidance is unambiguous that it should be four.
We are not going to pretend that is fatal, because an estate running that way is not on fire. But it is worth understanding what the collapse costs you, so it stays a decision rather than an accident. One combined platform subscription means one set of role assignments across capabilities with genuinely different blast radiuses, the same policy applying to your Sentinel workspace and your ExpressRoute circuits, and a single billing line for “platform” that nobody can decompose or challenge.
The separation is also far cheaper to establish at the start than to retrofit. If you are designing now, do it as four. If you inherited one, the honest question is not whether to split it today, but whether the next capability you add goes into the pile or starts the separation.
Vending, and why rigid models fail
Two recommendations that belong together.
The first is to build a subscription vending process so application teams can request a subscription through a self-service workflow, and get one that arrives already inside the right management group, with the right policies inherited and the right role assignments applied. A subscription created outside that process inherits nothing, and it is invisible as a governance gap until it shows up as an unexplained cost or an audit finding.
The second is more interesting because it argues against over-designing: avoid a rigid subscription model. The guidance is to use flexible criteria for grouping rather than a fixed structure, on the grounds that one size does not fit all, and what works for one business unit will not work for another. Some applications can share a landing zone subscription. Others need their own.
Those two recommendations are often read as being in tension. They are not. Vending is about how a subscription is created. Flexibility is about when one should be. Automating the creation of subscriptions nobody needed just industrialises the sprawl.
Quota is a design constraint, not an operational surprise
Three facts about quota that change how you design, rather than how you operate.
Quotas are not capacity guarantees, and they are applied per region. Having quota for a hundred cores does not mean a hundred cores are available to you in that region on the day you need them. For workloads where that matters, capacity reservations are the mechanism, not quota increases.
SKU availability varies by region. New features frequently land in some regions first, and virtual machine SKUs are not uniformly available. Confirm the services and SKUs your workload needs exist in your chosen regions before the design depends on them.
Quota Groups let you manage and share quota across several subscriptions, which changes the calculus on whether a workload needs its own subscription for headroom reasons.
Operationally, three things are worth automating early: quota requests through the Azure Quota REST API, quota alerts so subscription owners are told before they hit a limit, and a dashboard with custom views tracking used capacity against critical thresholds. Raising a support request for more cores is not a problem. Discovering you needed them during a deployment window is.
One more that costs nothing and is skipped constantly: enable Azure Service Health on every subscription. It is the difference between knowing an Azure incident is affecting you and inferring it from your own alerts.
The tenant transfer control nobody has configured
This is not really a subscription design topic and I am including it anyway, because in our assessments it is almost never set.
Every Azure subscription is linked to one Microsoft Entra tenant. Anyone holding the right permissions can change which tenant a subscription is linked to. Your policies, your role assignments and your governance all follow the tenant, so a subscription that leaves is a subscription that leaves all of it behind.
The recommended configuration is to set both *Subscription leaving Microsoft Entra directory* and *Subscription entering Microsoft Entra directory* to permit no one, then maintain a short list of exempted users covering the platform operations team and your break-glass accounts.
Two caveats that matter. Only Global Administrators with elevated access can configure this, and Microsoft is clear that Global Administrator should be reserved for emergencies rather than used routinely. And the exempted users list accepts individual accounts only, not Entra groups, so it needs a review cadence or it decays as people move on. Subscriptions transferred into a tenant land in the default management group, which is another argument for making sure that management group is not permissive.
Our position: design the boundaries, then count
Our position is that subscription count is the least interesting output of Azure subscription design, and treating it as the goal is what produces estates that need remodelling three years later.
Design the management group hierarchy first, because that is where policy and access are applied at scale. Then place subscriptions inside it according to the four triggers. The number falls out.
We would not begin with a target count, and we would not begin from the org chart. In our engagements the estates that age worst are the ones whose subscription topology mirrored a reporting structure, because reporting structures are reorganised roughly every two years and subscription topologies are not.
The counterweight, and I want to be even-handed about this: starting small is genuinely correct for new environments, and the guidance says so. Begin with a small set of subscriptions and grow. The failure mode we are describing comes from premature structure, not from too few subscriptions. If you are unsure whether a workload needs its own, the reversible answer is usually to keep it in an existing one, because reusing decommissioned subscriptions is straightforward and unpicking a fragmented estate is not.
Management groups first, even though it feels backwards
We would argue for management groups before subscriptions every time, and it is worth acknowledging that this is the less intuitive order.
Teams want to see the workload boundary first, because the workload is what they are actually deploying. The management group hierarchy feels like abstraction for its own sake at the point when someone just wants somewhere to put an application. That instinct is understandable and it is still the wrong sequence.
The reason is asymmetry of cost. Policy inheritance is decided at the management group level, so getting the hierarchy wrong is the expensive mistake to unwind later. Moving a subscription between management groups changes every policy and role assignment that applies to everything inside it, which is a change nobody wants to make casually against a production estate. A subscription placed in the wrong group is a decision you inherit for years.
Get the hierarchy right and subscription placement becomes a routine, reversible decision. Get it wrong and every subscription you add compounds it.
Where to start
Take your existing estate and put every subscription against the four triggers. Scale, management, policy, network. Any subscription that does not map to one of them exists for a reason that is no longer load bearing, and it is a candidate for consolidation.
Then check three things: whether your platform responsibilities are split four ways or collapsed into one, whether a new subscription today would arrive through a vending process with policy inherited, and whether your tenant transfer settings permit no one.
Those three answers tell you more about the health of a landing zone than a cost report will.
Veratas designs Azure platforms and does the enterprise architecture work that decides where these boundaries belong, including remediating estates built before the current landing zone accelerator options existed.
If your subscription estate has grown past the point where anyone can explain the organising principle, talk to our team. Mapping it against the four triggers is a short exercise and it usually reduces the count.
Frequently asked questions
How many Azure subscriptions should we have? There is no target number. Create a subscription when it is warranted by a scale limit, a management boundary, a policy boundary or network topology. The count is an output of those decisions.
Do we need a subscription per region? No. Subscriptions are not tied to a region and can be treated as global. Create a regional subscription only for region-specific governance requirements such as data sovereignty, or to scale beyond quota limits. Keep primary and secondary disaster recovery regions in the same subscription.
Should platform services share one subscription? No. Establish separate dedicated subscriptions for management, security, connectivity and identity, so each can carry its own policy and role assignments and so the billing is separable. In practice most estates collapse these into one or two, usually management and security together with connectivity and identity folded in, and it rarely gets unwound afterwards. It is far cheaper to establish the separation at the start than to retrofit it.
Should we design management groups or subscriptions first? Management groups first, even though teams instinctively want to see the workload boundary first. Policy inheritance is decided at the management group level, so an error there is the expensive one to unwind: moving a subscription between groups changes every policy and role assignment applying to everything inside it. Get the hierarchy right and subscription placement becomes routine and reversible.
What is subscription vending? An automated self-service workflow for creating subscriptions, so each one arrives inside the correct management group with policies inherited and access assigned. Subscriptions created outside it inherit nothing and are invisible as governance gaps.
Does quota guarantee capacity? No. Quotas are applied per region and are not capacity guarantees. Use on-demand capacity reservations where guaranteed capacity matters, and consider Quota Groups to share quota across subscriptions.
How do we stop a subscription being moved to another tenant? Set both subscription leaving and subscription entering directory settings to permit no one, with a short exempted users list including platform operations and break-glass accounts. The list takes individual accounts only, not groups, so it needs reviewing.
Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.