# Azure Verified Modules is a standard, not a library you install > Azure Verified Modules is a Microsoft initiative to define one shared definition of what a good infrastructure-as-code module looks like, with modules aligned across Bicep and Terraform and published from the registries for each language, while this repository holds the proposals, the issue tracking and the documentation site. **Azure/Azure-Verified-Modules** — Azure Verified Modules (AVM) is an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like. Modules will then align to these standards, across languages (Bicep, Terraform etc.) and will then be classified as AVMs and available from their respective language specific registries. - Repository: https://github.com/Azure/Azure-Verified-Modules - Website: https://aka.ms/AVM - Stars: 586 · Forks: 164 - Language: PowerShell - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/azure-azure-verified-modules ## This repository holds the standard, not the modules The first thing the README says is that the documentation is published over at aka.ms/AVM, and then it explains what this repository is actually for: it is used for proposing and tracking the state of modules, tracking issues and feature requests, and hosting documentation for the Azure Verified Modules project. If you are looking for the AVM code repositories, the README points you to the Bicep and Terraform module indexes on the AVM portal. That distinction is the whole thing to understand before evaluating the project. Azure Verified Modules is an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like. Modules then align to these standards, across languages such as Bicep and Terraform, and are classified as AVMs and made available from their respective language specific registries. So the artefact you consume is a module in a Bicep or Terraform registry, and the artefact in this repository is the definition of what qualifies, the process for getting there, and the tracker for where each module stands in that process. For a team choosing modules, that means the evaluation happens in two places. The AVM portal and the per-language indexes tell you what exists, and the standards and the issue tracker tell you how far along each one is. The primary language of this repository is recorded as PowerShell, which is consistent with a repository whose code is a large set of policy and template files rather than a library with a public API. ## The four questions the standard answers The README frames the work as providing a single definition of what a good IaC module is, and it lists four aspects of that definition. How the modules should be constructed and built, with consistency enforced and testing applied where possible. How they are to be consumed, which is the question that decides whether a module can be dropped into a deployment pipeline without surprises. What they deliver for consumers in terms of resources deployed and configured, which is a contract about behaviour rather than about shape. And, where appropriate, alignment across Infrastructure-as-Code languages such as Bicep and Terraform. Each of those four is a place where module libraries commonly diverge, and the fact that the standard names them is a useful signal about what the project considers a problem. The emphasis on enforcing consistency and on testing where possible is notable, because it says the standard is about a repeatable quality bar rather than a template library. The delivery question is the one that matters most to a consumer, since a module that creates the right resources with the wrong names, tags or defaults is worse than no module at all. The language alignment point is the ambitious one, and it is the reason the initiative is worth an article. Two implementations of the same Azure pattern, one in Bicep and one in Terraform, that agree on naming, on outputs and on what they create, remove an entire category of divergence between teams that pick different IaC languages. ## A library in several languages, from one source of truth The mission statement is written in the language of a programme rather than a library. The aim is to deliver a comprehensive Azure Verified Modules library in multiple Infrastructure-as-Code languages, following the principles of the well-architected framework, serving as the trusted Microsoft source of truth. Supported by Microsoft, the stated goal is to accelerate deployment time for Azure resources and architectural patterns. Three phrases in that carry the weight. Well-architected framework principles means the modules are meant to embody Azure's own architectural guidance rather than a set of convenience wrappers, which is a much higher bar. A trusted Microsoft source of truth means the modules are a reference point rather than one vendor's opinion, which is what makes them usable as an internal standard rather than merely as code to import. And a library in multiple languages is the promise that a team can move between Bicep and Terraform without rewriting its patterns. The practical value for a consumer is a shorter path from a requirement to a working deployment, with the patterns already reviewed against the framework. The cost is a dependency on a Microsoft-maintained module rather than on your own code, which is a trade a lot of Azure teams are happy to make and some are not. The contributor route is documented at aka.ms/AVM/Contribute, and the repository carries the usual community files, a code of conduct, a security policy and a support policy, which is a sign of a programme with external contributors rather than a single team's scripts. ## Where to find the modules and how the docs are built The navigation is short and worth repeating. The AVM portal is at aka.ms/AVM and is the place the README points you to for guidance, and the contributing guide is at aka.ms/AVM/Contribute. The Bicep and Terraform module indexes live on the AVM portal, at azure.github.io/Azure-Verified-Modules/indexes, and those are the references for the actual code. The documentation in this repository is built with Hugo. The Makefile has a single target: ```make .PHONY: server server: @echo "Starting Hugo docs server..." cd docs && hugo server && cd .. ``` So a contributor runs the server target, the Hugo site in the docs directory is served locally, and the content lives in that directory, with static assets under docs/static/images, which is where the AVM logo referenced in the README comes from. There is a .devcontainer directory and a .vscode directory, so the intended development loop is a container with the editor configuration already in place, and a utilities directory for helper scripts. The one thing the repository is not is a build artefact. There are no releases, and the last push was on 2026-10-19, so the history here is a record of proposals and documentation changes rather than a versioned library. ## Licence, trademarks and the telemetry paragraph The licence is MIT, with the LICENSE file at the root, which is the permissive choice you would expect for a cross-language module ecosystem whose individual modules live in their own repositories under their own terms. The trademark section is the part to read if you plan to publish modules of your own under the AVM banner. The project may contain trademarks or logos for projects, products or services, authorised use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark and Brand Guidelines, use of Microsoft trademarks or logos in modified versions must not cause confusion or imply Microsoft sponsorship, and any use of third-party trademarks or logos is subject to those third parties' policies. There is also a data collection statement. The software may collect information about you and your use of the software and send it to Microsoft, which may use it to provide services and improve the products, and telemetry can be turned off as described in the repository. The statement also covers features that may enable Microsoft to collect data from users of your applications, with a requirement to comply with applicable law, including providing appropriate notices together with a copy of Microsoft's privacy statement. Use of the software is described as operating as consent to these practices. That paragraph is boilerplate in most Microsoft repositories, and it is worth reading anyway if your organisation has a policy on telemetry in developer tooling, because the consent language here is explicit. ## How to judge a module against the standard The value of a published standard is that it gives a consumer something to check a module against, and the AVM material gives four separate angles on that. The first is whether the module is classified as an AVM at all, which is a state tracked in this repository rather than a fact you can read off the module itself. The second is the issue tracker, which the README says collects known topics the project is working on, so a module with open issues is a module with a known gap. The third is the per-language index, which tells you what actually exists for Bicep and for Terraform, and therefore whether a pattern you need is available in the language your team uses or only in the other one. The fourth is the harder one, and it is the delivery question. A module that deploys the right resources with the wrong naming, the wrong tags, the wrong default region or the wrong diagnostic settings is technically compliant and practically wrong, and that is the failure mode a standard that states what a module delivers is designed to catch. For a team writing its own modules, the same four angles work as a self-assessment, and the contributing guide is the place to start. A team that has already built a mature internal module library has something else to consider, which is whether aligning it to the AVM standard is worth the churn when its modules already work, and the answer usually depends on how much you expect to share or reuse them across teams. ## Conclusion Azure Verified Modules fits an Azure team that deploys infrastructure as code and wants its modules to follow a Microsoft maintained definition of quality, with the same patterns available in Bicep and Terraform and a published set of practices to test against. It is the wrong thing to look for if you are hunting for a single package to add, since the code lives in the language-specific repositories rather than here, and it is the wrong thing for a team that has already standardised on its own module conventions. Before adopting a module from it, read the module's own documentation and the index entry for your language, check that the resources and patterns it assumes match your landing zone, and confirm with the published practices list whether it currently meets the standard it claims. ## FAQ ### What is the Azure Verified Modules repository for? It is used for proposing and tracking the state of modules, tracking issues and feature requests, and hosting documentation for the AVM project. The AVM code itself lives in the Bicep and Terraform repositories, whose module indexes are linked from the AVM portal. ### What does the AVM standard define? A single definition of what a good infrastructure-as-code module is: how modules should be constructed and built with consistency and testing enforced where possible, how they are to be consumed, what they deliver in terms of resources deployed and configured, and where appropriate alignment across IaC languages such as Bicep and Terraform. ### Where do I find the AVM modules and the contribution guide? The main documentation is published at aka.ms/AVM, the Bicep and Terraform module indexes are on the AVM portal at azure.github.io/Azure-Verified-Modules/indexes, and the contributing guide is at aka.ms/AVM/Contribute. ### How is the Azure Verified Modules documentation site built? With Hugo, from the docs directory. The Makefile provides a single server target that echoes a message, then runs hugo server inside the docs directory. ### What licence and trademark rules apply to AVM? The repository is MIT licensed. Microsoft trademarks and logos may only be used as set out in Microsoft's Trademark and Brand Guidelines, and using them in modified versions must not cause confusion or imply Microsoft sponsorship, with third-party marks governed by their own owners. ## Sources - [Azure/Azure-Verified-Modules on GitHub](https://github.com/Azure/Azure-Verified-Modules) - [Issues](https://github.com/Azure/Azure-Verified-Modules/issues) - [License: MIT](https://github.com/Azure/Azure-Verified-Modules/blob/main/LICENSE) - [Project website](https://aka.ms/AVM) - [README](https://github.com/Azure/Azure-Verified-Modules/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-azure-verified-modules