Recently, I was working with a large healthcare provider to design their public facing mission critical web platform. The customer already had ExpressRoute connection with a 50mb line, not super fast but it doesnt need to be either always.
Given the design divided the environments in their respective vNets, we ended up creating multiple vNets around 9 in Azure. Connecting each vNet to on-premise network via ExpressRoute would mean consuming 9 connections\links out of 10 (20 for premium sku). This was sub optimal as that will not leave any room for the future projects to utilise the same circuit on-premise connectivity, plus, expansion of additional evironments in future on the platform will be limited as well.
So how could you avoid this problem?
VNet Peering comes to rescue here, following diagram dipicts the topology which can be used to achieve the above design-
- You can also use transitive vnet (‘transitive’ is just a given name) for NVAs, implementing hub and spoke model.
- vNet Peering does not allow transitive routing i.e. if three vnets are peered in a chain, vnet1 ,vnet2 and vnet3 then vnet1 cannot talk to vnet3.
- vNet Peering is always created from both vNets to work, hence above diagram has two arrows for each vNet Peering.
- As all the vnets are connected to single VPN Gateway via ExpressRoute, bandwidth between on-prem and Azure vNets will limited to the VPN Gateway SKU selected for the Expressroute connection.