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:




No comments:
Post a Comment
Note: Only a member of this blog may post a comment.