An Azure Landing Zone is the foundational architecture that every enterprise needs before deploying workloads at scale. It's the difference between a well-governed cloud environment and a sprawling mess of subscriptions, resources, and security gaps that nobody can manage.

Microsoft's Cloud Adoption Framework provides the blueprint. This guide translates that blueprint into practical decisions.

What a Landing Zone Provides

A properly designed landing zone gives you:

Identity and access management — who can do what, governed by policy
Network topology — how workloads communicate, with segmentation and security
Management and monitoring — visibility into everything running in your environment
Security baseline — guardrails that prevent insecure configurations
Governance — policies that enforce compliance automatically
Cost management — budgets, alerts, and accountability

Without this foundation, every team builds their own approach, creating inconsistency, security gaps, and ungovernable sprawl.

The Enterprise-Scale Architecture

Management Group Hierarchy

Tenant Root Group
├── Platform
│   ├── Management (Log Analytics, Automation)
│   ├── Identity (Entra ID, Domain Controllers)
│   └── Connectivity (Hub networking, DNS, Firewall)
├── Landing Zones
│   ├── Corp (Internal workloads, private connectivity)
│   └── Online (Internet-facing workloads)
├── Sandbox (Experimentation, no production data)
└── Decommissioned (Resources being retired)

Why this structure matters: Azure Policy is inherited down the management group hierarchy. Policies applied at "Landing Zones" affect all workloads. Policies applied at "Corp" affect only internal workloads. This enables governance at scale without per-subscription management.

Subscription Strategy

One subscription per workload per environment is the recommended pattern for enterprise scale:

app-payments-prod
app-payments-staging
app-customer-portal-prod

Why separate subscriptions?

Blast radius containment (a misconfiguration in one subscription doesn't affect others)
Clear cost attribution (each subscription maps to a cost centre)
Independent RBAC (teams manage their own subscription without affecting others)
Azure limits are per-subscription (separate subscriptions avoid hitting resource limits)

Networking

Hub-and-Spoke (Recommended for Most)

                    ┌─────────────────┐
                    │    Hub VNet      │
                    │  Azure Firewall  │
                    │  VPN Gateway     │
                    │  DNS Resolver    │
                    └────────┬────────┘
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
        ┌──────────┐  ┌──────────┐  ┌──────────┐
        │  Spoke 1 │  │  Spoke 2 │  │  Spoke 3 │
        │  App A   │  │  App B   │  │  App C   │
        └──────────┘  └──────────┘  └──────────┘

The hub contains shared networking services (firewall, VPN/ExpressRoute gateway, DNS). Spokes contain workloads. All traffic between spokes routes through the hub firewall for inspection and policy enforcement.

Virtual WAN (For Complex or Multi-Region)

Azure Virtual WAN replaces the manual hub-spoke with a managed networking service. Better for multi-region deployments, large numbers of spokes, and SD-WAN integration.

Decision: Use hub-spoke for single-region or simple multi-region. Use Virtual WAN when you have 20+ spokes, complex routing, or need managed SD-WAN integration.

Identity — Entra ID

Non-negotiable configurations:

Conditional Access policies: Require MFA for all users, block legacy authentication, enforce compliant devices for sensitive resources
Privileged Identity Management (PIM): Just-in-time access for admin roles. No standing admin access
Break-glass accounts: 2 emergency access accounts with strong passwords stored in a physical safe. Excluded from Conditional Access. Monitored for any usage
Service principals and managed identities: Applications authenticate with managed identities (no stored credentials), not service principals with secrets

Governance — Azure Policy

Essential policies to enforce:

Policy	Effect	Why
Allowed locations	Deny	Data sovereignty compliance
Require tags (cost centre, owner, environment)	Deny	Cost attribution and accountability
Deny public IP on VMs	Deny	Prevent accidental internet exposure
Require HTTPS on storage accounts	Deny	Encrypt data in transit
Deploy diagnostic settings	DeployIfNotExists	Ensure all resources log to central Log Analytics
Require encryption at rest	Deny	Data protection baseline
Deny certain VM SKUs	Deny	Cost control (prevent expensive GPU VMs in dev)

Implementation approach: Start with audit mode to understand current state, then switch to deny mode once you've confirmed no legitimate workloads are affected.

Security

Microsoft Defender for Cloud: Enable on all subscriptions. Configure security contacts, enable auto-provisioning, and set the Secure Score target.

Microsoft Sentinel: Centralised SIEM for security event collection, detection, and response. Connect all Azure activity logs, Entra ID logs, and workload logs.

Network security:

Azure Firewall for east-west and north-south traffic filtering
Network Security Groups (NSGs) on every subnet
Azure DDoS Protection Standard on internet-facing resources
Private Link for PaaS services (storage, databases, key vaults)

Automation

Infrastructure as Code is mandatory. Manual portal deployments create ungovernable environments.

Tool	Best For
Bicep	Azure-native, simpler syntax than ARM, first-class Azure support
Terraform	Multi-cloud, larger ecosystem, state management
Azure Verified Modules	Pre-built, tested modules for common patterns

Landing zone deployment: Use the Azure Landing Zone Accelerator (Bicep or Terraform) as your starting point. Customise from there rather than building from scratch.

Common Mistakes

Starting without a landing zone. Teams deploy workloads directly, then try to retrofit governance. This is 10x harder than starting right.
Over-engineering for day one. Design for your current needs with a clear path to scale. You don't need Virtual WAN for 3 subscriptions.
Ignoring hybrid connectivity. Most enterprises have on-premises systems. Plan ExpressRoute or VPN connectivity from the start.
No tagging strategy. Without consistent tags, you can't attribute costs, identify owners, or enforce policies. Define the tagging standard before the first resource is deployed.
Manual governance. If compliance depends on humans remembering to follow procedures, it will fail. Use Azure Policy to enforce automatically.

The landing zone is the foundation of your Azure environment. Get it right and every subsequent deployment is faster, more secure, and more governable. If you're planning an Azure landing zone or need to refactor an existing environment, let's talk.

Azure Landing Zone Architecture: Enterprise-Scale Design Patterns