Automating Infrastructure Deployment with Azure Bicep in 2026

Infrastructure as Code (IaC) has become an essential practice for managing and deploying cloud resources efficiently. Azure Bicep, a domain-specific language (DSL) for deploying Azure resources, simplifies the process of writing IaC templates. In this tutorial, we'll explore how to automate infrastructure deployment using Azure Bicep.

What You'll Build

By the end of this tutorial, you'll have a fully automated deployment setup for a basic Azure infrastructure. This setup will include:

• A Virtual Network (VNet)
• A Network Security Group (NSG)
• A Virtual Machine (VM)

Here's a sneak peek of the final architecture:

+-------------------+
|  Virtual Network  |
|   (myVNet)        |
+---------+---------+
          |
+---------v---------+
| Network Security  |
| Group (myNSG)     |
+---------+---------+
          |
+---------v---------+
| Virtual Machine   |
| (myVM)            |
+-------------------+

Why This Matters

Automating infrastructure deployment is crucial for several reasons:

• Consistency: Manual deployments are prone to human error. IaC ensures that your infrastructure is deployed consistently every time.
• Speed: Deploying infrastructure manually can be time-consuming. Automation speeds up the process significantly.
• Scalability: As your application grows, automated deployments make it easier to scale your infrastructure.
• Version Control: With IaC, you can version your infrastructure alongside your application code, making it easier to track changes over time.

This tutorial is beneficial for developers, DevOps engineers, and IT professionals who need to manage Azure resources efficiently.

Architecture Overview

The architecture we'll build is a simple setup comprising a Virtual Network (VNet), a Network Security Group (NSG), and a Virtual Machine (VM). The VNet acts as a logical isolation boundary for your Azure resources. The NSG controls inbound and outbound traffic to the VM, ensuring security. The VM will be a basic instance running a standard operating system.

Step-by-Step Implementation

Let's dive into the implementation. We'll go through the process step-by-step, building each component of the architecture.

Step 1: Setting Up Your Environment

Before we start writing Bicep files, ensure that you have the following prerequisites:

1. Azure CLI: You should have the Azure CLI installed. If not, you can download it from here.

2. Bicep CLI: Install the Bicep CLI to compile Bicep files. You can install it using the Azure CLI:

   az bicep install
   

3. Azure Subscription: Ensure you have access to an Azure subscription.

Step 2: Create a Virtual Network (VNet)

First, we'll create a Bicep file to define a Virtual Network. Create a new file named main.bicep and add the following code:

resource myVNet 'Microsoft.Network/virtualNetworks@2022-09-01' = {
  name: 'myVNet'
  location: 'eastus'
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
    ]
  }
}

This code defines a Virtual Network named myVNet with a single subnet. The address space is set to 10.0.0.0/16, and the subnet address prefix is 10.0.0.0/24.

To deploy this VNet, use the following Azure CLI command:

az deployment group create --resource-group <your-resource-group> --template-file main.bicep

Replace <your-resource-group> with the name of your Azure resource group.

Step 3: Add a Network Security Group (NSG)

Next, we'll add a Network Security Group to our setup. Update the main.bicep file to include the NSG definition:

resource myNSG 'Microsoft.Network/networkSecurityGroups@2022-09-01' = {
  name: 'myNSG'
  location: 'eastus'
  properties: {
    securityRules: [
      {
        name: 'AllowSSH'
        properties: {
          priority: 1000
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourcePortRange: '*'
          destinationPortRange: '22'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

This code creates a Network Security Group named myNSG with a rule to allow inbound SSH traffic on port 22. This is crucial for accessing the VM later.

Deploy the updated Bicep file with:

az deployment group create --resource-group <your-resource-group> --template-file main.bicep

Step 4: Deploy a Virtual Machine (VM)

Now, let's add a Virtual Machine to our infrastructure. For simplicity, we'll deploy a basic Linux VM. Update main.bicep:

resource myVM 'Microsoft.Compute/virtualMachines@2022-09-01' = {
  name: 'myVM'
  location: 'eastus'
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_B1s'
    }
    osProfile: {
      computerName: 'myVM'
      adminUsername: 'azureuser'
      adminPassword: 'YourPassword123!' // Use a secure password
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: myNIC.id
        }
      ]
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: 'UbuntuServer'
        sku: '18.04-LTS'
        version: 'latest'
      }
    }
  }
}

resource myNIC 'Microsoft.Network/networkInterfaces@2022-09-01' = {
  name: 'myNIC'
  location: 'eastus'
  properties: {
    ipConfigurations: [
      {
        name: 'ipConfig1'
        properties: {
          subnet: {
            id: myVNet::subnets[0].id
          }
          privateIPAllocationMethod: 'Dynamic'
          publicIPAddress: {
            id: myPublicIP.id
          }
        }
      }
    ]
    networkSecurityGroup: {
      id: myNSG.id
    }
  }
}

resource myPublicIP 'Microsoft.Network/publicIPAddresses@2022-09-01' = {
  name: 'myPublicIP'
  location: 'eastus'
  properties: {
    publicIPAllocationMethod: 'Dynamic'
  }
}

This code adds a VM named myVM with a basic configuration. It uses an Ubuntu image and is connected to the VNet via a Network Interface Card (NIC). The NIC is associated with the NSG to apply the security rules.

Deploy the updated Bicep file with:

az deployment group create --resource-group <your-resource-group> --template-file main.bicep

In the next part of the tutorial, we'll explore additional configurations and optimizations for our infrastructure.

Step 5: Configure VM Extensions

To further enhance our VM, we can use VM Extensions to install software or configure the VM after it's deployed. For instance, we can install the Azure Monitor Agent to collect telemetry data. Add the following code to main.bicep:

resource myVMDiagnostics 'Microsoft.Compute/virtualMachines/extensions@2022-09-01' = {
  name: 'LinuxDiagnostic'
  location: 'eastus'
  parent: myVM
  properties: {
    publisher: 'Microsoft.Azure.Diagnostics'
    type: 'LinuxDiagnostic'
    typeHandlerVersion: '3.0'
    settings: {
      "ladCfg": {
        "diagnosticMonitorConfiguration": {
          "metrics": {
            "resourceId": myVM.id,
            "metricAggregation": [
              {
                "scheduledTransferPeriod": "PT1H"
              }
            ]
          }
        }
      }
    }
  }
}

This extension will install the Azure Monitor Agent on the VM, enabling you to monitor its performance and health.

Deploy the updated Bicep file with:

az deployment group create --resource-group <your-resource-group> --template-file main.bicep

Step 6: Cleanup Resources

Once you've tested your setup, it's a good practice to clean up resources to avoid unnecessary costs. You can delete the resource group and all its resources with:

az group delete --name <your-resource-group> --no-wait --yes

Common Mistakes

1. Incorrect Resource Group: Ensure you're deploying to the correct resource group. A typo can lead to deploying resources in an unintended group.
2. IP Address Conflicts: Double-check address spaces and prefixes to avoid IP conflicts within your VNet.
3. Security Group Rules: Ensure security rules are correctly configured. Forgetting to allow SSH can lock you out of your VM.
4. Password Complexity: Azure enforces complexity requirements for VM passwords. Ensure your password meets these requirements to avoid deployment failures.

How I Would Use This

When to Use

• Development Environments: Quickly spin up environments for testing and development.
• Prototyping: Use Bicep to prototype infrastructure setups before moving to production.
• Consistent Deployments: For environments that require consistent setups, Bicep ensures the same configuration is applied every time.

When to Avoid

• Complex Architectures: For very complex setups, consider using a combination of Bicep with Azure Blueprints or Terraform for more advanced features.
• Frequent Changes: If your infrastructure changes very frequently, it might be more efficient to manage parts of it manually or with other tools until the architecture stabilizes.

Production Considerations

• Cost Management: Monitor resource usage to avoid unexpected costs, especially with VMs and public IPs.
• Security: Regularly review and update security rules and credentials.

Lessons Learned

• Modularity: Breaking down Bicep files into smaller, reusable modules can simplify management and updates.
• Versioning: Keep track of Bicep file versions, especially when deploying to production environments.
• Testing: Always test infrastructure changes in a sandbox environment before applying them to production.

Next Steps

• Learn Advanced Bicep Features: Explore modules and conditions in Bicep for more complex scenarios.
• Integrate with CI/CD: Automate deployments by integrating Bicep with Azure DevOps or GitHub Actions.
• Explore Azure Policies: Use Azure Policies to enforce compliance and best practices across your infrastructure.

Sources

• Azure Bicep Documentation
• Azure CLI Installation
• Bicep GitHub Repository