August 22, 2024 Marco

Azure Verified Modules (AVM)

When diving deeper into Azure Bicep, you’ll quickly reach a point where you need to deploy multiple resources as a bundle or even an entire architecture including Resource Groups. Bicep Modules enable this by allowing you to modularize components. These modules are declared just like standard resource deployments in *.bicep files.

I’ve seen some challenges with self-developed modules in the past:

  • Ensuring broad reusability (we’ve all seen files that are hard to make reusable like the number of subnets inside a Vnet or specific SKUs that require a different set of parameters)
  • Keeping up with API versions of resource providers
  • Getting started with complex deployments and multiple resources with many dependencies
  • Centralizing and versioning of modules

Azure Verified Modules help to target exactly those pain points, let’s dive in!

What are Azure Verified Modules?

As the name might suggest, Azure Verified Modules (AVM) aim at standardizing what constitutes a high-quality Infrastructure-as-Code (IaC) module. They follow a high level of automation and usually use the whole range of Bicep capabilities like user-defined data types and functions. By establishing these standards (we dive into these later in the post) across  Bicep and Terraform, AVM ensures that modules meet these criteria, follow a modern architecture, and are kept up-to-date. Every module is assigned to a module owner who ensures the module follows the guidelines and is up-to-date. As of the time of writing, module owners must be Microsoft employees.

Main benefits:

  • AVM is owned, developed & supported by Microsoft
  • You can open an official Microsoft support ticket when any issues using one of the modules occur
  • The code follows a clear and specific structure to ensure consistency
  • Modules are aimed to align with the Azure Well-Architected Framework (WAF)
  • Modules are tested, documented, and published using working examples

At the end of the day, AVMs allow you to get up to speed faster and maintain your IaC deployments more efficiently.

AVM mission statement

Our mission is to deliver a comprehensive Azure Verified Modules library in multiple IaC languages, following the principles of the well-architected framework, serving as the trusted Microsoft source of truth. Supported by Microsoft, AVM will accelerate deployment time for Azure resources and architectural patterns, empowering every person and organization on the planet on their IaC journey.

Modules

Module types

AVMs are divided into resource modules, pattern modules, and utility modules, both in Bicep and in Terraform.

Resource modules (res)

Single Azure resources including additional settings like diagnostic settings and role assignments.

Pattern modules (ptn)

Multiple resources to accelerate common tasks/architectures. Pattern modules can include other pattern modules, but should not reference non-AVM modules.

Utility modules (utl)

Reusable functions or routines via deployment scripts. The concept of Utility Modules is new and will be introduced gradually!

Consuming modules in a Bicep file

Bicep modules are available from the Microsoft public artifacts registry mcr.microsoft.com/bicep. If you use Visual Studio Code and have the Bicep extension installed, an alias  br/public: is already included. You don’t have to configure anything and can start typing, the alias will automatically be populated. The rest works the same as with self-developed modules, i.e. using parameters and additional functions.

Module documentation and authoring

When working with Bicep, I really enjoy working directly in Visual Studio Code and using the built-in Bicep linter to develop Bicep code. Every now and then you have to check the documentation though, to see how to declare certain values. The AVM project provides documentation for each module, describing the structure, different parameters, and great usage examples. When struggling, I usually take a first look at the Using large parameter set example, where you will find the declaration of almost every parameter in the module. You can also check the main.bicep file in each of the module folders to see the entire Bicep structure of the module. In the end, because Bicep modules are based on generic resource providers, you can always check the official Bicep documentation for deeper information.

You can find the documentation of the modules on GitHub: bicep-registry-modules/avm at main · Azure/bicep-registry-modules · GitHub

Lab 1: Deploy single resources using resource modules

We will create an Azure Key Vault including a role assignment for the Key Vault Secrets User role and a CanNotDelete resource lock. Normally these are different resources or can be put into individual modules or, as here, consumed in a single module. The main.bicep which consumes the module could look as simple as this.

Module used: bicep-registry-modules/avm/res/key-vault/vault at main · Azure/bicep-registry-modules (github.com)

targetScope = 'subscription'

// PARAMETERS
param location string = 'switzerlandnorth'
param resourceGroupName string = 'demo-resource-module'
param keyVaultName string = 'demo-kva'
param roleAssignments array = [
  {
    principalId: '<objectId of the user or service principal>'
    roleDefinitionIdOrName: 'Key Vault Secrets User'
  }
]

// RESOURCES
resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  location: location
  name: resourceGroupName
}

// MODULES
module kva 'br/public:avm/res/key-vault/vault:0.7.1' = {
  scope: rg
  name: keyVaultName
  params: {
    location: location
    name: keyVaultName
    roleAssignments: roleAssignments
    lock: {
      name: 'Set by code'
      kind: 'CanNotDelete'
    }
  }
}

You can manually deploy the main.bicep file using this Azure CLI command:

az deployment sub create --name resource-module --location switzerlandnorth --template-file main.bicep

Lab 2: Deploy multiple resources using pattern modules

This example of a pattern module deploys a secure and scalable AI baseline environment consisting of many interrelated resources. This is comparable to the landing zone principle, where you want to provide a secure and standardized baseline environment with minimal effort. Just that it is now automated, supported, and WAF aligned provided by Microsoft.

Module used: bicep-registry-modules/avm/ptn/ai-platform/baseline at main · Azure/bicep-registry-modules (github.com)

This module deploys a virtual machine with encryption at host by default. The encryption at host feature needs to be enabled on the subscription using Azure CLI or PowerShell, otherwise, the deployment will fail. While I recommend to enable encryption at host if possible, this is a great chance to override a default parameter, as you would with other parameters when using the module. Note line 23, where we simply override the parameter.

targetScope = 'subscription'

// PARAMETERS
param location string = 'switzerlandnorth'
param resourceGroupName string = 'demo-pattern-module'
param envNameShort string = 'demoptn'

// RESOURCES
resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  location: location
  name: resourceGroupName
}

// MODULES
module aiPlatformBaseline 'br/public:avm/ptn/ai-platform/baseline:0.3.0' = {
  scope: rg
  name: envNameShort
  params: {
    name: envNameShort
    virtualMachineConfiguration: {
      adminUsername: '<adminUsername>'
      adminPassword: '<adminPassword>'
      encryptionAtHost: false
    }
  }
}

Again, you can manually deploy the main.bicep file using this Azure CLI command:

az deployment sub create --name pattern-module --location switzerlandnorth --template-file main.bicep

Make sure to delete the resource group when you are finished to prevent cost.

The example code can also be found in my GitHub repository.

Key takeaways

  • The modules offer a good level of automation, i.e. integration for role assignments
  • You don’t have to maintain your own modules and container registry hosting the modules
  • Modules are versioned which enables controlled maintenance
  • Modules align with best practices and
  • Modules are covered by official Microsoft support
  • Modules are tested, documented, and published with good examples on how to use them

Conclusion

Azure Verified Modules are a great initiative targeting engineers and architects as well. It enables many organizations to bring their code into a more aligned and mature base, reducing development effort to maintain each module. At most, I highly recommend looking at AVM and checking whether it brings added value to your deployment processes. If you have any questions just let us know.

Resources

Hear the world using Azure OpenAI and a Raspberry Pi

This project shows the build of a device that is designed to help visually impaired individuals using a Raspberry Pi and Azure AI services.

, , ,
Marco Gerber

Marco

Senior Cloud Engineer, keen on Azure and cloud technologies.

Leave a Reply

Your email address will not be published. Required fields are marked *