AVM Adoption as a CAF, WAF, and Zero Trust Alignment Signal

by Matthew

Infrastructure as Code · Azure Verified Modules · CAF · WAF · Zero Trust · Bicep

Matthew Collins · MCT · Azure Infrastructure · IaC · AI Foundry · 6 min read

When I’m reviewing an Azure IaC codebase and I see Azure Verified Modules as the foundation, I’m not just looking at a module choice. I’m looking at a signal about how deeply that organization understands what Microsoft is actually trying to say about how Azure should be deployed.

There are certain terms that get repeated constantly in Azure architecture conversations: CAF-aligned, WAF-aligned, and Zero Trust. They show up in partner advanced specializations, Marketplace certified software designations, and client architectural review meetings. They are used loosely enough that they sometimes seem meaningless, a marketing overlay applied to infrastructure that may or may not actually follow the principles these frameworks describe.

Azure Verified Modules changes that. AVM is Microsoft’s method to encode what CAF, WAF, and Zero Trust alignment actually looks like at the resource level, in code rather than in documentation. If you understand what AVM is doing and why, you understand why adopting it is a genuine alignment signal and not just an easy button for deploying infrastructure via code.

What AVM Actually Is

Azure Verified Modules is Microsoft’s official library of Bicep and Terraform modules, published and maintained by the Azure product engineering teams. It replaces older community patterns like CARML (Common Azure Resource Modules Library) and establishes a specification that module authors must follow for a module to carry the Verified badge.

That specification is the important part. AVM modules are not just convenience wrappers around az CLI commands. They are opinionated implementations that:

• Default to secure configurations (managed identity, no public network access where applicable, private endpoints wired in)
• Include diagnostic settings and monitoring outputs by default
• Follow CAF-standard resource naming abbreviations
• Are designed to compose: they expose consistent outputs so that one module can feed cleanly into another
• Are tested against real Azure deployments, not just template validation

In short, an AVM module for a Key Vault doesn’t just create a Key Vault. It creates a Key Vault the way Microsoft’s own architects would create one if they were following their own published guidance.

Where CAF Alignment Lives in AVM

The Cloud Adoption Framework’s IaC guidance focuses on three things that are often treated as separate concerns: resource naming and tagging, landing zone structure, and governance at scale through Azure Policy. AVM touches all three.

Naming conventions are encoded directly. AVM’s naming helper modules follow CAF abbreviations: kv- for Key Vault, rg- for resource group, st for storage, so a codebase built on AVM produces resource names that are CAF-compliant by default rather than by discipline.

Composability for landing zones is baked into the module design. The CAF landing zone pattern is fundamentally about composing building blocks: connectivity (hub/spoke or Virtual WAN), identity (Entra ID, Privileged Identity Management), management (Log Analytics, Defender for Cloud), and workload landing zones. AVM modules are designed to produce outputs that wire directly into that composition pattern. You’re not fighting the framework to assemble a landing zone; you’re assembling the pieces it was designed to produce.

Policy alignment comes through the WAF side of the specification, but the CAF governance layer, particularly around tagging strategy and resource hierarchy, is reflected in how AVM modules accept and pass through tag parameters across resource hierarchies.

Where WAF Alignment Lives in AVM

The Well-Architected Framework’s five pillars (Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency) each have a footprint in AVM module specifications.

Reliability shows up in zone-redundancy defaults and health probe configurations. AVM modules for compute and networking resources surface availability zone parameters prominently and provide sane defaults rather than leaving zone configuration as an afterthought.

Security is the most visible pillar in AVM. The secure-by-default principle means public network access is disabled where it can be, managed identity is the authentication default, and RBAC assignments are explicit rather than relying on legacy access key patterns. A Key Vault module that enables purge protection and soft delete by default is making a WAF Security decision on your behalf.

Operational Excellence is reflected in the diagnostic settings pattern. AVM modules accept a diagnosticSettings parameter block that routes logs and metrics to your Log Analytics workspace. In a codebase without AVM, enabling diagnostics on every resource is a discipline problem: it happens when someone remembers to add it. In an AVM-based codebase, it’s a parameter you pass, consistently, across every resource type.

Cost Optimization and Performance Efficiency are less prescriptive at the module level; these pillars require context that a generic module can’t have. But AVM surfaces SKU choices and right-sizing parameters in a way that forces an explicit decision rather than defaulting to the largest or cheapest option silently.

Where Zero Trust Alignment Lives in AVM

Zero Trust is not a product or a feature set. It is a security model built on three principles: verify explicitly, use least privilege access, and assume breach. In an Azure IaC context, those principles translate directly into resource configuration decisions that AVM modules make by default.

Verify explicitly is reflected in AVM’s identity defaults. Every module that can use managed identity does. Shared access keys and connection strings are not the default authentication path; they are explicitly surfaced as override options that require a conscious decision to enable. You do not accidentally deploy a storage account that authenticates via key because the module’s secure default points you toward identity-based access.

Use least privilege shows up in how AVM modules handle RBAC. Rather than granting broad Contributor access at a resource group level, AVM modules surface granular data-plane role assignments: Storage Blob Data Reader, Key Vault Secrets User, Service Bus Data Sender. The module design pushes you toward the minimum required permission surface rather than the most convenient one.

Assume breach is encoded in the observability and resilience defaults. Diagnostic settings enabled by default means audit logs are flowing from day one, not after an incident triggers a scramble to enable logging retroactively. Private endpoints, network access restrictions, and soft delete with purge protection are all assume-breach configurations: they limit blast radius, preserve forensic data, and make recovery possible.

The distinction between WAF Security and Zero Trust in AVM is worth naming. WAF Security covers the broad security posture of a workload: encryption, key management, access control, threat detection. Zero Trust is specifically the trust model governing how identity and network position interact. An AVM-based codebase can satisfy WAF Security requirements through correct configuration choices. Zero Trust alignment requires the identity-first, least-privilege, assume-breach posture to be the default, not the exception. AVM’s module specification makes it the default.

The Architect’s Signal in the Marketplace

AVM adoption as a market signal is worth examining, particularly for Azure SDCs building Marketplace offers.

Before AVM was formalized, early IaC adopters were arriving at similar patterns independently: modular Bicep, consistent outputs for composition, diagnostics by default, managed identity everywhere, CAF naming. The discipline to build this way came from deep engagement with CAF, WAF, and the Azure architecture review process. You had to already understand the frameworks to build in alignment with them.

AVM formalizes that understanding into a library, which means two things are now true simultaneously:

First, an architect who adopts AVM without understanding why is getting alignment as a side effect, which is genuinely good for the Azure ecosystem. Defaults matter at scale.

Second, an architect who understands why AVM is designed the way it is, and can explain what WAF pillar a particular module default is serving and what trade-off it’s making, is demonstrating something that a library dependency alone cannot. That architect is aligned with Microsoft’s direction, not just dependent on the library.

For SDCs building on AVM, that alignment becomes a commercial differentiator. An offer built on AVM modules carries verifiable CAF, WAF, and Zero Trust alignment by construction, not as a line item on a co-sell submission checklist, but as an architectural property of the codebase itself. In a Marketplace where many offers position around framework alignment, demonstrating it through the code is what separates a proof from a claim.

What This Means in Practice

If you’re building or reviewing Azure IaC today, a few practical implications follow from this framing:

Use AVM as a specification, not just a dependency. Read the module specifications at azure.github.io/Azure-Verified-Modules. Understand what each parameter is doing and which WAF pillar it serves. The library is the implementation; the spec is the knowledge.

Treat AVM non-compliance as a gap to explain, not ignore. There will be cases where your environment requires deviation from AVM defaults: specific network topologies, compliance requirements, legacy constraints. Document those deviations and their reasoning. An architecture that deviates from AVM with documented rationale is stronger than one that follows AVM without understanding it.

Let AVM alignment drive your marketing narrative. If your Marketplace offer or Azure managed service is built on AVM, that is a concrete, verifiable CAF, WAF, and Zero Trust alignment claim, not a positioning statement. Make it explicit in your offer listing and marketing materials.

The Longer View

Microsoft’s direction for Azure IaC is unambiguous: Bicep is the authoring format, AVM is the module standard, and CAF, WAF, and Zero Trust are the frameworks that ground both. Those who are building in alignment with that direction now are building toward where the Microsoft Partner programs, the Marketplace certification requirements, and the architecture review processes are heading.

AVM adoption is a signal. Understanding why it’s designed the way it is turns that signal into something more valuable: a demonstrable, articulable alignment with how Microsoft thinks Azure should be built.

Stay in the flow, avoid the noise.

#AzureVerifiedModules #Bicep #InfrastructureAsCode #CloudAdoptionFramework #WellArchitected #ZeroTrust #AzureArchitecture #