💳 Designing Subscription Strategy
Where Ownership, Cost, and Control Actually Live
If Management Groups define governance…
Subscriptions define accountability
🔥 Why Subscription Design is Critical
Most real problems in cloud don’t come from:
- networking
- compute
- storage
They come from:
- unclear ownership
- cost visibility issues
- access chaos
- deployment conflicts
👉 All of this ties back to subscription design
❌ Common Mistakes
1. One Subscription for Everything
Subscription-1
├── All apps
├── All environments
├── All teams
👉 Result:
- no cost clarity
- no isolation
- access conflicts
- blast radius is huge
2. One Subscription per App (blindly)
App1-Sub
App2-Sub
App3-Sub
👉 Sounds clean… but:
- too many subscriptions
- operational overhead
- difficult governance
- duplicated configs
3. Environment-based only
Prod-Sub
Dev-Sub
QA-Sub
👉 Problem:
- multiple apps mixed
- ownership unclear
- cost allocation messy
✅ What Subscriptions Should Represent
A subscription is a boundary for:
- Ownership
- Cost (billing unit)
- Access control
- Lifecycle management
- Quotas and limits
🧠 Key Design Dimensions
You must balance these:
1. Ownership
- Who owns the workload?
- Which team is accountable?
2. Cost Visibility
- Can you track cost per:
- app?
- business unit?
- environment?
3. Isolation
- Blast radius
- Security boundaries
- Compliance needs
4. Scale
- 10 apps vs 1000 apps
- future growth
5. Operations
- CI/CD pipelines
- access management
- monitoring
🏦 Recommended Enterprise Pattern
Platform Subscriptions
- Platform-Identity
- Platform-Connectivity
- Platform-Management
👉 Owned by central cloud/platform team
Landing Zone Subscriptions (Workloads)
Instead of 1 rigid rule, use pattern-based approach
Pattern 1 — App + Environment (most common)
App1-Prod
App1-NonProd
App2-Prod
App2-NonProd
👉 Good for:
- clear ownership
- cost tracking
- isolation
Pattern 2 — Shared Non-Prod
App1-Prod
Shared-NonProd
👉 Useful when:
- many small apps
- cost sensitivity
- early stage
Pattern 3 — Regulated Workloads
PCI-App1-Prod
PCI-App1-NonProd
👉 Required when:
- strict compliance
- audit isolation
- policy enforcement
Sandbox Subscription
Sandbox-Sub
👉 Purpose:
- experimentation
- controlled freedom
- strict budgets
⚖️ Key Trade-offs
| Approach | Pros | Cons |
|---|---|---|
| Few subscriptions | Easy management | Poor isolation |
| Many subscriptions | Strong isolation | Operational overhead |
💡 Golden Rule
Design subscriptions around ownership and cost — not just structure
🔁 Relationship with Management Groups
| Level | Purpose |
|---|---|
| MG | Governance / Policy |
| Subscription | Ownership / Cost / Access |
🧠 Architect Thinking
You don’t ask:
“How many subscriptions should I create?”
You ask:
“Where do I need separate ownership, cost visibility, and isolation?”
🚨 Subtle but Important Insight
Most failures happen when:
- MG design is good ✔
- Subscription design is weak ❌
👉 Result:
- governance exists
- but accountability is broken
What Comes Next
Now we have:
- MG structure ✔
- Subscription strategy ✔
Next comes the most complex part:
👉 Network Architecture (Hub-Spoke, vWAN, Segmentation, Connectivity)
| ⬅ Back to Series Home | ⬅ Back to: Management Group Design ➡ | Next: Network Design ➡ |