Azure Infrastructure as Code (IAC) Guide: 10 Best Practices

IaC lets you define Azure infrastructure (like virtual machines, networks, and storage) in templates. However, it’s not limited to infrastructure (IaaS) parts; we can automate basically every other aspect of Azure resources.

Think about PaaS services and serverless resources such as Azure Functions, Azure Logic Apps, or even access control policies, databases and database objects – you name it.

Benefits of Infrastructure as Code (IaC)

IaC is a practice where you manage and provision computing infrastructure using machine-readable definition files, instead of configuring physical hardware or using interactive tools.

All in all, it offers several benefits for managing infrastructure:

• Consistency: It ensures that infrastructure deployments are consistent. 
• Version Control: Tools like Bicep and Terraform enable version-controlled infrastructure, offering reliability with each deployment. It allows you to track changes, roll back versions, and collaborate effectively while maintaining a history of infrastructure states.
• Faster deployments: By automating infrastructure deployment, recovery time is minimised, allowing businesses to respond to disruptions promptly.
• Reusability: Whether for testing, development, or production, IaC promises consistency and efficiency across environments.
• Scalability: It allows organisations to scale their infrastructure quickly and reliably. With predefined templates, scaling operations can be executed seamlessly and consistently.
• Automation: IaC handles the entire infrastructure lifecycle, from provisioning to teardown – automatically. It reduces manual mistakes, accelerates deployment, and boosts overall efficiency.

Infrastructure as Code and its role in Disaster Recovery (DR)

What happens if you've run out of backups or your backups don't work? If you've got to rebuild loads of servers and deploy all the software, that's gonna take ages…

But using Infrastructure as Code you can rebuild environments quickly. This is crucial for ensuring business continuity.

How Does Azure IaC work?

Let’s answer this question by looking at how a typical workflow might occur while building Infrastructure as Code in Microsoft Azure:

1. Firstly, a developer or operator writes the infrastructure definition in code – using tools like Azure Bicep, ARM templates, Terraform (or another tool of choice).
2. They commit it to a source-code repository - Git.
3. The third step is to review the change and validate the code to check whether it isn’t malicious and does what it’s intended.
4. Once approved, the change is merged and sent through a CI/CD pipeline.
5. The pipeline typically includes a build phase (tests, checks, etc) and a release phase.
6. The release phase actually creates the resources in Azure.

Let’s zoom in on it more, starting with the build phase.

Build phase

• In the build pipeline stage, developers write code and tests, which are then packaged into a deployable artefact that can be deployed across multiple environments.
• The pipeline runs syntax checks and scans for secrets, credentials or misconfigurations and vulnerabilities.

If any issues are found, the pipeline can fail early. This way, unsafe assets are prevented from reaching the next phase: release. 

Release phase

In the release phase, the pipeline authenticates to Azure using a service principal or managed identity. It retrieves secrets (e.g. passwords, cryptographic keys, certificates, connection strings) from Azure Key Vault. Instead of embedding secrets in files, you store them there. 

Most IaC tools integrate well with Key Vault, allowing the pipeline to retrieve these secrets at runtime without enabling developers direct access to the secrets. This reduces the risk of secrets being misused or accidentally exposed.

Next, the IaC tool runs deployment commands and applies the configuration to the target Azure environment. Azure compares the desired state defined in the IaC code with the current state of your infrastructure.

If there’s a mismatch, the IaC tool takes action – creating missing resources, updating existing ones, or removing anything no longer needed. 
This ensures that your environment remains consistent with what is declared in the code.

Azure IaC Tools 

There are many tools for Infrastructure as Code. Which you use depends on your company’s use case (your needs, environment, resources, etc.) 

Azure Bicep 

Azure Bicep is Microsoft’s native IaC language. It’s actively developed, fully supported, and integrates well with Azure tooling.

param location string = ‘East US’
param storageAccountName string = ‘mystorageaccount’
resource storageAccount ‘Microsoft.Storage/storageAccounts@2022-09-01’ =
{
name: storageAccountName
location: location kind: ‘StorageV2’
sku: { name: ‘Standard_LRS’ } }

If you work with Azure, Bicep is a great choice. It's a domain-specific language (DSL) built to simplify ARM templates. It is declarative, meaning you define the desired state, and Azure handles the rest. Bicep is easier to read and write than raw JSON-based ARM templates (mentioned below also). It integrates seamlessly with Azure and keeps you close to Microsoft’s ecosystem.

 

Azure Resource Manager (ARM) Templates

Azure Resource Manager (ARM) templates are JSON-based and used to define Azure resources declaratively. They provide deep integration with Azure but can be complex to write and maintain manually. Bicep was introduced as an abstraction over ARM templates to simplify the experience. 

 {
“$schema”: “https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“resources”: [
{
“type”: “Microsoft.Storage/storageAccounts”,
“apiVersion”: “2022-09-01”,
“name”: “mystorageaccount”,
“location”: “East US”,
“sku”: {
“name”: “Standard_LRS”
},
“kind”: “StorageV2”
}
]
}

 

Terraform 

 

 

Terraform is cloud-agnostic. It allows you to define infrastructure across multiple providers, not just Azure. It’s also declarative, like Bicep, but has a broader reach. Terraform uses HashiCorp Configuration Language (HCL), which is easy to learn.  

If you work in multi-cloud environments or plan to in the future, Terraform is a strong option, but might need a licence when specific features are needed. OpenTofu is then also interesting to look at, which is created as an alternative. OpenTofu is governed by the Linux Foundation and remains fully open source. 

The example below deploys a storage account through Terraform. 

provider “azurerm” {
features {}
}
resource “azurerm_storage_account” “storage” {
name = “mystorageaccount”
resource_group_name = “myResourceGroup”
location = “East US”
account_tier = “Standard”
account_replication_type = “LRS”
}

 

Pulumi

Unlike Bicep and Terraform, Pulumi allows you to write infrastructure in general-purpose programming languages like Python, TypeScript, and C#. This makes it appealing to developers who prefer imperative coding. 

Pulumi provides flexibility but requires more programming knowledge.

The example below deploys a storage account trough Pulumi (TypeScript).

import * as azure from “@pulumi/azure”;
const storageAccount = new azure.storage.Account(“storage”, {
name: “mystorageaccount”,
resourceGroupName: “myResourceGroup”,
location: “East US”,
accountTier: “Standard”,
accountReplicationType: “LRS”,
});

How do I Choose the right IaC tool?

There are numerous tools that can be used, but before that, ask yourself and your team: 

• Do you have any existing experience with a specific IaC tool?
• What programming skills does the team already have? (C#, Go, JSON, TypeScript—or none?)
• Which cloud provider are you using? In other words: where do you deploy resources?
• What is your deployment mechanism?
• What are the needs of your organisation? Do you have some compliance requirements?
• Do you need an imperative or declarative approach?
• Who will manage the IaC templates, and where will they live?
• Are you managing configuration too, or just provisioning infrastructure?
• Are there any changes happening outside the templates?

Check supported languages in your environment 

Before selecting an IaC language, it is important to verify what your environment supports. 

Here is how to go about it: 

• Check official documentation: Cloud providers regularly update their documentation to list supported IaC tools. For example, Azure officially supports Bicep, Terraform, Pulumi, and Azure Resource Manager (ARM) templates. 
• Review policy and compliance requirements: Some organisations mandate the use of specific IaC languages for security and governance purposes. 
• Examine existing infrastructure: If your team already uses Terraform or ARM templates, it is recommended to align with that choice for consistency. 
• Experiment in a test environment: Set up a simple deployment with different IaC languages to see which one aligns best with your workflow.

Choose the right language 

The choice of an IaC language depends on the cloud provider, work environment, and personal preferences. Choosing the right language is the first challenge, as it shapes how you work and determines the scalability of your solutions. 

Before selecting a language, it is important to: Verify which options your environment supports. Once you know what’s available, you can proceed confidently.

Decide on the best fit based on your cloud provider, organisational needs, and personal preference. Research how to get started and ensure a smooth transition to writing IaC.

10 Azure IaC Best Practices

Starting may seem overwhelming, but breaking it down into manageable steps will make it easier. Here are a few tips to help you get started successfully:

1. Set up your development environment

• Install the necessary tools and CLI for your chosen IaC language. 
• Ensure you have access to an Azure subscription. 
• Use a development environment like Visual Studio Code, which provides extensive support for IaC languages. Install extensions such as the Bicep Extension for VS Code, Terraform Extension by HashiCorp, or Pulumi Extension to improve syntax highlighting, autocompletion, and deployment capabilities. 
• Use the PowerShell Extension terminal in VS Code to run your scripts and deploy infrastructure directly.

2. Learn from official resources

Microsoft provides excellent learning resources for Bicep. You can complete step-by-step learning modules on Microsoft Learn. Terraform and Pulumi also offer extensive documentation and hands-on labs.

3. Start with simple deployment

• Start with small resources, such as deploying a storage account (as shown in the examples). 
• Test your scripts in a sandbox environment before deploying them to production. 
• Follow best practices, such as using parameters and modular structures. Also, explore Azure Verified Modules, which support both Bicep and Terraform here.

4. Use version control system

Store your Infrastructure as Code files in GitHub, Azure DevOps, or another version-controlled repository to maintain detailed change histories and support rollback capabilities. This way, you have a 4 eyes principle in place before it gets pushed to production. Consequently, mistakes will be mitigated. 

5. Test and Validate

Regular testing of IaC scripts is paramount. Ensuring scripts perform as expected before deploying them to production environments can prevent potential issues that could impact business operations

6. Avoid configuration drift

Avoiding drift is key to reliable infrastructure. By removing direct human access and routing all changes through your CI/CD pipeline, you ensure that Infrastructure as Code remains the single source of truth. You'll get consistent environments if you run the same assets through dev, test, and production.

Learn more on how to prevent infrastructure drift with Azure IAC.

7. Automate

Automation eliminates manual steps, reduces errors, and enables the consistent reproduction of environments. 

Implement Continuous Integration (CI) and Continuous Deployment/ Delivery (CD) (CI/CD) pipelines (e.g., Azure Devops, GitHub Actions) to automate deployments of IAC across all environments (development, test, staging, and production). 

8. Parameterise your IaC templates

Define all environments using the same IaC template, and vary only the input parameters (e.g. scale, region, resource SKUs). This keeps your infrastructure consistent across environments and avoids configuration drift. It also ensures that tests in lower environments are valid and representative of production.

9. Limit access to the production environment

Having people changing things manually in the production phase may cause your Infrastructure as Code to break. This applies particularly to imperative scripts that expect environments to match a defined state. To maintain control and consistency, restrict write access to production environments. 

That being said, there may be some exceptional situations where an urgent change is required – which is too urgent to handle through the usual IaC process or CI/CD pipeline.

To cope with that, you can use one of these two controlled access methods:

• Use Priviliged Identity Management (PIM): PIM provides just-in-time access with time limits and optional approval. Access is temporary, logged, and auditable.
• Leverage Break glass accounts: A highly privileged account used only in emergencies. Credentials are stored securely and accessed under strict conditions.

10. Manage and Store Secrets in the right place

Never store your hard-coded secrets in your IaC code files. Instead, the best practice is to store and manage secrets in Azure Key Vault; a secure and centralised place.

Closing thoughts

Infrastructure as Code allows organisations to better manage their cloud resources precisely and effectively. By automating infrastructure deployments and managing them through code, businesses enhance their operational efficiency and prepare accordingly for disaster recovery.