Skip to main content

Hi guys,



In the Azure Networking 101 course/video, the instructor said doing Azure Transit via ExpressRoute Edge Routers can avoid VNet Peering data charge. I don't quite get it as there is data charge still on those two VNet Peering between Spoke VNets and Hub VNet that ExpressRoute terminates, isn't there?



Or he actually meant avoiding the data charge of VNet Peering between Spoke VNets? But what is the actual difference from commercial prospective? Traversing two VNet Peering through Hub VNet V.S. traversing one direct VNet Peering between two Spoke VNets.



Thanks



 



JF

We will get back to you about this shortly
Umair Hoodbhoy Manny Calero

Shahzad Ali Thanks team

Hua (Jack) Fang - thanks for your question. 



So even though you have a Hub and Spoke topology connected to ExpressRoute with VNET peering between the VNETs, when advertising a default or summary route in from on-prem the underlying Azure fabric recognizes data flows from spoke to spoke (hairpinning off the MSEEs) and does not flag this flow for VNET peering charges.  This is why a lot of customers use this method initially.   



If the data flow is leveraging UDRs in the spokes and "routing" off something inside the Hub for spoke to spoke traffic, VNET peering charges are applied.  Keep in mind that while this does seem like a good idea for cost savings, it is not something that is recommended by the Azure Product Team and comes with some caveats as discussed in the ACE training course material.



Here is some additional reference material on spoke to spoke communication options in Azure: https://cloudnetsec.blogspot.com/2019/02/azure-intra-region-and-inter-region.html

Bryan Ashley - thanks for your response.



I think what missing in the course/presentation are:



1. "Allow Gateway Transit" in the Hub VNet when enabling VNet Peering between Hub and Spoke VNet



2. "Use Remote Gateway" in both Spoke VNets when enabling VNet Peering between Hub and Spoke VNet



Then in that case, Spoke VNets can utilize the virtual network gateway (it's a ExpressRoute Gateway) by enabling VNet Peering to the Hub VNet.



Acknowledged the trick of injecting default route or VNet summary route backwards to make Inter-VNet traffic stays in Azure through MSEE, but I just still can't understand why "when leveraging this option, the Azure fabric recognizes this data path and does not apply charges for the traffic when it traverses the VNET peerings." 



JF

Reply


Terms & Conditions