Designing Azure Landing Zones That Scale Past Your First Hundred Subscriptions

Most landing zone deployments look great in the diagram and fall apart at subscription fifty. The management group tree calcifies, policy exemptions multiply, and the platform team becomes a ticket queue. This article covers the decisions that determine whether your landing zone scales — made before you deploy anything.

Start with the management group hierarchy you'll need in year two

The Cloud Adoption Framework's default hierarchy is a starting point, not a destination. The mistake teams make is modelling the org chart instead of modelling policy variance. Two workloads belong in the same management group if — and only if — they should inherit the same policies.

A structure that has survived several enterprise rollouts:

Tenant Root
└── Contoso
    ├── Platform
    │   ├── Identity
    │   ├── Management
    │   └── Connectivity
    ├── Landing Zones
    │   ├── Corp        (private, hybrid-connected)
    │   └── Online      (internet-facing)
    ├── Sandbox         (loose policy, budget-capped)
    └── Decommissioned  (deny-all, awaiting deletion)

Policy as code, or policy as chaos

Every policy assignment should live in source control and deploy through a pipeline. Portal-assigned policies are how you end up with drift nobody can explain. With Bicep, a policy assignment is a first-class resource:

targetScope = 'managementGroup'

resource denyPublicIp 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
  name: 'deny-public-ip-corp'
  properties: {
    displayName: 'Deny public IPs in Corp landing zones'
    policyDefinitionId: tenantResourceId(
      'Microsoft.Authorization/policyDefinitions',
      '6c112d4e-5bc7-47ae-a041-ea2d9dccd749'
    )
    enforcementMode: 'Default'
  }
}

Keep three assignment tiers: audit at the top of the tree, deny at the landing-zone tier, and deployIfNotExists for the platform guarantees (diagnostics, defender plans, backup). Resist the urge to deny at root — you will break the platform team's own automation within a month.

Subscription vending is the product

The landing zone isn't the diagram; it's the vending machine. A workload team should get a compliant subscription — networking peered, policies inherited, budget alert wired, RBAC granted — from a pull request, in under an hour, with no human in the loop.

What to watch after go-live

• Policy exemption count. Rising exemptions mean your tiers are wrong — fix the tree, don't accumulate exceptions.
• Time-to-subscription. If it creeps past a day, teams will start sharing subscriptions, and your blast-radius model dies.
• Orphaned resources in Decommissioned. Automate deletion after a grace period; the deny-all policy makes this safe.

The teams that succeed treat the landing zone as an internal product with a roadmap, versioned releases, and users — not as a one-off migration project.