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.