Tuesday, June 11, 2024

Azure: VNet with VNet peering in bicep

 Here's a bicep file including a module which installs a VNet and a VNet peering to an existing VNet. A VNet peering consists of a local and a remote peering. The remote peering is installed outside the scope of the current deployment (in a different resource group) and so has to be addressed specifically. With ARM templates this is solved by using nested templates. With bicep this is done using modules (a separate bicep file which is referenced from the main bicep file).

The bicep file references an existing VNet (which typically would be a Hub VNet). So this has to be implemented beforehand.

To use the files, simply update the parameters file with relevant info. And update the path to the module in the bicep file. If you deploy using Azure Pipelines or Github Actions make sure that the module file is not placed anywhere where it will be deployed (this throws an error), it should just be referenced.

The files are available here on Github:




Monday, June 10, 2024

Formatting JSON files

 If you have a JSON file which is not properly formatted, there are several ways to fix it.

An online tool such as JSON Formatter & Validator can be used.

If using Visual Studio Code, the formatting feature is built in. Just right click anywhere in the JSON file and choose Format Document (or press Shift+Alt+F), see below:

Azure policy: Deny VNet peering to non-approved VNets

 As part of the Azure Landing Zone architecture, there is a policy that denies the creation of VNet peerings to non-allowed VNets, see policy here.

This policy is relevant to a apply in a hub-spoke setup where you want to avoid that spoke VNets, or spoke landing zones, can create VNet peerings to anything other than the defined Hub VNets.

At current client we've been running this policy since December, 2023 and it's been working fine.

However, about a month ago some policy evaluation behavior changed (the policy itself or the templates have not changed) and now for certain bicep files, the policy blocks deployments even when using approved VNets for the peering. It wasn't for all bicep files and ARM templates still worked.

Microsoft Support came up with a minor update to the policy definition to effectively have the same rule but the syntax is slightly different. This works.

We haven't found an explanation yet as to why there was a change in policy evaluation behavior.

But the updated policy can be found here on Github.

Tuesday, June 4, 2024

Azure policy: Auto create DNS records in private DNS zones using multiple zones

 There are certain Azure PaaS services that when used together with private endpoints, require not just one A record in one DNS (as is the case for most PaaS services) but multiple A records in multiple private DNS zones (PDNS).

Examples of PaaS services that require this are (see here for full list): 

  • Azure Monitor
  • Power BI
  • Azure Data Explorer
  • Azure Arc
  • Azure Health Data Services

When using private endpoints at scale, MSFT recommends using Azure Policy for the A record creation. I've described this in a previous article, see here.

But the MSFT policy to create DNS records can only handle a single PDNS zone, not multiple PDNS zones.

I found a fix to this on the 'Blog Cloud63' in this post (and here's a direct link to his policy definition), so thanks goes to Vincent Misson for that.

He basically expands on the MSFT policy for the resource 'privateDnsZoneGroups' by adding a copy loop to the properties of the resource. The copy loop then goes through an array of PDNS zone resource IDs and adds multiple items under properties. The privateDnsZoneGroups resource is what actually creates the A record in the PDNS zones.

Below you can see snippet of the code with the copy loop (modified policy):

And without the copy loop (default MSFT policy)

I have uploaded my slightly modified version of the policy to Github.

It has been tested with Azure Monitor, specifically with private endpoints for Azure Monitor Private Link Scope (AMPLS) and it works as expected (11 records are created in 5 separate PDNS zones).