Azure: Enable and configure subnet peering

 Subnet peering in Azure is a feature that was introduced in April 2025. My guess is that not that many organizations are using it, as it has a quite specific/limited use case.

Subnet peering is enabled on the VNet peering resource. So you still have a local and remote VNet peering resource that peers two VNets but you specify a property in those peerings (peerCompleteVnets: false) that enables the subnet peering - and disables full VNet peering.

A VNet peering resource cannot be both a VNet peering and a subnet peering, it is either or.

Prerequisites

Before being able to deploy this feature, it has to be enabled at the subscription level. According to the documentation, a request form must be filled out first. But when you do that, Microsoft just replies with the instructions on how to enable the feature.

They do this because there are some hard limitations for the use currently, the most important one being the following:

Note: The following instructions to enable feature on subscription level use AZ CLI:

# Log in to Azure: 

az login

# Set the correct subscription: 

az account set –subscription <sub id>

# Verify correct sub is set:

Az account show

# Enable subnet peering on subscription

az feature register --namespace Microsoft.Network --name AllowMultiplePeeringLinksBetweenVnets

# You will be prompted to run this command as well to complete the registration:

az provider register -n Microsoft.Network

# Verify

az feature show --name AllowMultiplePeeringLinksBetweenVnets --namespace Microsoft.Network --query 'properties.state' -o tsv

# If done correctly, the command will output (see screenshot below): Registered

Enable subnet peering on VNet peering resource

You can enable subnet peering via az cli commands or directly in the ARM/Bicep template.

Example using AZ CLI (that I have tested):

az network vnet peering create --name vnet-conn-weu-001_to_vnet-conn-weu-004 --resource-group rg-deploymentstack-001 --vnet-name vnet-conn-weu-004 --remote-vnet vnet-conn-weu-005 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names snet-conn-weu-002 --remote-subnet-names snet-conn-weu-001

az network vnet peering create --name vnet-conn-weu-004_to_vnet-conn-weu-001 --resource-group rg-deploymentstack-001 --vnet-name vnet-conn-weu-005 --remote-vnet vnet-conn-weu-004 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names snet-conn-weu-001 --remote-subnet-names snet-conn-weu-002

Example using Bicep:

When configuring this via Bicep, there are two main changes to be done to the VNet peering resource:

1) The property peerCompleteVnets for the VNet peering must be set to false

2) localSubnetNames and localSubnetNames values must be specified as well. The values are the subnet names, not the subnet IP ranges. See screenshot below:

When the subnet peering has been implemented, it can be viewed from the Azure Portal by going to the VNet peering itself (under VNets). Under Peering type, Subnet will be active, see below:

Enable VNet encryption in Azure

 It is possible to enable encryption on a VNet so that in-transit traffic between virtual machines within the VNet is encrypted (using DTLS). See MS article here for more info.

It is straightforward to enable, it can be done in different ways e.g. via the portal or via code.

To enable in Azure portal, go to the VNet -> Overview -> Properties tab -> click the Encryption link currently saying 'disabled' -> check the 'enabled' box -> save the changes

To enable it using Azure Verfied Modules, you just add vnetEncryption: true under VNet parameters, see below, or full example on GitHub.

module vnet 'br/public:avm/res/network/virtual-network:0.7.2' = {

  name: 'vnetDeployment'

  params: {

    name: vnetName

    addressPrefixes: vnetAddressPrefixes

    subnets: [

      {

        addressPrefix: subnetAddressPrefix

        name: subnet_01_name

        networkSecurityGroupResourceId: networksecuritygroup.outputs.resourceId

      }

    ]

    vnetEncryption: true

  }

}

If you look at the final ARM template result in the portal, the following section is added under VNet paramters:

"encryption": {

                    "enabled": true,

                    "enforcement": "AllowUnencrypted"

                }

The enforcement flag only allows AllowUnencrypted for now. MS mentions that an option to drop unencrypted traffic will be added later.

Note that there are certain requirements and limitations, for example, certain VM SKUs must be used for this to work, see more here.

Using Git rebase to sync latest changes in main branch to feature branch

You have a scenario where you create a feature branch from the main branch. Then you work for a while on the feature branch and want to merge these changes into main.

But in the meantime changes have also been made to main and you are unsure if there are now conflicts.

With Git rebase you can take all the latest changes from main and sync them into your current feature branch. And all your current commits will be added on top of those changes from main (this keeps the commit history clean). It is similar to if you started over on a fresh feature branch from main and then added all your changes again.

It is also described here and on YouTube here.

To use git rebase, run the following commands:

Go to main branch first and get latest changes:

git switch main

git pull

Then switch to your existing feature branch:

git switch feature/my-feature-branch

If others have worked on the same feature branch, you can pull the latest changes with:

git pull --rebase (optional)

If only you have worked on the feature branch you can skip that (as you know you have the latest changes) and then run the rebase command:

git rebase main

This will add all the latest changes to your local feature branch.

Then you need to push those changes to the remote feature branch (typically, so you can create a pull request and merge everything into main):

git push --force-with-lease

You cannot run a regular git push since the local and remote branch history are no longer the same (since changes from main have been interjected into the feature branch). Using --force-with-lease is safe as it checks that remote and local are still the same before pushing and if not it will fail.

That's it.

If you run into a merge conflict you can try and open the file and update as needed and then run: 

git add the-file-name-you-updated

git rebase --continue

Or if you want to cancel entirely, run:

git rebase --abort

To see more info on general Git usage and commands, see here.

Compare two columns in Excel

 If you have two large lists that you need to compare (to identify what items are missing in one of the lists), this can be done in excel.

Add the first list (the bigger of the two) in column A and the other list in column B.

For column C, add this formula in cell C2 and drag it all the way down to the bottom column C:

=IF(COUNTIF($B:$B; A2)=0; "Item in column A is missing in column B"; "Item exists in both lists")

What it does is for each cell in column A, it will run through all the items in column B and look for a match and note if it finds one, see screenshot below.

An example xlsx file is available on GitHub (choose download raw file).

Create architecture diagrams with Mermaid and ChatGPT

 Mermaid is a practical tool that can create all sorts of diagrams as code. And if you combine it with an LLM, you can create it with a prompt.

To view the results, go to https://mermaid.live and add the code in the box on the left.

As an example, I had ChatGPT create a hybrid cloud architecture diagram with an on-prem location connected to Azure via an ExpressRoute. For encryption, VPN runs inside the ER circuit. The Azure setup is hub-spoke meaning the central networking components are in the hub and are connected to multiple spoke VNets. Traffic flows through an Azure Firewall.

I have put the code in a markdown file on Github (click Raw to view code).

Result looks like below:

If saving the mermaid code in a markdown file (.md) it will render the diagram directly in Github as long as it is wrapped with ```mermaid at the beginning and ``` at the end.

And if you copy raw code to mermaid.live, only use the text inside the wrapper.

Here's what it looks like at mermaid.live:

You can also preview the diagram in Visual Studio Code if you install the Markdown Preview Mermaid Support extension (and save file as .md). To view diagram, just right-click the .md file and choose "Open preview". It looks like this:

The native Mermaid file format extension is .mmd and there are extensions for VS Code for that as well.

Azure Bastion Developer - shared Bastion pool

 The Azure Bastion is useful for connecting securely to virtual machine without exposing the VMs to the internet using public IP's.

This however, requires a dedicated Bastion instance to be deployed and an AzureBastionSubnet.

With Bastion Developer, test/dev users can connect to the local IP of the VM via Bastion using a shared pool, so no dedicated setup required. The features are limited though. See here for more info.

To use, in the portal simply go to the VM -> Connect -> Bastion.

Add credentials and click Connect. This will open a remote session in the browser, see below:

Azure: Troubleshoot connectivity to a key vault with a private endpoint

 If you have a key vault that you can't reach there can be multiple reasons for this. Two of the main ones are DNS issues and firewall blocks.

This post will go over those two issues and show a couple of ways to test for connectivity.

When working in hybrid setups with an on-prem location connected to Azure either via VPN or ExpressRoute then it happens that you can create and see the key vault (this also goes for e.g. storage accounts and other PaaS services) but you get an error when trying to add a secret or other content to it. The error can mention e.g. "the connection to the data plane failed".

To troubleshoot, first we ensure that the local IP of the private endpoint can be resolved.

nslookup myown-keyvault.vault.azure.net

On Linux you can use the command dig to get slightly better lookup details than with nslookup:

dig myown-keyvault.vault.azure.net

This should resolve to a local IP. If it doesn't resolve at all or if it returns a public IP, there is something wrong with the DNS setup.

More info on troubleshooting DNS can be found here.

If that works, you can check for connectivity from your source. This can be done in a couple of ways and either of them is fine.

From Windows run:

tnc myown-keyvault.vault.azure.net -port 443

From Linux run (netcat and nc is same command):

nc -zv myown-keyvault.vault.azure.net 443

All data to a key vault goes over port 443, so if you have connectivity on that port and it can resolve the IP, then you should be good.

Alternatively try:

$(Invoke-WebRequest -UseBasicParsing -Uri https://myown-keyvault.vault.azure.net/healthstatus).Headers

Or from Linux:

curl -i https://myown-keyvault.vault.azure.net/healthstatus

There is more info on troubleshooting behind a firewall here.