It’s very nice to have our Azure networked meshed into one firewalled network topology, but as you can imagine, this is not possible and of course not recommended.
The situations whereby VNET peering (or it’s associated features) are not recommended, are:
- 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 100 VNET peers per VNET. Probably, this can be raised using Azure Support request
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.