Solved

VNet Peering data charge in Azure Transit Option 1/2 via ExpressRoute Edge Routers

  • 31 July 2021
  • 4 replies
  • 25 views
H

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

icon

Best answer by bashley 4 August 2021, 23:29

View original

4 replies

Shahzad Ali
Userlevel 6
Badge +6

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

H

Shahzad Ali Thanks team

B
Badge

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

H

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

1 Attachment

Reply


Terms & Conditions