Let’s be honest — talking about resource organisation in Azure sounds about as exciting as reorganising your underwear drawer. But it’s one of the most critical foundations of a successful Azure environment.
Like any foundational principle of the Cloud Adoption Framework (CAF), getting it right early pays dividends. Some missteps are easy to fix when that “ah-ha!” moment hits. Others? Not so much — they can demand significant remediation effort and risk.
Consultant Corner: Nobody — and I mean nobody — gets it perfect. Perfection isn’t the objective. The goal is to do what’s best for your organization while honoring best practices.
You should align with CAF and Enterprise-Scale principles — but don’t let them stifle innovation. Teams differ greatly in maturity, discipline, skills, and resources. And that’s perfectly fine.
What truly matters is grasping the principles — not just the tangible results.
Why It Matters
Resource organisation is directly tied to how effectively an Azure environment can be managed, governed, and protected.
When I see a well-structured Azure Enterprise-Scale platform — regardless of size — I instantly know the engagement will be smoother. It’s not about volume; it’s about clarity. Defined archetypal scopes allow governance mechanics to be applied with confidence.
Example: Imagine a compliance requirement:
“No public exposure of virtual machines.”
Sounds simple — until you realise real-world workloads sometimes do need public IPs. How do you differentiate?
- A domain controller? Absolutely not.
- A public-facing workload VM? Maybe yes.
The answer? Archetypes.
Definition: An archetype is a predefined, standardised pattern or configuration — usually created to fulfill a common use case, compliance requirement, or deployment model. Think of it as a blueprint with opinions.
In Azure, you define archetypes — like “identity workloads” vs. “internet-facing services” — and then apply governance accordingly (via Policy, RBAC, Budget, etc.).
Enterprise-Scale helps you enforce these archetypes by:
- Using Management Groups to separate workloads by type.
- Applying Policy and RBAC at the right scopes.
- Enabling flexibility and control, even in small environments.
You could be running just one VM — doesn’t matter. The structure still matters.
Naming Convention
Be consistent — even if you’re consistently wrong. Just document it.
Consultant Corner: I don’t usually recommend enforcing naming via Azure Policy — set it to AuditOnly at most. Focus on naming things usefully: resource type, region, environment, etc.
Tagging
Define and ratify a tagging policy early.
Consultant Corner: I enforce tags at the resource group level with
Denypolicies. It’s painful upfront, but essential later. Tags enable the cool and innovative stuff that often comes with subsequent stages of cloud adoption – automation, chargeback, scheduling… everything.
Resource Locks
A constant tug-of-war between SecOps and Operations. If you round-tabled the discussion, you’d typically have the SecOps team immediately saying yes but the operations team immediately saying no. In reality – they are a fantastic mechanism to prevent accidental deletion of key resources. I’ve seen Azure Local Clusters being accidentially deleted…
They will impede regular operations and there really does need to be a balance (documented with considerations and findings) between using them selectively or not.
Consultant Corner: I’ve used strict locks where needed — paired with custom roles and PIM – preventing BAU teams from removing them unless elevated.
Subscription Design
This one always sparks debate. Do you separate workloads by subscription?
If you’re doing infrastructure as code, there’s very little downside. Subscriptions provide scope boundaries for policies and budgets. More structure = more control.
Deployment Strategy
All of this becomes dramatically easier when you embrace Infrastructure as Code (IaC).
The tangible outputs of Resource Organisation — management groups, policies, subscriptions, role assignments — are no longer something you “click together.” They’re code, and that’s a game-changer.
Azure Landing Zone (ALZ) modules exist for both Bicep and Terraform, and they’ve matured significantly in recent years. You can:
- Use them out of the box
- Customise them to suit your org’s needs and skill levels
- Automate deployments across environments consistently
Consultant Corner: The barrier to entry has never been lower. In the last 12 months alone, the tooling, documentation, and community support around ALZ modules have exploded.
Final Thoughts
Resource Organisation often gets 10 minutes of airtime before everyone jumps to the exciting stuff like networking or app patterns.
But the principle of Resource Organisation underpins everything else. If you can articulate your requirements — even loosely — you can define archetypes, apply structure, and create an environment that’s far easier to manage and govern.
- Understand the principles that Enterprise Scale is trying to acheive.
- Define initial archetypes – even if they are the standard “Internal/Corp” “Publicly Exposed/Online” templates.
- Implement the Management Group Structure and principle of shared Platform as soon as possible.
- Opt for an Infrastructure as Code, if for nothing else but the definition and management of the Platform. Bicep, Terraform, whatever your flavour. The modules exist, and are customisable.