Azure Verified Modules: turning architecture standards into deployable building blocks

By its fourth month, the cloud landing zone at Blyde Financial Services, the fictional South African financial-services group in this series, had a well-reviewed architecture diagram, a standards document of forty pages and a platform team of four. It also had three slightly different ways of deploying a storage account. The document-processing team had written its own Terraform. The fraud team had copied a template from a blog post. The platform team's version was correct but undocumented, so nobody else used it.

All three passed policy on the day they were deployed. Only one of them would still pass after the next guardrail release, and nobody could easily tell which.

The gap was not in the architecture. It was between the standard and the thing that gets deployed. This article is about that gap and about Azure Verified Modules, Microsoft's programme for closing part of it. The same reasoning applies on AWS and Google Cloud, and the article ends with how.

Four artefacts that are often treated as one

When people say "our landing-zone architecture" they can mean any of four different things:

A diagram shows the parts and how they connect. It is necessary and easy to get wrong, because nothing checks it. An Azure diagram is not an architecture until it explains the decisions.
A standard states what must always be true: storage is encrypted, data stores have no public endpoint, diagnostic logs go to the central workspace. It is enforceable through policy, but it does not build anything.
A module is reusable infrastructure code that builds a component in a known way, with parameters for what may vary. It is where a standard becomes something a pipeline can deploy the same way every time.
A deployed environment is what actually exists. It is the only one of the four that runs, and the only one an attacker meets.

Behind all four sits a fifth thing that none of them is: the decision about why the design is this way and not another.

Five artefacts that are often treated as one. A module is where a standard becomes something a pipeline can deploy the same way every time, but it cannot answer the first row: it encodes a decision someone already made. Blyde keeps evidence for each row separately, so a reviewer can tell whether a gap is in the thinking, the rule, the code or the estate. Fictional example.

Blyde's three storage accounts were a module problem. The standard was clear. There was simply no shared, trusted building block that encoded it, so each team encoded its own reading of the standard, and those readings drifted.

What Azure Verified Modules are

Azure Verified Modules (AVM) is, in Microsoft's words, "an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like" (AVM, checked on 7 November 2026). The facts that matter for a landing-zone team, all checked on 7 November 2026 against the AVM site and FAQ, are these:

Two main kinds of module. Resource modules deploy a single Azure resource and its extensions, such as a key vault with its private endpoint, diagnostic settings and role assignments. Pattern modules compose several resources into a reusable architectural pattern. The module indexes also list a small set of utility modules.
Two languages. Modules are published for Bicep and Terraform. Bicep modules come from the public Bicep registry under the avm/res and avm/ptn prefixes and are served from Microsoft Container Registry. Terraform modules come from the HashiCorp Terraform Registry under the Azure namespace, for example Azure/avm-res-keyvault-vault/azurerm.
Ownership and support. The AVM site says "AVM is owned by Azure engineering and supported by Microsoft", and the FAQ describes it as an officially supported open-source project. Every module must have a named owner, and the FAQ states that only Microsoft full-time employees can currently be module owners. Issues are raised on GitHub, and Microsoft support routes module issues to the module owners.
Versioning. Modules use semantic versioning. The FAQ states that modules are currently published as 0.x versions, that a module does not need to reach 1.0.0 to be used in production, and that after 1.0.0 breaking changes come with a major version increment.
Testing. Every pull request runs static validation against the AVM specifications and deployment validation of the module's test examples, and a new version is published only when both pass.
Telemetry. Modules collect usage telemetry by default, controlled by an enableTelemetry parameter in Bicep and an enable_telemetry variable in Terraform. Decide deliberately whether to leave it on.

AVM is also the base of Microsoft's own platform landing zone accelerator. Microsoft's implementation guidance recommends an infrastructure-as-code approach using the Azure Landing Zones IaC Accelerator, built on AVM for Bicep or Terraform, and notes that the modules can also be used independently (Microsoft Learn). Subscription vending has Bicep and Terraform modules too.

Provenance: know where every module came from

A verified module is a dependency, and dependencies need provenance. Open source does not mean low risk or high risk; it means you can inspect what you depend on and must decide how far to trust it.

For AVM, that means three habits:

Use the official source. The AVM Terraform quickstart warns that unofficial modules with "avm" in their names can appear in registry searches. Take modules from the published module index, not from a search result.
Allow the registry. Bicep modules are pulled from mcr.microsoft.com. In a locked-down network, the pipeline runners need that route, or a mirrored copy in an internal registry.
Record what you use. Blyde keeps a module inventory: module name, pinned version, owner on its side, which patterns use it and when it was last reviewed. Without that list, a security advisory or a deprecated module is a search exercise.

Pin versions and take upgrades on purpose

A module that floats to its latest version is a change you did not review. Pin every module to an exact version, as you would any other dependency, and treat an upgrade as a change with evidence. Pin the version before you pin your hopes on the platform makes the general case.

Blyde does not deploy registry modules directly. Its patterns compose pinned module versions with its own defaults, and every change runs through the same pipeline: static checks, a Terraform plan or Bicep what-if, and test deployments. A new module version arrives as a pull request, is read and planned in test, and is promoted only when the plan shows what the changelog said. The inventory row is what makes an upgrade or a retirement findable. Fictional example.

The AVM FAQ's own upgrade advice is sensible and short: check the release notes for incompatibilities, update the version, and run a Bicep what-if or a Terraform plan before applying. Blyde turns that into a routine:

An automated pull request proposes the new version.
An engineer reads the changelog and notes anything breaking or behaviour-changing.
The pipeline runs a plan or what-if against the test environment, and the engineer compares it with what the changelog said should change.
If the plan matches, the change is promoted to production through the normal release. If it does not, the upgrade is held and the reason recorded.

Because modules are still in the 0.x range, minor versions can contain breaking changes under semantic versioning rules. That is not a reason to avoid them. It is a reason to read the notes and look at the plan. Upgrade evidence belongs in the architecture record.

Compose patterns, do not fork modules

Blyde does not deploy registry modules directly from workload code. It builds a small number of its own patterns, each composing pinned AVM resource modules with Blyde's defaults: naming, tags, private endpoints, diagnostic settings, and the role assignments its standards require. The internal document-pipeline pattern, for example, composes a storage account, a function app, a key vault and a private endpoint module, with only the workload-specific values left as parameters.

This keeps the standard in one place. When the guardrail on public network access changed in version 2.4 of the policy set, described in part 4, the fix was one change to one pattern, tested once and released to every team that used it.

Two rules prevent this from going wrong:

Do not fork the upstream module. If a module does not do something you need, wrap it or raise an issue upstream. A fork stops receiving fixes and becomes yours to maintain.
Keep the patterns few. A pattern for every workload is just another way of having no standard. Blyde started with four, one per common workload shape.

What a module cannot do

The most important limit is easy to state and easy to forget: a module is not a substitute for an architecture decision.

A key vault module can deploy a vault with a private endpoint, purge protection and the right diagnostic settings. It cannot decide whether the fraud workload should have its own vault or share one, who may read the secrets, how keys are rotated or what happens when the vault is unavailable. A pattern module for a hub network can deploy a hub. It cannot decide whether you need one.

Teams that adopt verified modules without the decisions end up with well-built components arranged in the wrong way. Teams that have the decisions but no modules end up with the right arrangement built three different ways. You need both, and you need to know which one is missing when something goes wrong. That is what the decision row in the first diagram is for.

The same idea on AWS and Google Cloud

Azure Verified Modules is Microsoft's programme, but the problem is universal. On AWS, Landing Zone Accelerator on AWS is an open-source solution built with the AWS Cloud Development Kit that AWS recommends deploying on top of AWS Control Tower, configured through a set of configuration files (AWS, checked on 7 November 2026). AWS also states that the solution "will not, by itself, make you compliant", which is exactly the module-versus-decision point. Google Cloud's landing-zone guidance recommends infrastructure as code, points to a Terraform example foundation as an opinionated starting point and to a catalogue of Terraform blueprints as reusable modules (Google Cloud).

The habits in this article apply to all of them: use official sources, record provenance, pin versions, prove upgrades with a plan, compose a few patterns, and keep the decisions written down separately.

An adoption checklist

Question	Healthy answer at Blyde
Where do our modules come from?	The AVM module index, recorded in an inventory with versions
Are versions pinned?	Yes, exact versions, upgraded by pull request
How is an upgrade proved?	Changelog read, plan or what-if in test compared with the notes
Do workloads use registry modules directly?	No, through a small set of internal patterns
Have we forked any upstream module?	No. Gaps are wrapped or raised upstream
Can our pipelines reach the registry?	Yes, or through an internal mirror
Is telemetry a deliberate choice?	Yes, decided and recorded
Where are the decisions the patterns encode?	In decision records linked from each pattern

Key points

A diagram, a standard, a module and a deployed environment are different artefacts, and a decision sits behind all of them. Keep evidence for each.
Azure Verified Modules are Microsoft-owned, supported Bicep and Terraform modules, in resource and pattern forms, with semantic versioning and validation on every change (checked on 7 November 2026).
Treat modules as dependencies: use official sources, keep an inventory, pin exact versions and prove each upgrade with a plan in test.
Compose a few internal patterns from verified modules instead of forking them, so a standard changes in one place.
A module encodes a decision. It does not make one.

This is part 5 of Cloud Foundations, Explained End to End. Previous: Landing zones are products, not one-off projects. Next: A data landing zone is not just a data lake.

Related reading: Infrastructure as code: why you need it and how to start small for the basics, and Generated from reality: diagrams from IaC, inventories and traces for keeping the diagram honest once the code exists.

Background reading: Azure Verified Modules and its FAQ, and Platform landing zone implementation options (Microsoft Learn), checked on 7 November 2026.

How CloudNala can help

CloudNala helps platform teams move from standards documents to building blocks that teams actually use. We review how your landing zone and workloads are deployed today, identify where the same standard is encoded several different ways, design a small set of internal patterns on verified modules with an inventory and an upgrade routine, and make sure the decisions those patterns encode are written down where a reviewer can find them.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Landing Zone Review or write to us at consult@cloudnala.co.za