WTH Are Azure Verified Modules?
Towards the end of 2023, Microsoft announced a new initiative around infrastructure as code for Azure called Azure Verified Modules. (AVM). This is an exciting idea, so let’s explore it more.
What Are Azure Verified Modules?
Azure Verified Modules is a new initiative focused on infrastructure as code modules for deploying Azure resources. It’s the successor to the CARML project (which it will replace) and aims to provide a few things:
- A set of standards for what good Infrastructure as Code modules look like
- A module repository for modules that implement these standards, currently for Bicep and Terraform
- A mechanism for people (currently MS employees) to be listed as owners and maintainers of these verified modules so that someone is responsible for them
- A means for people (both MS and Non-MS) to contribute to these modules
The aim of this project is two-fold:
- To provide those who want to consume IaC modules with a verified library of modules that follow good practices and are owned and maintained by Microsoft.
- To provide those who want to contribute to existing modules or create their own with a set of standards that they can follow to ensure their modules follow best practices and comply with a standard.
How Do Azure Verified Modules Work?
Let’s look at the two sides of this project: standards and modules.
Standards
The AVM team have created a library of standards and specifications that define what good modules look like. These include:
- A definition of two types of modules that will be supported: resource modules and pattern modules
- Resource modules deploy a specific Azure resource or a set of closely related resources (such as a VM and disks); they do one thing
- Pattern modules deploy a set of Azure resources intended to solve a specific problem, such as a virtual WAN or Azure Landing Zone
- A lifecycle for how modules are owned and managed
- Module specifications, for how you write modules, these are split into:
- Shared specifications that apply to all modules, whether they are written in Bicep or Terraform
- Bicep specific specifications
- Terraform specific specifications
If you want to contribute to any AVD modules, you must comply with these. But these are also a good set of standards for general use. If you are building your own modules for your company or the community, these are a good set of standards to abide by.
Modules
As well as being a set of standards, AVM is a set of verified modules you can use in your infrastructure as code. As mentioned, these fall into two categories: resource modules and pattern modules.
You can find details of all the modules in the AVM catalogue in the respective languages pages:
Whilst you can find details of all of these modules on the AVM site, the modules themselves are not hosted here but instead use:
- For Bicep, this is the Bicep Public Module Registry
- For Terraform this is the HashiCorp Terraform Registry
You can find the modules, get the details from the AVM site, and then reference them in your code from the appropriate registry.
Contributing
If you want to contribute to AVM, there are a few ways you can do that:
- Raise issues for existing modules where you have found problems or improvements
- Contribute code to existing modules through Pull Requests
- Suggest new modules
As mentioned, creating new modules is currently limited to Microsoft employees.
Why Would I Want to Use Azure Verified Modules?
If you are deploying infrastructure to Azure, it’s common to wonder if someone has already done this before you in a way you can re-use, especially when deploying complex infrastructure. AVM provides a repository of modules that can help you achieve this but also ensures that these modules meet a standard. If you’ve ever looked at the modules in public repos like the Terraform registry, you will know that the standards and quality of the module can vary dramatically. It’s not uncommon to find modules that deploy infrastructure incorrectly or with bad configurations. Using the modules from AVM ensures that they meet the required standard and have been tested against this. This then removes the need for you to dig deep into the modules to see if they are going to work or if they are going to leave security vulnerabilities in your infrastructure.
The pattern modules are also a great concept for where you want to deploy more complex sets of infrastructure, including things like the Azure Architecture Centre reference architectures.
If you’re a module builder looking for a good set of standards for building your own modules, you can’t go too wrong with using the AVM standards as a starting point. The specifications that have been developed are comprehensive and provide a lot of detail on how they should be implemented. Below is an example of one of the more straightforward standards around module versioning.
What Issues Do Azure Verified Modules Have?
The biggest issue with AVM is that it is relatively new, so the catalogue of modules is small, but it is growing. As the work to migrate from CARML to AVM is completed, the module list will start to be built out, at least in the resource modules section. Sadly, the pattern module section is even smaller, with no Bicep modules and 4-5 Terraform ones. Hopefully, this will grow over time.
The other gripe I have with this solution is limiting the submission of new modules to Microsoft employees. I get why they have done this; they want to ensure every module has an owner committed to maintaining it, and organisation pressure can be applied if they are not, but it does mean that the growth of the libraries will be limited. It would be great to see them expand this further to allow community members to submit and own modules. This would see more rapid progress in fleshing out the libraries.
Finally, I hope that Microsoft settles on AVM and keeps it running for a long time, improving as they go, rather than starting another fresh initiative in a few years, like has happened with CARML and its replacement with AVM.
