Azure Landing Zones: the practical guide (secure-by-default, engineer-friendly)

Why landing zones still matter

If you inherited an Azure estate where every subscription looks different, RBAC is welded to people, and nobody can prove logs land anywhere useful, you have already met the debt a landing zone avoids. A landing zone is the operating model plus the technical scaffolding that makes every new workload trustworthy by default. If vending a subscription takes a service request and a best-effort checklist, you do not have one yet.

What good looks like

• One management group hierarchy with clear owners: tenant root → Platform → LandingZones → workload scopes.
• Subscription vending pipeline that assigns RBAC, policy, and diagnostics automatically based on metadata.
• Guardrails split into deny (foot-guns), deployIfNotExists (baseline config), and audit (future enforcement).
• Shared networking/DNS patterns owned by platform, not retrofitted per workload.
• Logging + security operations with agreed routings for alerts, playbooks, and break-glass accounts.
• Runbooks for change: Day 0 baseline, Day 30 hardening, quarterly review with measured drift.

Baseline decision points

1. Management group layout – Keep it shallow: Tenant Root → Platform for shared services, LandingZones for workloads, optional Sandbox for experiments.
2. Subscription lifecycle – Who can request one, what metadata is mandatory, how long until retirement, and how vending is automated (GitHub Actions / Azure DevOps).
3. Identity boundaries – Which groups map to which RBAC roles, how PIM and break-glass are handled, and where admin workstations sit.
4. Policy scope – Decide which guardrails land at the LandingZones management group and which are delegated to workload owners. Avoid “deny everything” until telemetry proves it is safe.
5. Networking + DNS – Hub and spoke vs vWAN, who owns private DNS zones, how Private Endpoint approvals work, and how shared firewalls are funded.
6. Operations + alerts – Where Defender, Sentinel, and platform alerts go, who triages, and how exemptions expire.

Signal vs noise

• Enable now: cost guardrails, public network denies, default diagnostic settings, Defender for Cloud plans you have owners for (Servers, SQL, Storage).
• Delay until Day 30: advanced Defender plans (Containers, APIs) if the SOC is not ready; aggressive TLS mandates if legacy workloads still exist; network micro-segmentation before hub routing is proven.
• Probably never: auto-enabling extensions nobody operates (legacy Log Analytics agents), enforcing niche policies because “the template had them,” or enabling Defender plans without budget. Every alert without an owner is noise.

Phased rollout

• Day 0 (Baseline) – Deploy management groups, core policies (deny obvious foot-guns, deploy diagnostics), subscription vending automation, and central logging.
• Day 30 (Hardening) – Review alert volume, promote high-confidence audits to deny, enable the next set of Defender plans, and extend diagnostics to tier-two services.
• Quarterly (Operate) – Measure drift (policy compliance, RBAC, diagnostics), prune unused subscriptions, update the initiative versions, and review exemptions.

Runbook: build an Azure landing zone you can scale

Before running the subscription vending pipeline, apply this Terraform snippet to create management groups and a dedicated logging workspace scope. Update the parent_management_group_id and role assignment object IDs to match your tenant.

resource "azurerm_management_group" "platform" {
  display_name = "Platform"
  name         = "mg-platform"
}

resource "azurerm_management_group" "landingzones" {
  display_name            = "LandingZones"
  name                    = "mg-landingzones"
  parent_management_group_id = azurerm_management_group.platform.id
}

resource "azurerm_log_analytics_workspace" "landing" {
  name                = "lz-law-plat"
  location            = "uksouth"
  resource_group_name = "rg-operations-core"
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

resource "azurerm_role_assignment" "log_contributor" {
  scope                = azurerm_log_analytics_workspace.landing.id
  role_definition_name = "Log Analytics Contributor"
  principal_id         = var.platform_team_object_id
}

When creating initiatives, keep parameters lightweight so they can be reused. This Bicep skeleton creates an initiative plus an assignment at the LandingZones management group. Edit the policy definition references to match your catalogue.

param landingZonesMgId string

var policySet = {
  name: 'alz-lz-guardrails'
  displayName: 'Landing Zone Guardrails'
  description: 'Baseline deny + deploy rules for workload subscriptions.'
  policyDefinitions: [
    {
      policyDefinitionReferenceId: 'deny-public-ip'
      policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/your-deny-id'
      parameters: {}
    }
    {
      policyDefinitionReferenceId: 'deploy-diagnostics'
      policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/your-deploy-id'
      parameters: {
        logAnalytics_: {
          value: '/subscriptions/${subscription().subscriptionId}/resourceGroups/rg-operations-core/providers/Microsoft.OperationalInsights/workspaces/lz-law-plat'
        }
      }
    }
  ]
}

resource initiative 'Microsoft.Authorization/policySetDefinitions@2021-06-01' = {
  name: policySet.name
  properties: policySet
}

resource assignment 'Microsoft.Authorization/policyAssignments@2021-06-01' = {
  name: 'alz-lz-guardrails'
  properties: {
    displayName: 'Apply baseline guardrails to LandingZones'
    policyDefinitionId: initiative.id
    scope: landingZonesMgId
  }
}

Use the Azure CLI to verify every subscription emits diagnostics to your workspace. Replace the subscription and workspace names before running.

az account set --subscription "<workload-subscription>"
az monitor diagnostic-settings list --resource "/subscriptions/<workload-subscription>" \
  --query "[?name=='send-to-law'].*"

Validation checks

Use these KQL queries and governance checks to prove the landing zone is behaving.

Before running the KQL, swap the workspace name for your central Log Analytics instance. The query lists subscriptions that have not streamed activity logs in the last 24 hours.

AzureActivity
| summarize count() by SubscriptionId, bin(TimeGenerated, 1d)
| where TimeGenerated < ago(1d)

Common pitfalls

Rollback / back-out plan

• Policy releases – disable or reassign the offending policy assignment; leave the definition in place to avoid referencing issues. Remediate the resources separately.
• Vending pipeline failures – subscriptions created during failed runs should be moved to a quarantine management group, stripped of RBAC, then reprocessed once the pipeline is fixed.
• Networking/DNS rollbacks – revert to the previous hub configuration through IaC; publish the change window and flush Private DNS zones after validation.
• Logging changes – if diagnostic settings cause duplicate ingestion cost, roll back the deployIfNotExists policy assignment and reapply once the policy definition is corrected.

Document every rollback in the platform change log and include the date you expect to re-attempt the change. Landing zones are only “done” when you can repeat them safely.