Set Up an Azure Landing Zone with the ALZ Accelerator

If you want the conceptual comparison of landing zones across AWS, Azure, and GCP first, read What Is a Cloud Landing Zone? before this tutorial — this one assumes you've already decided Azure is the cloud in question and just want it built.

An Azure landing zone is a platform landing zone (the governance, identity, and networking foundation) plus one or more application landing zones (where workload teams actually deploy resources) under it, per Microsoft's Cloud Adoption Framework. This tutorial builds the platform landing zone using Microsoft's own recommended path: the Azure Landing Zones IaC Accelerator, which uses Azure Verified Modules (AVM) for Terraform or Bicep, driven by the ALZ PowerShell module. A portal-based, click-through accelerator also exists, but Microsoft's own guidance is explicit that it's the fallback for teams without IaC expertise, not the primary path — this tutorial builds the thing you'd actually run in production.

Step 1: Decide your reference architecture and IaC language

Before running anything, decide:

• IaC language: Terraform or Bicep. Both use the same underlying Azure Verified Modules, so this is mostly a team-skills decision, not a capability difference.
• VCS/pipeline host: GitHub or Azure DevOps. The accelerator only supports the hosted versions of each (not self-managed GitHub Enterprise Server or on-prem Azure DevOps Server).
• Starting scale: a full enterprise-scale hierarchy, or a smaller starting point you'll grow later. If you're not sure, start smaller — the management group hierarchy is far easier to extend than to collapse once workloads are already assigned to it.

Step 2: Install the ALZ PowerShell module

# Requires PowerShell 7.4+
Install-Module -Name ALZ -Scope CurrentUser

# Confirm your environment actually meets the accelerator's requirements
# before you run anything against a real tenant
Test-AcceleratorRequirement

Test-AcceleratorRequirement checks things like your PowerShell version, required CLI tools, and authentication state — fix anything it flags before continuing.

Step 3: Authenticate and grant subscription-creation rights

The accelerator needs to be able to create subscriptions (or place existing ones) under the management groups it builds. If the identity running the bootstrap isn't already able to create subscriptions under your billing account:

Connect-AzAccount -Tenant "<your-tenant-id>"

# Grant subscription-creator rights to the identity that will run the
# accelerator (a user for an interactive bootstrap, or a service principal
# if you're bootstrapping from a pipeline identity)
Grant-SubscriptionCreatorRole -PrincipalId "<object-id>" -BillingAccountId "<billing-account-id>"

Step 4: Generate the accelerator's folder structure

New-AcceleratorFolderStructure -Destination "./alz-platform"
cd ./alz-platform

This scaffolds the configuration files the bootstrap step reads — the IaC language choice, target management group, naming prefix, and which optional modules (hub networking, additional policies) to include all get set here before you deploy anything.

Step 5: Bootstrap the platform landing zone

Deploy-Accelerator

Deploy-Accelerator is interactive by default and will prompt for anything not already set in the folder structure's configuration — target management group ID, IaC language, VCS host, and repository details. Behind the scenes this is doing the accelerator's four phases in sequence: confirming prerequisites, bootstrapping the CI/CD pipeline and repository in your chosen VCS, and triggering the first deployment of the platform landing zone's Terraform or Bicep code.

Expect this step to take a while — it's provisioning a full management group hierarchy, policy assignments, and (depending on your configuration) centralized logging and networking resources, not a single resource.

Step 6: Verify the management group hierarchy

Once the pipeline completes, confirm the hierarchy actually landed correctly:

az account management-group list --output table

You should see a platform-level structure separating platform resources (identity, management, connectivity — the shared services every workload depends on) from an application/workload landing zones branch (where individual workload subscriptions get placed, commonly segmented into groupings like Corp and Online depending on whether a workload needs public internet exposure), plus dedicated Sandbox and Decommissioned groups for pre-production experimentation and subscription retirement respectively. Treat the exact management group names as configurable rather than fixed — the accelerator lets you set a naming prefix and your organization's specific hierarchy may nest these slightly differently than a default walkthrough would show.

Step 7: Verify policy assignments landed

az policy assignment list --query "[].{name:displayName, scope:scope}" --output table

Confirm policy assignments exist at the management group level (not just subscription level) — that's what makes them apply automatically to every subscription placed under that management group going forward, including ones that don't exist yet.

Step 8: Distribute your first application landing zone

With the platform in place, the actual per-workload unit — an application landing zone — is a subscription (or subscription set, for multi-environment workloads) placed under the appropriate branch of the hierarchy you just built. See Subscription vending in Microsoft's own docs for automating that request-and-provision flow once manual placement stops scaling — the same problem AWS teams solve with Account Factory for Terraform, covered in our AFT deep-dive if you're comparing approaches across clouds.

What you should have now

• A platform landing zone deployed from version-controlled IaC, not console clicks
• A CI/CD pipeline in GitHub or Azure DevOps that owns future changes to the hierarchy
• Policies enforced at the management group level, inherited by every subscription placed under it
• A repeatable path (subscription vending) for handing workload teams their own application landing zone