Azure: Convert ARM templates to Bicep and Bicep to ARM

 If you have some old ARM templates in your environment, it can make sense to update them to Bicep to benefit from newer features and simplified syntax.

There are some general guidelines on the Microsoft site here.

To convert the ARM templates to Bicep, you can use the Bicep tools. Bicep tools can be installed as an AZ CLI version, install info (cmd structure is: az bicep decompile) or as a Bicep CLI version, install info (where the cmd is e.g.: bicep decompile).

To create a Bicep file from an ARM template, use the following command:

bicep decompile <ARM template filename>

or

az bicep decompile --file <ARM template filename>

This will create a Bicep file and place it in the same folder as where the ARM template is located.

You can also convert from Bicep to ARM by using the bicep build command. This can be useful if you want to see what the Bicep is translated into before it is deployed. Note that this command does not account for a parameters file (if you have that), only the Bicep file itself.

bicep build <Bicep file name>

or

az bicep build --file <Bicep file name>

When you have converted a template, it is a good idea to run the deployment with the what-if option to check that nothing changes compared to what is already deployed. See here for more on using what-if.

Note that LLMs have gotten better at ARM templates and Bicep lately. Now, it is quite efficient at suggesting improvements and sanity checking code. This could be for example if you have repetitive code that can be optimized with a copy loop or if you want to optimize parameter naming with concat to construct names.

Azure: VNet peerings to multiple VNets with Bicep and for-expression

 VNet peerings in Azure are slightly more complicated than other resources. The reason for this is that a single VNet peering consists of two distinct resources, a local peering and a remote peering - and the remote peering is often placed outside of the current resource group (or scope).

If both VNets are in the same resource group (RG), then it is straight forward. If, however, the remote VNet is in another resource group, but in the same subscription, or in another subscription altogether, then this must be handled separately.

With ARM templates, this can be done using nested templates.  For Bicep you must use a module (basically another Bicep file that is referenced from the main file).

In the template that I'll reference below, it has a for-expression, or a loop, so that multiple peerings can be created by just updating the parameters file.

If you specify just a VNet name and an RG, the template will assume the remote VNet is in the same subscription. If you add a subcriptionId to one or more objects in the array, it will look for the RG in that subscription.

Note that all VNets must already be deployed.

Below are the files including the module. Note that the module must not be deployed itself only referenced (that is if you have a pipeline set up for deployment).

bicep file

param file

module file