Bicep Modules: Enterprise Infrastructure Scale

Copy-pasting Bicep code defeats the purpose of Infrastructure as Code. **Modules** allow you to strictly define inputs and outputs for reusable components (like a standardized VNET or Storage Account), enforcing compliance across the enterprise.

Creating a Module

// storage.bicep
param location string = resourceGroup().location
param namePrefix string

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: '${namePrefix}${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

output storageId string = stg.id

Consuming the Module

// main.bicep
module myStorage './storage.bicep' = {
  name: 'storageDeploy'
  params: {
    namePrefix: 'app'
  }
}

output id string = myStorage.outputs.storageId

Key Takeaways

  • Publish modules to a **Private Bicep Registry** (ACR) for cross-team sharing.
  • Use `br:myregistry.azurecr.io/bicep/storage:v1` syntax to consume remote modules.

Discover more from C4: Container, Code, Cloud & Context

Subscribe to get the latest posts sent to your email.

Leave a comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.