Azure Landing Zone Architecture: What We Actually Deploy

The first thing to understand about an Azure landing zone is that Microsoft's documentation describes a destination, not a starting point. The CAF reference architecture is correct about the end state. It is almost never a useful build plan for a team that has three weeks and a real workload waiting.

We have shipped landing zones for regulated fintech, manufacturing, and public sector. What follows is what we actually do, and where we have watched well-intentioned teams fall over.

Management Group Hierarchy Is Load-Bearing

The hierarchy is not cosmetic. Policy, RBAC, and cost-rollup all inherit down the tree. Getting this wrong means you are reassigning policies at the subscription level forever, which defeats the point.

The minimal hierarchy that works in practice:

Tenant Root
└── org-root (MG)
    ├── platform (MG)
    │   ├── connectivity (sub)
    │   ├── identity (sub)
    │   └── management (sub)
    ├── landing-zones (MG)
    │   ├── corp (MG)
    │   │   └── workload-a (sub)
    │   └── online (MG)
    │       └── workload-b (sub)
    ├── sandbox (MG)
    └── decommissioned (MG)

The corp vs online split matters for network policy inheritance. Corp children get private connectivity to on-premises. Online children do not; they get stricter egress controls instead. Do not collapse them into one MG because it feels simpler now. You will pay for the merge later when a workload team needs different outbound rules.

One mistake we see consistently: assigning policy at the subscription level during a proof-of-concept, then assuming the hierarchy inherits it. It does not work that way. Assignments at a child scope do not propagate upward. Audit assignments at the tenant root and platform MG, remediation assignments as close to the target as sensible.

Policy First, Resources Second

Every subscription that lands under landing-zones should be policy-compliant before the first workload VM is created. That means the Bicep or Terraform that vends the subscription also assigns the baseline policy set.

The policies worth assigning at the landing-zones MG level, at minimum:

• Deny public IP creation on NICs (except explicitly exempted subs under online)
• Require diagnostic settings sent to the central Log Analytics workspace
• Deny resource deployment outside approved regions
• Require tags: environment, owner, cost-center
• Deploy Azure Monitor agent to VMs automatically (DeployIfNotExists)

The DeployIfNotExists policies need a managed identity with Contributor on the target scope. That identity should be provisioned by the landing zone pipeline, not handed out manually.

// Assign the baseline initiative at the landing-zones management group
resource policyAssignment 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'baseline-corp-controls'
  scope: managementGroup(landingZonesMgId)
  identity: {
    type: 'SystemAssigned'
  }
  location: 'eastus2'
  properties: {
    policyDefinitionId: baselineInitiativeId
    enforcementMode: 'Default'
    parameters: {
      logAnalyticsWorkspaceId: {
        value: centralWorkspaceId
      }
      allowedLocations: {
        value: ['eastus2', 'centralus']
      }
    }
  }
}

// Role assignment for the DINE managed identity
resource remediationRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(policyAssignment.id, 'contributor')
  scope: managementGroup(landingZonesMgId)
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c')
    principalId: policyAssignment.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

Do not skip the enforcementMode. Teams that set it to DoNotEnforce to "test first" and never flip it back are running in placebo mode for months.

Hub-Spoke vs Virtual WAN

This is the decision that takes the most time in design reviews, and most teams overthink it.

Virtual WAN is the right answer when you have more than two regions, multiple ExpressRoute circuits, or a heavy branch-office connectivity requirement. The routing automation it provides is genuinely useful at that scale. Under that threshold, a traditional hub-spoke with Azure Firewall is cheaper, easier to reason about, and faster to operate.

For a typical enterprise with one primary region:

• Deploy a dedicated connectivity subscription under the platform MG.
• Put a hub VNet there with Azure Firewall Premium and a VPN/ER gateway.
• Spoke VNets live in workload subscriptions, peered to the hub.
• All egress routes from spokes point at the firewall's private IP via a route table.
• DNS: Azure Private DNS Resolver in the hub, with conditional forwarders for on-premises zones.

The firewall policy structure matters. Use a global base policy at the connectivity subscription level. Workload teams can create child policies that inherit the base. This keeps the security team in control of the parent rules without blocking workload teams from adding application-specific rules under their own child policy.

Identity and Privileged Access

Most landing zone guides treat identity as a step, not a design surface. We treat it as a hard constraint.

Entra ID groups, not individuals, get RBAC assignments. Every group name encodes the scope and role: az-sub-workload-a-contributor, az-mg-corp-reader. This makes entitlement reviews fast enough that people actually do them.

Privileged Identity Management is non-negotiable for anything above Reader. Just-in-time activation with a maximum 8-hour window and an approval requirement for Owner and User Access Administrator. The approval notification goes to a Teams channel, not an individual's email. People ignore email at 11pm. They notice a Teams ping in a channel called #azure-pim-approvals.

Break-glass accounts: two, federated to nothing, MFA hardware-only, stored in a physical safe. Their last-sign-in date appears on a weekly Sentinel alert. If that alert fires, someone is using the break-glass account, and you need to know within minutes.

Subscription Vending

Landing zones are not one-time builds. Platform teams that hand-craft each subscription burn out. Automate subscription creation from day one.

The vending machine pattern is straightforward: a Git repository where workload teams submit a pull request with a YAML manifest describing what they need. A pipeline picks it up, creates the subscription under the correct MG, assigns policy, creates the baseline resource group, and posts a summary back to the PR. No tickets, no manual steps.

The manifest is simple on purpose:

name: workload-payments
management-group: corp
owner-group: az-sub-workload-payments-owner
cost-center: "4421"
regions:
  - eastus2
environment: production
connectivity: hub-spoke

Keep the schema conservative. Features get added to the manifest only when multiple teams request the same thing. This is the one place where saying no to early customization pays off.

Common Failure Modes

After deploying and inheriting landing zones across a range of client sizes, the same failure modes appear:

The sandbox MG gets forgotten. Teams spin up resources in sandbox, the 90-day cleanup policy that was "going to be added later" never gets added, and sandbox becomes a sprawl vector. Set an auto-shutdown policy and a budget alert from the start. Sandbox exists to experiment, not to host shadow production.

Log Analytics workspace consolidation is delayed until it hurts. Multiple workspaces created organically, no central one, and then Sentinel has to be deployed across all of them. Central workspace from day one, workload teams send diagnostics to it. Workload-specific workspaces are fine for application-level logs where the workload team owns the query bill; they are not fine as the only destination for platform telemetry.

Azure Policy remediation tasks pile up and no one runs them. Assign ownership of the remediation task backlog in your on-call runbook. A compliance score of 40% is not a landing zone, it is a suggestion.

See our cloud architecture practice for how we scope and deliver these engagements, including accelerators for regulated industries.

When to Call Us

If your team is designing a landing zone for the first time, inheriting one that grew organically, or preparing for a compliance audit and discovering the policy baseline was never enforced, reach out and we can scope an architecture review or a full build engagement.