Governance at Scale
Management groups, subscription design, resource groups, and tagging strategies — architect the organisational hierarchy that keeps thousands of Azure resources under control.
Why governance design matters
Governance is like city planning. Without zoning laws, someone builds a factory next to a school. Without naming conventions, nobody can find anything. Without budgets per department, costs spiral.
In Azure, governance means designing the hierarchy (management groups → subscriptions → resource groups → resources) and the rules (policies, tags, naming conventions) that keep everything organised as you scale.
Good governance is invisible when it works. Bad governance becomes visible when you get a surprise bill or can’t find who owns a resource.
Management group hierarchy design
Management groups sit above subscriptions and let you apply policy and RBAC inheritance at scale.
CAF enterprise-scale landing zone pattern
The most common enterprise pattern follows the Cloud Adoption Framework:
Tenant Root Group
├── Platform
│ ├── Identity (Entra Connect, DNS)
│ ├── Management (Log Analytics, Automation)
│ └── Connectivity (Hub VNet, Firewall, VPN/ER)
├── Landing Zones
│ ├── Corp (internal workloads, hub-spoke network)
│ └── Online (internet-facing workloads, public endpoints)
├── Sandbox (experimentation, no production data)
└── Decommissioned (resources pending deletion)🏛️ David’s CAF implementation: CloudPath Advisory always starts government clients with this hierarchy:
- Platform subscriptions are locked down — only infra team has access
- Landing Zones get pre-configured policies inherited from the management group (e.g., enforce encryption, require tags)
- Sandbox has relaxed policies for experimentation but is isolated from production networks
- Decommissioned is an organisational holding area for resources pending deletion — cleanup requires separate automation (Azure Policy + Logic App or runbook)
Exam tip: Management group depth limit
Azure supports up to 6 levels of management group depth (not counting the root). The CAF pattern typically uses 3-4 levels. Don’t over-nest — deep hierarchies make policy inheritance hard to trace and debug. If you need more than 4 levels, reconsider your organisational model.
Subscription design
Subscriptions are the primary isolation boundary in Azure. They’re also billing units and have service limits (quotas).
When to create a new subscription
| Reason | Example |
|---|---|
| Billing isolation | Each business unit gets its own subscription for cost allocation |
| Scale limits | Approaching subscription quotas (e.g., 250 storage accounts per region per subscription) |
| Environment isolation | Separate subs for dev, staging, production |
| Compliance boundaries | Different regulatory requirements (EU data, government workloads) |
| Team autonomy | Teams that need independent RBAC without affecting others |
| Pattern | Single Subscription | Per Environment | Per Business Unit | Per Workload |
|---|---|---|---|---|
| Isolation | None | Environment-level | Department-level | App-level |
| Cost tracking | Tags only | Sub-level per env | Sub-level per BU | Sub-level per app |
| Management | Simplest | Low (3-4 subs) | Medium (10-20 subs) | High (50+ subs) |
| Blast radius | Largest | Per-environment | Per-department | Smallest |
| Best for | Small orgs, POCs | Most small-medium orgs | Large enterprises | Very large / regulated |
🏗️ Priya’s design: GlobalTech uses per business unit + per environment:
sub-engineering-prod,sub-engineering-dev,sub-engineering-sandboxsub-finance-prod,sub-finance-devsub-platform-connectivity,sub-platform-identity,sub-platform-management
Total: ~15 subscriptions, manageable with Azure Policy at the management group level.
Resource group design
Resource groups are logical containers. Key design principles:
| Principle | Guidance |
|---|---|
| Lifecycle alignment | Resources that are created, updated, and deleted together belong in the same RG |
| Permission boundary | RBAC is commonly applied at RG level — group resources by team ownership |
| Region-agnostic | RGs are metadata — they can contain resources from any region |
| Delete as a unit | Deleting an RG deletes ALL resources inside. Design for safe deletion. |
🚀 Marcus’s resource group pattern: NovaSaaS groups by microservice:
rg-api-gateway-prod— API Management, CDN, WAFrg-user-service-prod— Container Apps, Cosmos DB, Redisrg-batch-processor-prod— Functions, Queue Storage, Batch
Each team owns their resource groups. The platform team owns shared resources (rg-networking-prod, rg-monitoring-prod).
Tagging strategy
Tags are the architect’s metadata tool for governance, cost management, and automation.
Recommended tag taxonomy
| Tag | Purpose | Example Value | Enforcement |
|---|---|---|---|
Environment | Dev/staging/prod classification | Production | Required — Azure Policy |
CostCenter | Financial allocation | CC-4521 | Required — Azure Policy |
Owner | Responsible team or person | platform-team@globaltech.com | Required — Azure Policy |
Application | Which app/service this belongs to | user-service | Required — Azure Policy |
DataClassification | Sensitivity level | Confidential | Recommended |
CreatedBy | Who created the resource | terraform-pipeline | Auto-tag via Policy |
ExpiryDate | When to review/delete | 2026-12-31 | Recommended for non-prod |
Design decision: Tag enforcement with Azure Policy
Don’t rely on people to tag resources manually — they won’t. Use Azure Policy to:
- Require tags on creation:
Require a tag on resource groupspolicy (Deny effect) - Inherit tags from RG:
Inherit a tag from the resource grouppolicy (Modify effect) — resources auto-inherit tags from their parent RG - Append default tags: Auto-add
CreatedDateorCreatedBytags at deployment time
Well-Architected Framework (Cost Optimisation): Tags are the foundation of cost allocation. Without enforced CostCenter tags, you can’t answer “which team spent how much?” — and cost management becomes guesswork.
Azure Policy for tag governance
| Policy | Effect | What It Does |
|---|---|---|
| Require tag on resource groups | Deny | Blocks RG creation without specified tags |
| Inherit tag from resource group | Modify | Auto-copies tag from RG to resources inside |
| Require tag on resources | Deny | Blocks resource creation without tags |
| Add/replace tag | Modify | Force-applies tags (useful for auto-tagging) |
🏛️ David’s government tagging: CloudPath Advisory enforces strict tagging for all government clients:
DataSovereignty: NZ(or AU, US) — mandatory, drives policy about where data can be storedClassification: OFFICIAL/SENSITIVE/PROTECTED— drives encryption and access requirementsAgency: Ministry-of-Health— cost allocation back to the funding agency- All enforced via Azure Policy at the management group level — no exceptions
Knowledge check
🏗️ GlobalTech has 5 business units and needs separate billing, different RBAC permissions per team, and the ability to enforce policies centrally. They want dev and production workloads isolated. Which subscription design should Priya recommend?
🏛️ David's government client requires all Azure resources to have a DataSovereignty tag indicating the approved data residency region. The tag must be present on every resource — no exceptions. Which Azure Policy approach should David recommend?
🎬 Video coming soon
Next up: Hierarchy is designed — now let’s enforce the rules and govern identities — Compliance & Identity Governance.