How to Design and Implement an Azure Landing Zone (Subscriptions, Management Groups, RBAC & Policy) – 2026 Guide

If you’ve ever inherited an Azure environment that feels like the wild west—subscriptions scattered everywhere, inconsistent permissions, and zero governance—you already understand the problem. Most Azure environments don’t fail due to lack of capability—they fail due to poor structure.

Designing an Azure landing zone is about setting up a scalable, governed foundation before things get messy. Done right, it gives you consistency, security, and operational clarity across your entire cloud estate.

In this guide, I’ll walk you through how to design and implement a modern Azure landing zone in 2026, focusing on real-world architecture decisions around:

• Subscription strategy
• Management group hierarchy
• RBAC design
• Azure Policy enforcement

This is based on practical experience—not just theory—so you can avoid the common mistakes I’ve seen repeatedly in enterprise environments.

Quick Fix Summary

• Use management groups to enforce governance at scale across subscriptions
• Separate workloads into dedicated subscriptions (Prod, Dev, Shared Services)
• Apply RBAC using groups, not individuals
• Use Azure Policy to enforce compliance and prevent drift
• Automate deployment using Bicep or Terraform, not manual portal builds

Step-by-Step Azure Landing Zone Design

1. Design Your Management Group Hierarchy

Management groups are your governance backbone.

Recommended Structure (Real-World)

Tenant Root
│
├── Platform
│   ├── Identity
│   ├── Management
│   └── Connectivity
│
└── Landing Zones
    ├── Corp
    └── Online

Why This Matters

• Enables policy inheritance
• Centralises governance
• Reduces duplication

Portal Steps

1. Go to Azure Portal → Management Groups
2. Create new groups under the root
3. Assign subscriptions to appropriate groups

PowerShell Example

New-AzManagementGroup -GroupName "Platform" -DisplayName "Platform Services"
New-AzManagementGroup -GroupName "LandingZones" -DisplayName "Landing Zones"

2. Subscription Strategy (Where Most People Get It Wrong)

One of the biggest mistakes I see: too many or too few subscriptions.

Best Practice Model

Key Principles

• Isolation: Separate prod from non-prod
• Billing clarity: Align subscriptions to cost centres
• Security boundaries: Limit blast radius

Pro Tip

Avoid putting everything into a single subscription “to keep it simple.” It never stays simple.

3. Implement Role-Based Access Control (RBAC)

RBAC is where governance often breaks down.

Golden Rule

Never assign permissions directly to users.

Correct Model

• Assign roles to Azure AD groups
• Add users to groups

Common Roles

PowerShell Example

New-AzRoleAssignment `
  -ObjectId <GroupObjectId> `
  -RoleDefinitionName "Contributor" `
  -Scope "/subscriptions/<subscription-id>"

Real-World Lesson

In one environment I reviewed, over 40 users had Owner access. That’s not governance—that’s chaos waiting to happen.

4. Enforce Governance with Azure Policy

Azure Policy is your enforcement engine.

What You Should Enforce Immediately

• Allowed regions
• Required tags (CostCentre, Environment)
• VM size restrictions
• Deny public IP exposure

Example Policy Assignment (PowerShell)

$policy = Get-AzPolicyDefinition -Name "AllowedLocations"
New-AzPolicyAssignment `
  -Name "RestrictLocations" `
  -PolicyDefinition $policy `
  -Scope "/providers/Microsoft.Management/managementGroups/LandingZones"

Pro Tip

Start with Audit mode, then switch to Deny once validated.

5. Implement Tagging Strategy

Tagging is critical for cost management and automation.

Minimum Tags

• Environment (Prod/Dev/Test)
• Owner
• CostCentre
• Application

Why This Matters

• Enables cost reporting
• Supports automation
• Improves accountability

6. Networking Considerations (Hub-and-Spoke)

While not always included in basic landing zone discussions, networking is critical.

Typical Design

• Hub VNet → Shared services (firewall, DNS)
• Spoke VNets → Workloads

Key Components

• Azure Firewall
• VPN Gateway / ExpressRoute
• Private DNS Zones

7. Automate Everything (Seriously)

Manual builds are where inconsistencies creep in.

Recommended Tools

• Bicep
• Terraform
• Azure Blueprints (legacy but still seen)

Example Bicep Snippet

resource rg 'Microsoft.Resources/resourceGroups@2022-09-01' = {
  name: 'rg-prod-app'
  location: 'australiaeast'
}

Additional Tips / Pro Tips

Pro Tips

• Use naming conventions early—renaming later is painful
• Lock down tenant root group permissions immediately
• Enable Azure Activity Logs at management group level
• Integrate with Microsoft Sentinel for security visibility

Warnings

• Overusing Owner role = security risk
• Skipping policy = guaranteed drift
• Poor subscription design = future rework nightmare

FAQ Section

1. What is an Azure landing zone?

A landing zone is a pre-configured Azure environment designed with governance, security, and scalability in mind.

2. How many subscriptions should I create?

It depends on your organisation, but typically separate by environment (Prod/Dev) and function (Networking, Identity).

3. Should I use RBAC or Azure Policy?

Both. RBAC controls who can do something, while Policy controls what can be done.

4. Can I retrofit a landing zone into an existing environment?

Yes—but it’s significantly harder. Expect migration effort and restructuring.

5. What is the biggest mistake in Azure design?

Lack of governance early on—especially around RBAC and policy.

Conclusion / Actionable Takeaways

Designing an Azure landing zone isn’t just about architecture—it’s about discipline and foresight.

Next Steps

1. Review your current subscription structure
2. Implement management groups aligned to best practices
3. Audit RBAC assignments (remove direct user roles)
4. Deploy baseline Azure Policies
5. Start automating your deployments

From experience, the environments that succeed aren’t the ones with the most advanced tech—they’re the ones with clear structure and enforced governance from day one.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.