Subscription as Architecture Boundary
A subscription is not just a billing container — it's an architectural boundary that affects isolation, governance, networking, and scalability. Every subscription decision is a design decision.
The Four Boundaries of a Subscription
- Billing boundary — costs roll up per subscription; enables per-team or per-project cost visibility
- Policy & RBAC boundary — Azure Policy and role assignments can be scoped to a subscription
- Scale boundary — each subscription has its own resource quotas and limits
- Network boundary — VNets live in a subscription; cross-subscription requires peering
Subscription Topology Patterns
There's no single "right" subscription model. The choice depends on org size, compliance requirements, blast radius tolerance, and team autonomy needs.
| Pattern | Structure | Best For | Risk |
|---|---|---|---|
| Per-Environment | sub-dev, sub-staging, sub-prod | Small orgs (1-3 products), clear env separation | All workloads share limits; blast radius within env |
| Per-Workload | sub-app1-prod, sub-app2-prod, sub-shared | Isolation-first orgs, regulated industries | Subscription sprawl; overhead managing many subs |
| Per-Team | sub-team-alpha, sub-team-beta, sub-platform | High-autonomy engineering orgs | Cost visibility per-app is harder; teams may duplicate infra |
| Hybrid (Landing Zone) | Combines all three with management groups | Enterprise scale (100+ engineers) | Complex to set up; needs platform team to govern |
AZ-305 Exam Tip
Exam questions often present a scenario and ask "how many subscriptions?" The answer depends on: isolation requirements, billing separation needs, quota pressure, and policy scope differences. Look for keywords like "separate billing," "different compliance requirements," or "approaching limits."
EA/MCA Billing Hierarchy
Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA) have different billing structures. Understanding these is key for cost architecture.
| Level | EA | MCA | Purpose |
|---|---|---|---|
| Top | Enrollment | Billing Account | Contract-level entity |
| Grouping | Department | Billing Profile | Invoice grouping, payment method |
| Ownership | Account | Invoice Section | Subscription creation rights |
| Bottom | Subscription | Subscription | Resource container |
Don't Confuse Billing Hierarchy with Management Groups
The EA/MCA hierarchy is for billing and procurement. Management groups are for governance (policy, RBAC). They're independent structures that both contain subscriptions. A subscription belongs to exactly one billing account AND exactly one management group.
Limits That Drive Architecture
Subscription limits (quotas) are a forcing function for architecture. Hit a limit, and you must split into multiple subscriptions — plan for this.
| Resource | Default Limit | Can Increase? | Architecture Impact |
|---|---|---|---|
| VNets per region | 1,000 | Yes | Rarely a problem |
| NSGs per subscription | 5,000 | Yes (to 10K) | Large microservice deployments may hit this |
| Public IPs per subscription | 1,000 | Yes | Multi-tenant SaaS with dedicated IPs |
| Storage accounts per region | 250 | Yes (to 500) | Data-intensive workloads; use fewer, larger accounts |
| VNet peerings per VNet | 500 | No | Hub-spoke at scale; consider Virtual WAN |
| Route tables per subscription | 200 | Yes | Complex routing topologies |
| RBAC role assignments | 4,000 per subscription | No | Large orgs; use groups not individual assignments |
| Azure Policy assignments | 200 per subscription | No | Governance-heavy environments |
When to Split: The Five Triggers
- Quota pressure — approaching hard limits that can't be increased
- Blast radius — a misconfigured policy or RBAC shouldn't affect unrelated workloads
- Billing separation — different cost centers or chargeback owners
- Compliance isolation — regulated workloads (PCI, HIPAA) need separate policy scopes
- Team autonomy — teams need freedom to self-serve without stepping on each other
Cost Management Architecture
Cost management is an architectural concern, not an afterthought. Design cost visibility from day one.
The Cost Governance Stack
Budget Design Principles
- Set budgets at subscription and resource group levels — not just top-level
- Use multiple thresholds: 50% (inform), 80% (warn), 100% (alert), 120% (action group triggers automation)
- Connect budgets to action groups for automated responses (e.g., shut down dev VMs at 100%)
- Export cost data to storage for historical trending beyond the 13-month Cost Management window
Tagging Taxonomy Design
Tags are your metadata layer for cost allocation, automation, and governance. A bad taxonomy is worse than none — it creates false confidence.
Minimum Viable Tag Set
| Tag | Purpose | Example | Enforce? |
|---|---|---|---|
cost-center | Chargeback | CC-4521 | ✅ Required via Policy |
environment | Lifecycle | prod / staging / dev | ✅ Required via Policy |
owner | Accountability | team-payments | ✅ Required via Policy |
application | Workload ID | checkout-api | ✅ Required via Policy |
data-classification | Security | confidential / internal / public | ⚠️ Recommended |
created-by | Audit | terraform / manual | Auto-applied |
Tags Do NOT Inherit
Tags on a resource group do not automatically flow to resources inside it. Use Azure Policy with modify effect to auto-apply RG tags to child resources. This is a common exam trick question.
Enforcement via Azure Policy
Require a tag on resources— deny creation if tag is missingInherit a tag from the resource group if missing— modify effect copies RG tag downRequire tag and its value from a set— enforce controlled vocabulary (prevents "prod" vs "Prod" vs "production")
Chargeback & Showback Models
| Model | Description | Best For | Complexity |
|---|---|---|---|
| Showback | Show teams their costs; no actual money transfer | Cost awareness without org friction | Low |
| Direct Chargeback | Bill teams directly for their resource consumption | Teams with P&L responsibility | Medium |
| Shared Cost Allocation | Split shared infrastructure costs proportionally | Hub/platform services, shared DBs | High |
Shared cost allocation methods:
- Even split — divide equally among consumers (simple but unfair)
- Proportional to usage — based on metrics (CPU, requests, storage) consumed
- Fixed allocation — pre-agreed percentages per team (predictable but may drift)
Reserved Instances, Savings Plans & Spot
These are architecture-level cost commitments. Choosing them affects your flexibility and lock-in.
| Mechanism | Discount | Commitment | Flexibility | Best For |
|---|---|---|---|---|
| Reserved Instances | Up to 72% | Specific SKU + region, 1 or 3 years | Low — locked to size/region (exchangeable within family) | Steady-state workloads: databases, always-on VMs |
| Savings Plans | Up to 65% | $/hr spend, 1 or 3 years | High — applies across VM families, regions, services | Dynamic workloads that shift between sizes/regions |
| Spot VMs | Up to 90% | None — can be evicted with 30s notice | Highest — no commitment at all | Batch, rendering, CI/CD, stateless scale-out |
Architect's Decision Framework
- Identify baseline (always-on) capacity → Reserve it (RIs for specific, Savings Plans for flexible)
- Identify burst capacity → Pay-as-you-go or Spot (if fault-tolerant)
- Start with Savings Plans if unsure — they're more forgiving than RIs
- Layer: use RIs for known DB workloads + Savings Plans for compute + Spot for batch
Real-World: MegaCorp Financial Services
Scenario: 2,000-person enterprise with 5 business units (Retail Banking, Corporate Banking, Insurance, Wealth Management, Shared IT), 3 environments (dev, staging, prod), and regulatory requirements (PCI-DSS for payments, SOX for reporting).
Subscription Design
- Platform subscriptions: sub-connectivity (hub VNet, ExpressRoute, Firewall), sub-management (Log Analytics, Defender, automation)
- Per-BU + per-env: sub-retail-prod, sub-retail-nonprod, sub-insurance-prod, sub-insurance-nonprod, etc.
- Shared services: sub-shared-data (data platform used by all BUs), sub-shared-identity
- Sandbox: sub-sandbox (experimentation, no peering to prod, auto-delete after 30 days)
- Total: ~14 subscriptions organized under management groups by BU and environment
Cost Architecture
- Tagging:
cost-center,bu,application,environmentenforced via Policy - Chargeback: BUs charged for their subscription costs directly; shared infra split 40% Retail / 25% Corporate / 20% Insurance / 15% Wealth (based on resource consumption metrics)
- Savings: 3-year RIs for production SQL databases; 1-year Savings Plan for compute; Spot for dev/test VMSS
- Budgets: Per-subscription with 80%/100%/120% alerts; dev subscriptions auto-shut VMs at 100%
Result
42% cost reduction vs. pay-as-you-go baseline. Full visibility per BU. Compliance teams can audit per-subscription. Platform team manages 14 subs vs. the 200+ resource groups they'd need in a single subscription.
Knowledge Check
1. A startup has 3 products, 2 environments each, and needs separate billing per product. They're hitting NSG limits in their single subscription. What's the minimum subscription topology change?
2. Tags applied to a resource group automatically appear on all resources inside it. True or false?
3. Your team runs a mix of always-on web servers and periodic batch-processing jobs. Which cost optimization combination maximizes savings?
4. Which is NOT a valid reason to create a separate subscription?
5. How should shared platform costs (hub VNet, firewall, monitoring) be allocated across business units?
Key Takeaways
- Subscriptions are architecture boundaries (billing, policy, scale, network) — not just billing containers
- Choose topology based on isolation needs, not just org chart: per-environment, per-workload, per-team, or hybrid
- Plan for limits proactively; split before you hit quota walls
- Tags are your cost visibility layer — enforce them via Policy from day one
- Layer cost optimizations: RIs for steady-state, Savings Plans for flexible, Spot for fault-tolerant