Selectable Export PowerShell Engine arrives for the Granfeldt PowerShell Management Agent
June 24, 2026How to Deploy Azure Local Small Form Factor (SFF) – Bringing Azure to the Edge
June 24, 2026Hello Folks!
Welcome back to my coverage of the Microsoft Azure Infra Summit 2026. This session is one I have been looking forward to, because if you have ever stood up an Azure Landing Zone (ALZ) by hand, you know it can eat weeks. Management groups, policy assignments, Hub-and-Spoke networking, log analytics, Defender for Cloud, identities, pipelines, governed branches. There is a lot of plumbing.
In this session Jack Tracy (he leads the Azure Landing Zones team) and Jarrod Holgate (tech lead on Azure Landing Zones and Azure Verified Modules) walk through the ALZ Infrastructure as Code Accelerator. Then they actually run it, and a bootstrap that used to be a multi-week journey wraps up in about twelve minutes of typing and ticking boxes.
📺 Watch the session:
Why IT Pros Should Care
If you are the person who has to deliver a secure, governed Azure platform before your dev teams can land their first workload, this matters to you. Here is the short version of why:
- It bakes in the Cloud Adoption Framework “start right, stay right” pattern so you do not have to invent it.
- It supports both Bicep and Terraform, and it bootstraps GitHub or Azure DevOps for you (with a local file system option for GitLab, Bitbucket, or whatever else you run).
- It covers roughly 80% of common customer scenarios out of the box. You do not have to write modules from scratch.
- It is open source, every module is published, and you can fork or compose as you see fit.
- It is now built entirely on Azure Verified Modules (AVM), so what you deploy is aligned with the Well-Architected Framework by default.
In short, if you have been hand-crafting management group hierarchies and policy assignments in the portal, stop. There is a better way, and the team that designs ALZ ships it as code you can actually read.
What is the ALZ IaC Accelerator
A quick recap, because it is worth getting the vocabulary right.
The Azure Landing Zone lives inside the CAF Ready methodology. It is the shared platform (networking, identity, logging, policy, management groups) that supports the many application landing zones your workload teams consume. Jack uses a great analogy in the session: think of a metropolis. Before residents and businesses can move in, you need water, gas, electricity, and roads. The platform landing zone is the utilities layer. The application landing zones are the buildings.
The ALZ IaC Accelerator is the tooling that deploys and manages that platform layer using declarative infrastructure as code. It is composed of:
- A set of IaC modules in Bicep and Terraform (all of them built on AVM).
- A bootstrap layer for GitHub or Azure DevOps (or local file system).
- The ALZ PowerShell module, published to the PowerShell Gallery, which orchestrates everything.
- Comprehensive docs covering prereqs, scenarios, and options.
The accelerator is a Microsoft-supported, open source path to a production-grade landing zone. You should look at it before you decide to roll your own.
How it works
The accelerator runs in four phases. Jarrod walks through each of them in the demo.
Phase 0: Plan. You make decisions: Bicep or Terraform, GitHub or Azure DevOps, single or multi-region, Hub-and-Spoke or Virtual WAN, Azure Firewall or NVA, DDoS on or off, and so on.
Phase 1: Prereqs. Before the accelerator runs, you need two things in place: an identity to run the bootstrap, and the platform subscriptions. Traditionally this was four (connectivity, identity, management, security). There is now a new lighter option that needs only two subscriptions for smaller environments.
Phase 2: Bootstrap. This is where the magic happens. You feed it a bootstrap configuration file plus a platform landing zone configuration file, then run the Deploy-Accelerator command. The PowerShell module deploys identities, optional Terraform state storage with private networking, optional self-hosted container-instance runners, and then sets up your repositories, pipelines, environments, governed pipeline templates, and OIDC-based service connections using Workload Identity Federation. No manual steps after Phase 2.
Phase 3: Deploy. Run the CD pipeline. The platform landing zone deploys. Done.
A few things worth highlighting about the bootstrap:
- The accelerator deploys two identities: one with read-only for plan / what-if, one with write for apply / deploy. Least privilege, out of the box.
- Pipelines are governed. The actual deployment pipeline lives in a separate template repository, so changes to it require an approval.
- A CI pipeline runs on pull requests automatically. You get the engineering hygiene without configuring it.
Real-world scenarios and when to use it
Jarrod calls these “scenarios” and “options”. They are the difference between picking a starting pattern (scenario) and tuning it (options).
Scenarios. There are 11 of them out of the box. Pick the one that matches your starting state:
- Single region, Hub-and-Spoke, Azure Firewall.
- Multi-region, Hub-and-Spoke, Azure Firewall.
- Single or multi-region with Virtual WAN.
- Single or multi-region with a third-party NVA.
- No-connectivity (governance only, no Hub networking) for organizations who are not ready for centralized networking yet.
- New scenarios 10 and 11, which are cost-optimized for small and medium businesses with around 10 workloads. Same modules, same orchestration, just a smaller, cheaper starting shape.
- Sovereign landing zone for customers with data sovereignty and confidential compute requirements.
Options. Once you pick a scenario, you can tune it. The 16 documented options are the ones the team sees customers ask about most often: customizing resource names, customizing management group names, turning the DDoS protection plan on or off, choosing the sovereign baseline, and more. Behind those, Terraform alone exposes hundreds of variables.
Honest tradeoffs (because Pierre always tells you the rough edges):
- OpenTofu is not supported today. Just Bicep and Terraform.
- Personal Access Tokens are still required for Azure DevOps and self-hosted agents at the time of the session. The team has confirmed CLI / managed identity support is on the roadmap.
- Brownfield is “it depends”. The accelerator is greenfield-friendly. Retrofitting an existing tenant is possible but is going to depend on your current state and your risk appetite.
- You still own decisions. The Lady Justice slide in the session is a great reminder: balancing dev team freedom with central governance is your job. The accelerator gives you the controls; it does not pick your policy posture for you.
Getting Started
If you want to try this without waiting, here is the path Jarrod actually demoed:
- Install the ALZ PowerShell module from the PowerShell Gallery.
- Create your platform subscriptions (two minimum, four for the classic layout) and an identity for the bootstrap.
- Run Deploy-Accelerator with no parameters. It will prompt you interactively for everything: region, parent management group, subscriptions, naming convention, self-hosted agents yes or no, private networking yes or no, PAT, project name, and approvers.
- Review the two generated configuration files: the bootstrap config and the platform landing zone tfvars (or Bicep params).
- Confirm. The bootstrap runs Terraform behind the scenes and wires up Azure plus your repos.
- Run the CD pipeline. Approve at the apply stage. Your platform deploys.
If you are not ready to drive Terraform directly, the Azure Migrate AI agent (in preview) wraps the exact same accelerator codebase behind a guided chat experience. You answer questions, it produces a zip with the same two config files plus a design document explaining the decisions it made. Then you hand that off to the same pipeline. The Azure MCP server has matching tooling for VS Code, so day-two changes like “turn off the DDoS protection plan” know to also uncomment the dependent policy assignments in the archetype files. That is the kind of context-aware editing that saves you from breaking your own deployment.
Resources
- Azure Landing Zone in the Cloud Adoption Framework
- ALZ Accelerator hub (entry point for docs, scenarios, options)
- ALZ Terraform Accelerator on GitHub
- ALZ-Bicep on GitHub
- Azure Landing Zones Library (policies and archetypes)
- Azure Verified Modules
- Raise issues or feedback for the ALZ team
Watch the rest of the Summit
If you found this useful, the full Microsoft Azure Infra Summit 2026 playlist has a lot more: deployment stacks, Bicep beyond the basics, IaC CI/CD best practices, AVM with GitHub Copilot, and plenty of AKS and storage sessions. Grab the playlist here: Microsoft Azure Infra Summit 2026 on YouTube.
Hit the ALZ team in the comments on the session, or open an issue on the repo. The team is genuinely active there.
Cheers!
Pierre Roman