For years, every Azure team wrote the same Key Vault module. And the same storage account module, and the same virtual network module — each with slightly different defaults, slightly different ways of handling diagnostics and private endpoints, and slightly different bugs. Azure Verified Modules (AVM) is Microsoft's answer to that duplication: one set of Bicep and Terraform modules, built to a common specification and supported by Microsoft. In 2026 it stopped being optional background reading, because Azure Landing Zones are now built on it. Here's what AVM is, what has changed, and how we consume it in client estates.
What Azure Verified Modules are
In the project's own words, AVM is “an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like” (Azure Verified Modules). It is open source, owned by the Azure Deployments team within Azure engineering, and supported by Microsoft. It's also the consolidation of earlier efforts — the FAQ describes AVM as a straight-line evolution of CARML (the Bicep module library) and TFVM — and for Bicep specifically, Microsoft states that AVM is the only standard it publishes in the public module registry.
The practical promise is consistency across both languages: the same module concepts, the same interface names, the same Well-Architected-aligned defaults, whether your team writes Bicep or Terraform.
The three kinds of module
- Resource modules deploy one primary Azure resource, with the Well-Architected Framework's high-priority recommendations set as defaults — and they deliberately don't deploy external dependencies. In Bicep they're published as
br/public:avm/res/<provider>/<resource-type>; in Terraform asAzure/avm-res-...in the Terraform Registry. - Pattern modules compose several resources into an architecture — usually built from resource modules — such as a landing zone or a hub-and-spoke network (
avm/ptn/...). - Utility modules, still in preview, package reusable functions rather than deploying resources (
avm/utl/...).
The catalogue is substantial: as of autumn 2026 the published indexes list roughly 210 Bicep modules and about 155 Terraform modules across the resource and pattern categories, with more proposed (AVM module indexes). Check the index before planning around a module — proposed is not published.
The standard interfaces are the real win
Every resource module exposes the cross-cutting concerns the same way: diagnosticSettings, roleAssignments, lock, tags, managedIdentities, privateEndpoints, customerManagedKey, and availability zones. That sounds like a detail. In practice it's the reason AVM changes how platform teams work: governance requirements — diagnostics to the central workspace, private endpoints only, CMK for regulated data — can be expressed once, in one shape, across every resource type, instead of being re-implemented per hand-rolled module. It's the module-level counterpart to what a governed Azure landing zone does at the platform level.
Why 2026 makes AVM unavoidable: Azure Landing Zones moved
If your landing zone was built with Microsoft's classic modules, this is the part that matters.
Terraform: the long-standing caf-enterprise-scale module is deprecated and was archived — read-only — on September 15, 2026 (GitHub). Its successor is the AVM platform landing zone, built on the avm-ptn-alz pattern module plus companions for management resources, hub-and-spoke or Virtual WAN connectivity, and subscription vending.
Bicep: the classic ALZ-Bicep modules are deprecated. The AVM-based Bicep platform landing zone is now the default starter in the ALZ IaC Accelerator, the classic starter was removed from the Accelerator in February 2026, and the ALZ-Bicep repository receives bug, security and policy fixes until it's archived on February 16, 2027 (GitHub).
The accelerator itself bootstraps the pipelines for either Azure DevOps or GitHub (ALZ Accelerator). So the question for any team running a landing zone built in the last few years isn't whether to engage with AVM — it's when to plan the migration, ideally well before the Bicep archive date rather than in the month of it. Microsoft publishes migration guidance for both paths.
Support, honestly described
AVM is Microsoft-supported, and the mechanics are worth knowing before you depend on it: you can raise a GitHub issue on the module's repository or log a Microsoft support ticket, which support triages and routes to the module owners. What AVM doesn't offer is a fixed response or resolution target for GitHub issues, and modules that lose their owner receive essential maintenance from the core team until a new owner is found (AVM module support). Security vulnerabilities go to the Microsoft Security Response Center, not public issues.
How we consume AVM in client estates
The official guidance stops short of a consumption policy, so what follows is our own practice from running AVM-based platforms:
Pin exact versions. Many modules are still pre-1.0 (0.x.y), and full semantic-versioning guarantees only apply from 1.0 onward — so treat any version bump as potentially breaking. Pin the exact version, as every official quickstart does.
Upgrade on a cadence, not by accident. Only the latest release of a module is supported, so pinning forever isn't safe either. We batch upgrades monthly or quarterly: bump the version, run what-if or plan, review the diff like any other change. For Bicep, enable the use-recent-module-versions linter rule so drift becomes visible in the editor.
Wrap thinly, if at all. A thin internal wrapper that pins the version and sets your organization's defaults (tags, diagnostics destination, private-endpoint-only) is reasonable. A thick wrapper that re-exposes every parameter recreates the very problem AVM exists to solve.
Let the platform enforce, not the module. Modules make the secure configuration easy; Azure Policy makes the insecure one impossible. Use both — the same split we recommend everywhere between guidance and guardrails.
Know the telemetry switch. AVM modules deploy a small telemetry deployment by default to help Microsoft measure usage; it can be disabled with enableTelemetry = false in Bicep or enable_telemetry = false in Terraform (AVM telemetry). Make it a deliberate decision rather than a surprise in a security review.
Where to start
New platform? Start from the ALZ Accelerator and the AVM platform landing zone — there's no longer a good reason to begin anywhere else. Existing landing zone on caf-enterprise-scale or ALZ-Bicep? Inventory what you've customized, read Microsoft's migration guidance, and schedule the move while it's a project rather than an emergency. And for workload teams, replace your next hand-rolled module with its AVM equivalent and see how much code disappears.
Deop builds and migrates Azure landing zones as code — CAF-aligned, AVM-based, with Canadian data residency — as a Microsoft partner with the Infra & Database Migration specialization. See how we deliver Azure landing zones, read our PBMM landing zone guide, or book a discovery.