Azure Landing Zone Checklist: 12 Steps to a Production-Ready Foundation
A practical 12-step checklist for building enterprise-grade Azure landing zones using the Cloud Adoption Framework.
Most failed Azure programmes do not fail because of technology. They fail because someone spun up subscriptions without a plan and spent the next two years patching governance holes. A well-executed Azure Landing Zone eliminates that technical debt before a single workload is deployed.
At CC Conceptualise we have built landing zones for organisations ranging from 200-seat Mittelstand firms to multi-thousand-seat enterprises. Below is the checklist we follow on every engagement.
Why Landing Zones Matter
A landing zone is not a Terraform repo. It is an opinionated, governed environment that provides identity, networking, policy, and cost guardrails so that application teams can move fast without creating risk. Microsoft's Cloud Adoption Framework (CAF) provides the reference architecture; this checklist turns it into action.
Rule of thumb: If you cannot on-board a new workload subscription in under 30 minutes with all policies applied automatically, your landing zone is not done.
The 12-Step Checklist
1. Define Your Management Group Hierarchy
Start with the CAF-recommended structure: a single root management group, then tiers for Platform, Landing Zones (Corp / Online), Sandbox, and Decommissioned. Resist the urge to over-nest. Three to four levels is the sweet spot.
- Map each business unit or workload archetype to a management group
- Ensure your hierarchy supports policy inheritance without excessive exemptions
2. Establish a Naming and Tagging Convention
Before you create a single resource, agree on naming. We recommend a convention that encodes resource type, workload, environment, and region (e.g., rg-erp-prod-westeurope). Enforce mandatory tags — at minimum CostCenter, Owner, Environment, and DataClassification — via Azure Policy with a Deny effect.
3. Configure Azure AD (Entra ID) and Identity
- Enable Privileged Identity Management (PIM) for all administrative roles
- Create break-glass accounts (at least two, hardware-token protected, monitored)
- Implement Conditional Access policies: require MFA, block legacy auth, enforce compliant devices for admin portals
- Federate with your on-premises IdP if applicable
4. Set Up Platform Subscriptions
Separate Management, Identity, Connectivity, and workload subscriptions. Platform subscriptions host shared services and should never contain application workloads.
5. Deploy Hub Networking (or Virtual WAN)
Choose between a hub-and-spoke topology with Azure Firewall or Azure Virtual WAN based on branch-office count and routing complexity.
- Deploy Azure Firewall Premium or a supported NVA in the hub
- Configure UDRs on all spoke subnets to route through the firewall
- Set up ExpressRoute or VPN Gateway for hybrid connectivity
- Enable DDoS Protection Standard on the hub VNet
6. Implement DNS Architecture
- Deploy Azure Private DNS Zones for all PaaS private endpoints (e.g.,
privatelink.blob.core.windows.net) - Link zones to the hub VNet and configure conditional forwarding from on-premises DNS
- Centralise DNS management in the Connectivity subscription
7. Assign Foundational Azure Policies
Deploy the ALZ policy baseline and customise for your requirements. Critical policies include:
- Allowed regions (data residency)
- Deny public IP on NICs in corp landing zones
- Deploy diagnostic settings to a central Log Analytics workspace
- Enforce TLS 1.2 on all PaaS services
- Audit / Deny unmanaged disks
8. Configure Logging and Monitoring
- Create a central Log Analytics workspace in the Management subscription
- Enable Microsoft Defender for Cloud on all subscriptions (at minimum for Servers, SQL, Storage, Key Vault, and Containers)
- Route Activity Logs, NSG Flow Logs, and Firewall Logs to the workspace
- Configure Azure Monitor Alerts for critical platform events
9. Establish Cost Management Guardrails
- Set budgets and alerts per subscription and resource group
- Use Azure Policy to restrict expensive SKUs in non-production environments
- Implement Azure Reservations or Savings Plans for steady-state workloads
- Schedule automated shutdown for dev/test VMs
10. Automate Subscription Vending
Manual subscription creation does not scale. Build a subscription vending machine — an automated pipeline (typically Terraform or Bicep via GitHub Actions / Azure DevOps) that:
- Creates the subscription under the correct management group
- Peers the spoke VNet to the hub
- Applies baseline policies and RBAC
- Deploys mandatory resources (Log Analytics agent config, diagnostic settings)
11. Define RBAC Model and Governance Roles
- Use custom role definitions sparingly; prefer built-in roles
- Assign roles at the management group or subscription level, never at individual resource level
- Create a Platform Engineering team with Contributor on Platform subscriptions and Reader across all
- Workload teams get Contributor on their subscription only
12. Validate with a Canary Workload
Deploy a representative workload into the landing zone before opening it to application teams. Validate:
- Network connectivity (on-premises, internet egress, cross-spoke)
- Policy enforcement (try to violate a policy and confirm it is denied)
- Monitoring (confirm logs flow to the central workspace within minutes)
- Cost tracking (confirm tags and budget alerts fire correctly)
Common Pitfalls
- Skipping the canary step. Teams discover networking or policy issues in production instead of in a controlled test.
- Over-permissive RBAC. Granting Owner at subscription scope to workload teams undoes your governance investment.
- Ignoring policy remediation. Deploying audit-only policies and never reviewing compliance results is the same as having no policy.
- Treating the landing zone as a one-time project. Landing zones require continuous evolution — new Azure services, new compliance requirements, and new workload archetypes all demand updates.
How We Can Help
CC Conceptualise delivers landing zone engagements as a four-to-six-week accelerator: two weeks of design, two weeks of build, and an optional two-week hardening phase where we on-board the first production workload alongside your team. Every engagement produces an as-built document and a backlog of refinements your platform team can execute independently.
Next step: If your Azure environment already exists but was never built on a landing zone foundation, we run a Landing Zone Retrofit Assessment — a one-week review that produces a prioritised remediation roadmap. Get in touch to discuss your scenario.