Subscription Strategy
Subscriptions are not billing containers with a credit card attached. They are one of the most important boundaries in Azure — for ownership, governance, security, scale, and cost. Treating them as an afterthought is how platforms end up with one giant subscription that nobody can safely change.
Purpose
This page defines subscriptions as operational units for management, billing, security, scale, and workload ownership, and sets out a practical split for a small-to-medium organization.
Design Reasoning
The wrong question is “how few subscriptions can we get away with?” The better question is “where do we need a clear boundary for ownership, governance, compliance, scale, or isolation?”
- Platform subscriptions host shared platform capabilities — connectivity, management and monitoring, identity.
- Workload subscriptions host application environments or product lines, and form the application landing zones.
Subscription vending exists because application teams should not receive subscriptions through inconsistent, manual portal work. The platform should provide a repeatable process for creating, placing, securing, tagging, monitoring, and handing over subscriptions. Vending is covered in detail in Workload Onboarding; this page defines the boundaries that vending then automates.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| Platform subscription split | Separate connectivity, management, and (optional) identity subscriptions | Follows the platform landing zone model and gives each shared capability a clear owner and blast radius. |
| Workload subscription split | Split by ownership, environment, compliance, or isolation — not by resource count | A subscription boundary should mean something operationally, not just shard resources. |
Tradeoff: More subscriptions mean more scopes to govern. The platform absorbs that cost through inherited policy and vending automation, in exchange for clean ownership, cost, and security boundaries.
Recommended Configuration
A practical baseline for a small-to-medium organization:
| Subscription | Purpose | Owner |
|---|---|---|
| Connectivity | Hub VNet or Virtual WAN, firewall, private DNS, hybrid connectivity | Platform network team |
| Management | Log Analytics, alerts, monitoring, workbooks, optional Sentinel | Platform operations team |
| Identity (optional) | Domain controllers, Entra Domain Services, or identity-adjacent infrastructure | Identity team |
| Workload — production | Production application workloads | Application team, under platform governance |
| Workload — non-production | Development, test, and staging workloads | Application team |
| Sandbox | Exploration, proof of concept, disposable workloads | Users or teams, under lighter guardrails |
Every subscription — platform or workload — should consistently include management group placement, required tags, budget and cost alerts, Azure RBAC assignments, Activity Log forwarding, required diagnostic settings, a Defender for Cloud baseline, and a chosen network pattern.
Example Implementation
Use a simple, repeatable decision when a new workload appears. The point is to make “should this be its own subscription?” a checklist, not a debate.
| Question | If yes | Result |
|---|---|---|
| Different owner or operating team? | Yes | Use a separate subscription |
| Strict production / non-production separation required? | Yes | Use separate subscriptions |
| Different compliance or policy requirements? | Yes | Use a separate subscription or management group archetype |
| Shared platform capability? | Yes | Use a platform subscription |
| Small internal test workload without strong isolation needs? | No | It may fit an existing non-production subscription |
Validation Steps
# List subscriptions you can access and confirm management group placementaz account list --all --output table
# Review control-plane activity for a subscription over the last 7 daysaz monitor activity-log list --offset 7d --subscription <subscription-id>
# Confirm budgets and cost alerts existaz consumption budget list --scope /subscriptions/<subscription-id>Also verify that new subscriptions are automatically placed under the correct management group. If they are not, the platform is missing either a default management group placement or a subscription vending process.
Common Mistakes
- Putting every workload in one subscription “to keep it simple.” This blurs ownership, cost, policy, and security boundaries, and the cleanup is painful once workloads are running.
- The opposite extreme: a subscription per microservice or small project. Subscription strategy should reflect ownership, isolation, compliance, and operational needs — not arbitrary resource counts.