When I first started working in Azure, I created one subscription and used resource groups as folders to organize everything.
Yeah… I know.
I don’t like admitting it either.
I was new, it made sense at the time, and honestly—it worked for a while.
Until it didn’t.
I had dev, UAT, and prod separated into resource groups, and in my head that meant I had structure. I thought I had boundaries.
I didn’t.
I had a mess that just hadn’t broken yet.
Over the years, I’ve seen the same pattern play out across different environments. Some teams put everything into a single subscription. Others go the opposite direction and create dozens of subscriptions with no real structure.
Both approaches fail for the same reason: they weren’t designed.
After 20+ years in IT—starting in high school, through the Navy, into enterprise cloud—I can tell you this:
Boundaries matter.
You don’t mix critical systems with experimental ones.
You don’t design systems where one failure can cascade into everything else.
In Azure, subscriptions are where those boundaries actually exist.
Management groups give you structure.
Subscriptions are where that structure becomes real.
If you’ve already built your management group hierarchy, the next step isn’t just creating subscriptions.
It’s deciding how your environment is going to scale.
The Problem
Most teams don’t think about subscription design until they’re already in trouble.
- Put everything in one place
- Create subscriptions as needed without a plan
That works—right up until the moment it doesn’t.
I’ve seen environments where:
- Dev, test, and prod all live in the same subscription
- Networking is shared across environments “to save time”
- Platform services and applications are tightly coupled
At first, it feels efficient.
Then the cracks start showing.
RBAC becomes a nightmare. Networking becomes fragile. Deployments become tightly coupled.
And then cost becomes a problem.
You can’t clearly identify which workload is driving spend.
At that point, you’re not building—you’re managing friction.
A More Intentional Approach
Everything gets easier when you’re intentional.
Subscriptions are not billing containers.
They are control boundaries.
- Security scope (RBAC)
- Policy enforcement scope
- Deployment isolation
- Operational ownership
When you design subscriptions intentionally, you reduce complexity everywhere else.
Separate Platform and Workloads
Mixing shared services with application workloads creates long-term problems.
Platform services belong in platform subscriptions.
Applications belong in workload subscriptions.
And here’s what most engineers miss:
You need to design for decommissioning—not just growth.
Design for Growth
Your environment will grow.
- Add applications
- Add engineers
- Add environments
- Add complexity
The question is whether your design will support that growth—or fight against it.
Lessons From Experience
In the Navy, the systems I worked on weren’t optional—they were critical.
They were:
- Isolated
- Controlled
- Clearly separated
Cloud environments follow the same rules.
Train as you fight. Fight as you train.
Practical Subscription Architecture
Platform Subscriptions
- Identity
- Key Vaults
- Logging
- Automation
Connectivity Subscription
- Hub VNets
- Firewall
- VPN
- DNS
Workload Subscriptions
- Per application or environment
Sandbox Subscriptions
- Testing
- Experimentation
Decommissioned Subscription
- Retired workloads
- Cost control
- Restricted access
RBAC: Where This Becomes Real
Use groups, not individuals.
- App-Team-Prod-Contributors
- Platform-Admins
- Network-Operators
Tagging Strategy
- Environment
- Application
- Owner
- CostCenter
What You Should Do
- Map your current subscriptions
- Identify mixed responsibilities
- Align subscriptions to management groups
- Create a standard subscription pattern
Final Thoughts
Management groups give you structure.
Subscriptions bring that structure to life.
This is where your architecture stops being theoretical and starts becoming operational.
If you get subscription design right, a lot of your future problems get smaller:
- Access becomes predictable instead of chaotic
- Deployments become isolated instead of fragile
- Cost becomes measurable instead of guessed
If you get it wrong, everything downstream becomes harder.
Not impossible—but harder than it needs to be.
And here’s the part most engineers underestimate:
Design alone doesn’t hold the line.
You can build a clean subscription model, document it, and get buy-in from your teams—and six months later, you’ll still see:
- Resources in the wrong place
- Naming standards ignored
- Networking decisions breaking your design
- Permissions slowly expanding
Not because people are careless.
Because systems without enforcement always drift.
That’s the gap.
Subscriptions define the boundaries.
But they don’t enforce behavior inside those boundaries.
That’s where Azure Policy changes the game.
Policy turns your design into something enforceable.
It’s how you:
- Enforce tagging
- Restrict regions and SKUs
- Require secure configurations
- Prevent bad deployments before they happen
More importantly, it lets you scale governance without becoming the bottleneck.
In the next article, we’re going to break down how to actually implement Azure Policy in a way that works in real environments—how it flows from management groups into subscriptions, and how to build guardrails that protect your platform without slowing engineers down.
Because designing the structure is step one.
Enforcing it is where real engineering starts.