One Subscription Is Not Automatically Wrong
One of the easiest Azure recommendations to oversimplify is:
“Use multiple subscriptions.”
That advice is incomplete.
If a company has one small Azure workload, one team, one operating model, and limited complexity, one subscription may be perfectly understandable.
The problem begins when the subscription has no defined purpose.
Development appears.
Then production.
Then a sandbox.
Then shared networking.
Then a data platform.
Then another business unit.
Everything lands in the original subscription because it already exists.
Eventually the subscription is responsible for workloads that have different:
- owners;
- budgets;
- risk profiles;
- access requirements;
- policies;
- operational expectations.
At that point, a boundary that was initially simple has become ambiguous.
Microsoft treats subscriptions as important units of Azure management and as boundaries relevant to governance, isolation, cost, security, policy, quota, and scale. Microsoft Learn: Azure subscription organization
The subscription should therefore answer a question:
“What belongs here, and why?”
Think in Boundaries, Not Resource Counts
Do not create a new subscription simply because a resource count reaches an arbitrary number.
Create one when the boundary becomes useful.
| Question | Separate subscription becomes more useful when… |
|---|---|
| Ownership | Different teams are accountable |
| Security | Workloads need materially different controls |
| Policy | Different guardrails are required |
| Environment | Isolation between environments matters |
| Cost | Independent budget accountability is needed |
| Lifecycle | Workloads are created or retired independently |
Microsoft’s current guidance recommends treating subscriptions as units of management and notes that separate subscriptions can isolate application environments where appropriate. Microsoft Learn: Azure landing zone design principles
That is a design principle—not a command to multiply subscriptions unnecessarily.
What Is a Management Group Actually For?
Management groups organize subscriptions so common governance can be applied above them.
That sounds simple.
But management groups are often misused because they look like folders.
A folder invites you to reproduce the company org chart:
North America
Finance
Corporate IT
Applications
Production
That can seem logical until the organization changes.
Microsoft’s current guidance recommends keeping management-group structures reasonably flat—ideally around three to four levels—and specifically advises against duplicating deeply nested organizational structures. Management groups should primarily help apply policies and governance consistently to subscriptions with similar requirements. Microsoft Learn: Management groups and resource organization
A durable management group represents control similarity, not necessarily reporting similarity.
Ask:
Which subscriptions should inherit the same policy and governance expectations?
That is usually a better design question than:
Which vice president owns them?
Do Not Turn Dev, Test, and Prod Into Management-Group Layers by Default
This is another common instinct.
Teams imagine:
Landing Zones → Production → Development → Test
It seems clean.
But Microsoft explicitly recommends against creating management groups simply for production, test, and development environments. Where isolation is required, environments can be separated into subscriptions while remaining under the same workload archetype management group when their overarching policy requirements are the same. Microsoft Learn: Management group recommendations
Why?
Because management groups are primarily useful when the inherited controls differ.
If development and production need the same broad corporate requirements but different workload-level configurations, creating additional management-group layers may add complexity without creating much value.
The decision should follow policy and risk requirements, not aesthetic symmetry.
A Small Organization Can Start With a Small Hierarchy
A smaller Azure environment may initially need only a limited management structure.
For example, conceptually:
- Platform / shared responsibilities
- Workload landing zones
- Sandbox / experimentation
The exact structure depends on the organization.
You should not copy these labels simply because they appear here.
Microsoft’s reference architecture includes workload archetypes such as Corp, Online, Sandbox, and platform areas, but it also explicitly expects organizations to tailor the architecture to their requirements. Microsoft Learn: Management group architecture
The useful exercise is to define:
- where production workloads belong;
- where experimentation belongs;
- where shared platform capabilities belong;
- which workloads need different governance;
- where new subscriptions land by default.
That last point matters.
Microsoft recommends configuring a dedicated default management group for new subscriptions rather than allowing them to appear unmanaged at the tenant root. Microsoft Learn: Management group recommendations
Subscription Ownership Should Be Explicit
Every subscription should have a clear owner.
Not merely an Azure Owner role assignment.
A business and operational owner.
That owner should know:
- what the subscription exists for;
- which workloads belong there;
- who pays for it;
- who can request access;
- which policies apply;
- who remediates policy findings;
- who owns operational incidents;
- what would trigger retirement of the subscription.
Microsoft’s subscription guidance specifically recommends informing subscription owners of their roles and responsibilities, including budget responsibility, policy compliance, and access review expectations. Microsoft Learn: Subscription organization guidance
This is where technology and operating model meet.
A beautifully structured subscription hierarchy with unclear ownership is still an unclear platform.
Avoid Broad RBAC at Management-Group Scope
A permission assigned high in the Azure hierarchy can inherit downward.
That makes management-group access powerful.
It also makes it easy to grant significantly more access than intended.
Microsoft recommends against assigning application teams RBAC permissions at management-group scope and instead recommends granting access at the subscription or resource-group level required by the team. Microsoft Learn: Management group recommendations
The practical principle is:
Assign governance broadly when it must be broad. Assign human access as narrowly as the job allows.
That does not mean management-group RBAC is never appropriate.
Platform, security, audit, or centralized operational roles may legitimately require broader visibility.
The mistake is using a high-level assignment merely because it is convenient.
When Should You Create Another Subscription?
Use a decision rule instead of intuition.
Consider a new subscription when one or more of these conditions is material:
Different policy
Does this workload require a substantially different governance or compliance baseline?
Different security boundary
Would separating the workload reduce unnecessary access or risk?
Different ownership
Is a different team accountable for operating and funding it?
Different environment boundary
Would an issue in development create unacceptable impact on production?
Different lifecycle
Will this environment be created, transferred, or retired independently?
Different scale profile
Could quota or platform limits make separation valuable?
Microsoft’s subscription guidance explicitly identifies management, policy, scale, networking, and isolation considerations as reasons to evaluate separate subscriptions. Microsoft Learn: Subscription organization guidance
If none of those conditions apply, a new subscription may provide little value.
Subscription Vending: Automate When Demand Justifies It
“Subscription vending” can sound like something only huge enterprises need.
The principle is simpler.
A new subscription should arrive with the expected foundation.
That might include:
- correct management-group placement;
- baseline policies;
- budget settings;
- role assignments;
- logging expectations;
- standard tags;
- network onboarding where required.
Microsoft recommends establishing a consistent subscription-vending process and increasingly automating that process as demand grows. Microsoft Learn: Azure landing zone deployment
A company creating two subscriptions per year may not need a sophisticated self-service portal.
A company creating two per day has a different problem.
The decision rule is:
Automate subscription provisioning when manual creation becomes a recurring source of delay, inconsistency, or risk.
Do not automate because the term sounds mature.
Automate because repetition has become measurable.
The Organization Will Change. Your Control Model Should Survive It.
Companies reorganize.
Teams merge.
Business units are renamed.
Applications move between owners.
Cloud architecture should not require a structural redesign every time an organizational chart changes.
That is why grouping subscriptions by long-lived requirements—security, compliance, connectivity, workload archetype, and governance—can be more stable than directly reproducing reporting structures.
There are exceptions.
Some organizations genuinely have regulatory or sovereignty reasons to reflect geography or business segmentation in the hierarchy.
Microsoft’s guidance allows this kind of tailoring where requirements justify it. Microsoft Learn: Management group architecture
The goal is not a universally “correct” hierarchy.
It is a hierarchy with an explainable reason.
A Subscription and Management-Group Design Checklist
Before expanding the structure, ask:
- Can we explain the purpose of every subscription?
- Does every subscription have an accountable owner?
- Do production and non-production need separate boundaries?
- Are different security or compliance requirements driving separation?
- Are management groups based on durable governance requirements?
- Is the hierarchy reasonably flat?
- Are we accidentally rebuilding the HR org chart?
- Do new subscriptions have a defined landing location?
- Are application-team permissions scoped lower than management groups where possible?
- Do subscription owners understand cost and policy responsibilities?
- What would trigger creation of another subscription?
- At what volume would subscription provisioning need automation?
If you can answer those questions, the exact number of subscriptions becomes much less mysterious.
Design for the Organization You Are Becoming
Azure subscription architecture should not optimize only for today’s resource count.
It should create boundaries that remain understandable when another workload, team, environment, or regulatory requirement appears.
Start small.
Keep the management-group hierarchy understandable.
Give every subscription a purpose.
Use subscriptions when separation provides actual management value.
And automate subscription creation when repetition begins to hurt.
BI Cloud Tech’s Azure Landing Zone expertise, Landing Zone Readiness Assessment, and Architecture Review are existing paths for organizations that need to evaluate an existing structure or define a target model before Azure grows further.
The objective is not to predict your final Azure hierarchy. It is to create a structure that can accept change without becoming confusing.
