Introduction

Azure Bicep simplifies infrastructure as code (IaC) for Microsoft Azure, offering a cleaner syntax and improved tooling compared to ARM templates. Two core constructs of Bicep—variables and parameters—serve different purposes, and understanding their distinctions is key to writing efficient, maintainable templates. In this post, we’ll dive into the differences between variables and parameters, explore their use cases, and provide examples to illustrate when to use each.

Understanding Parameters

Parameters are used to allow external input to your Bicep templates. They make your templates reusable by enabling you to pass in different values for different deployments.

Key Characteristics of Parameters

• Defined by the user at deployment time.
• Used to make your templates flexible and adaptable.
• Ideal for values that differ across environments (e.g., development, testing, production).
• Support default values and validation rules (e.g., allowed values, minimum/maximum length).

Example: Using Parameters

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@description('The name of the storage account.')
@minLength(3)
@maxLength(24)
param storageAccountName string

@description('The location of the resource.')
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

When to Use Parameters

• For user-defined values such as environment-specific configurations (e.g., resource names, locations).
• When input values must be validated (e.g., using constraints like @allowed or @maxLength).
• To support CI/CD pipelines where deployment parameters change dynamically.

Understanding Variables

Variables are used to store computed or intermediate values within your Bicep templates. They are evaluated at runtime and help make your templates more readable by avoiding repetition.

Key Characteristics of Variables

• Defined within the template and cannot be changed at deployment time.
• Used for computed values or simplifying complex expressions.
• Scope is limited to the Bicep file where they are defined.

Example: Using Variables

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@description('The name prefix for the storage account.')
param namePrefix string

@description('The location of the resource.')
param location string = resourceGroup().location

var storageAccountName = '${namePrefix}${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

When to Use Variables

• For computed values that depend on other inputs or resource properties.
• To simplify complex expressions and improve readability.
• When a value is reused multiple times within the template.

Comparing Parameters and Variables

Combining Parameters and Variables

Often, you’ll use parameters and variables together to build flexible and maintainable templates. Here’s an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

@description('The environment name (e.g., dev, test, prod).')
@allowed(['dev', 'test', 'prod'])
param environment string

@description('The location of the resources.')
param location string = resourceGroup().location

var storageAccountName = 'sa${environment}${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

In this example:

• The environment parameter allows users to specify the deployment environment.
• The storageAccountName variable computes a unique name for the storage account using the environment parameter.

Best Practices

• Use Parameters for External Input:
  Define anything that may change between deployments as a parameter.

• Use Variables for Computation:
  Simplify your templates by moving calculated values to variables.

• Add Metadata:
  Use annotations like @description, @allowed, and @minLength to make your parameters self-documenting.

• Keep Parameters and Variables Separate:
  Avoid hardcoding values in variables that should be user-defined parameters.

• Test Across Environments:
  Ensure that your parameters and variables work well for all targeted environments.

Wrap Up

Understanding when to use variables versus parameters is essential for writing effective Bicep templates. Parameters make your templates reusable and environment-agnostic, while variables help simplify and streamline your logic. By leveraging both constructs appropriately, you can create clean, efficient, and flexible infrastructure-as-code templates for Azure.

Ready to take your Bicep skills further? Try combining these concepts in your next project and see how they enhance your workflow!