VNet Peering has just been released in to public preview by Microsoft. It allows VNets within the same region to communicate using the low latency, high bandwidth Azure backbone network . Prior to VNet peering to allow communication between two VNet’s we had to setup VNet to VNet IKE connections which required VPN Gateways to be setup. These gateways cost money to run and inject potential throughput issues and other overheads inherent with traffic encapsulation.
Reading through the blog posts that Microsoft have released and having a play with VNet peering this evening there are a couple features that I really like:
- You can peer VNet’s across subscriptions and between ARM and ASM VNet’s
- You can control if the remote VNet can use your local gateway and if you want your VNet to use a remote VNet’s gateway
- All other networking features work with VNet peering, including UDR’s, Network Appliances, VPN Gateways and NSG’s
- VNet Peering can be setup even if VNet to VNet connections via gateways are in place. As soon as the VNet peering comes up it will be preferred over the VNet to VNet connection which allows it to be implemented with very little if any traffic impact.
Microsoft have written some great blog articles on how to enable VNet peering, which can be managed via PowerShell as well as the Azure Portal.
One thing to note is that VNet peering needs to be enabled via PowerShell for each subscription that you want enable peering. The PowerShell code below can be used to enable VNet peering for your subscription.
Login-AzureRmAccount Get-AzureRmSubscription Get-AzureRmSubscription -Subscriptionname "you sub name here" |Select-AzureRmSubscription #register provider Register-Azurermproviderfeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.network Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network #show provider registration status Get-AzureRmProviderFeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.network