VNET Peering has been an available feature for almost a year now and has proved to be a very useful, popular, and for a long time the most requested feature. That said, as much as we would like to mesh together all our Azure VNETs into one lovely firewalled network topology, this isn’t always possible or suitable.
The situations whereby VNET peering (or it’s associated features) cannot be used are as follows:
- VNETs in different regions cannot have a peering relationship
- VNETs with overlapping address spaces cannot be peered
- VNETs which are both created using the Classic Deployment model cannot be peered
- VNETs which are created using mixed deployment models cannot be peered across different subscriptions (although this will be available in the future)
- Both VNETs must be created using the Resource Manager Deployment Model for Gateway Chaining (using a gateway in a peered VNET) to function
- There is a default limit of 10 VNET peers per VNET. This can be raised to a maximum of 50 using Azure Support requests
This still leaves many applicable situations whereby VNET peering can be very useful and can provide the hub and spoke, high speed, low latency network which your Azure subscription/s need.