Bicep Modules and Loops

Modules and loops are essential features for building maintainable, DRY (Don't Repeat Yourself) Bicep templates. Modules break large templates into reusable components, while loops create multiple resources from a single definition.

---

Bicep Modules

A module is a Bicep file that is consumed by another Bicep file. Modules enable:

• Reusability — define a resource pattern once, use it across projects
• Encapsulation — hide implementation details behind a clean interface
• Separation of concerns — break complex deployments into manageable pieces
• Testing — validate modules independently

Creating a Module

A module is simply a regular Bicep file. For example, a storage account module:

modules/storage.bicep

@description('Name of the storage account')
param storageAccountName string

@description('Azure region')
param location string = resourceGroup().location

@description('Storage SKU')
@allowed(['Standard_LRS', 'Standard_GRS', 'Standard_ZRS'])
param skuName string = 'Standard_LRS'

@description('Tags to apply')
param tags object = {}

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: skuName
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
    allowBlobPublicAccess: false
  }
  tags: tags
}

output storageAccountId string = storageAccount.id
output primaryBlobEndpoint string = storageAccount.properties.primaryEndpoints.blob
output name string = storageAccount.name

Consuming a Module

main.bicep

param environment string = 'dev'
param location string = resourceGroup().location

var commonTags = {
  environment: environment
  managedBy: 'bicep'
}

module appStorage 'modules/storage.bicep' = {
  name: 'appStorageDeployment'
  params: {
    storageAccountName: 'stapp${environment}${uniqueString(resourceGroup().id)}'
    location: location
    skuName: environment == 'prod' ? 'Standard_GRS' : 'Standard_LRS'
    tags: commonTags
  }
}

module logsStorage 'modules/storage.bicep' = {
  name: 'logsStorageDeployment'
  params: {
    storageAccountName: 'stlogs${environment}${uniqueString(resourceGroup().id)}'
    location: location
    tags: commonTags
  }
}

output appStorageEndpoint string = appStorage.outputs.primaryBlobEndpoint
output logsStorageEndpoint string = logsStorage.outputs.primaryBlobEndpoint

The same storage.bicep module is used twice with different parameters.

---

Module Scoping

Modules can deploy resources to different scopes:

Deploy to a Different Resource Group

module networkModule 'modules/network.bicep' = {
  name: 'networkDeployment'
  scope: resourceGroup('rg-networking')
  params: {
    vnetName: 'vnet-shared'
    location: location
  }
}

Deploy to a Subscription

targetScope = 'subscription'

module rgModule 'modules/resourceGroup.bicep' = {
  name: 'rgDeployment'
  scope: subscription()
  params: {
    rgName: 'rg-webapp-prod'
    location: 'uksouth'
  }
}

---

Bicep Registry

You can publish modules to an Azure Container Registry (ACR) and consume them by reference:

Publish a Module

az bicep publish \
  --file modules/storage.bicep \
  --target br:myregistry.azurecr.io/bicep/modules/storage:v1.0

Consume from Registry

module appStorage 'br:myregistry.azurecr.io/bicep/modules/storage:v1.0' = {
  name: 'appStorageDeployment'
  params: {
    storageAccountName: 'stapp${uniqueString(resourceGroup().id)}'
    location: location
  }
}

Public Module Registry