Azure Virtual Network, new undocumented feature, subnet peering

If you are an Azure Cloud engineer, you probably know what VNET peering is, you connect two VNETs (in the same subscription, another subscription, or another tenant) so they can communicate. The entire VNET is peered. The only control possible is the prefix associated with the peering, adding a new prefix requires synchronizing the VNET. Every subnet created with the prefix used in the peering can communicate with the distant VNET.
But recently a new feature emerged, you can select subnets that participate in the peering, you can now peer subnets instead of the VNET prefix. The feature is not yet published, is not even in a public preview, and of course, is not officially supported. Do use it in production environments.
Choosing which subnets can participate in a peering, for example, a hub and spoke model can be good. It provides an extra security layer. Image a setup where a subnet is dedicated to public-facing applications and another one for the backend that needs to connect to other services in your tenant. With this feature, you can peer from the last subnet to a HUB VNET, the other one will not have direct access to the internal network.
You can also think of peering a subnet to one VNET with a gateway and another one with another gateway (not tested) giving you the possibility to use two gateways (and maybe some routing headaches).
Peering subnets instead of the entire VNET can add problems. Governance, if teams can add and remove subnets, you will have to resynchronize peering very often. Another problem with using subnets instead of the VNET prefix is that you may end with many more prefixes to announce to an express route circuit. The Express route circuit has a limit of 1000 prefixes, you can raise this limit more easily with subnet peering.

How to deploy a subnet peering? The first option is to use Azure CLI
First, you need to register the new feature

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

The registration could take some time (more than 10 minutes). To verify if the feature is registered

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

Then with two VNETs in the same resource group

az network vnet peering create -n "vnet1-vnet2" -g RGName -o none --vnet-name vnet1 --remote-vnet vnet2 --allow-forwarded-traffic --allow-vnet-access --peer-complete-vnet false --local-subnet-names subnet1 --remote-subnet-names subnet1
az network vnet peering create -n "vnet2-vnet1" -g RGName -o none --vnet-name vnet2 --remote-vnet vnet1 --allow-forwarded-traffic --allow-vnet-access --peer-complete-vnet false --local-subnet-names subnet1 --remote-subnet-names subnet1

There are two VNETs (vnet1 and vnet2), and each has two subnets subnet1 and subnet2. The peering is created on the two VNETs by only using subnet1 subnets.

There are two VNETs (vnet1 and vnet2), and each has two subnets subnet1 and subnet2. The peering is created on the two VNETs by only using subnet1 subnets.

You can also use BICEP (and ARM Template) to deploy subnet peering, but there is a trick if you take a look at the BICEP documentation for Virtual Network Peering link there is no option for the peer-complete-vnet property in the latest API version (2023-11-01). You need to use an unpublished version, 2024-01-01

resource VnetPeeringA 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-01-01' = {
  parent: vnetA
  name: '${vnetAName}-${vnetBName}'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: false
    allowGatewayTransit: false
    useRemoteGateways: false
    peerCompleteVnets: false
    localSubnetNames: [
      'subnet1'
    ]
    remoteSubnetNames: [
      'subnet1'
    ]
    remoteVirtualNetwork: {
      id: vnetB.id
    }
  }
}

resource VnetPeeringB 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-01-01' = {
  parent: vnetB
  name: '${vnetBName}-${vnetAName}'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: false
    allowGatewayTransit: false
    useRemoteGateways: false
    peerCompleteVnets: false
    localSubnetNames: [
      'subnet1'
    ]
    remoteSubnetNames: [
      'subnet1'
    ]
    remoteVirtualNetwork: {
      id: vnetA.id
    }
  }
}

You will have a warning during the deployment.

Warning BCP081: Resource type "Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-01-01" does not have types available. Bicep is unable to validate resource properties prior to deployment, but this will not block the resource from being deployed.

But the peering will deploy without any issue.
The complete code is here

But remember it is an unofficial and unsupported feature, it may change soon and should not be used in production.