Transitive network flow between peered vnets is on our roadmap but we have no dates to share at this time.
An error occurred while saving the commentEric Tacik commented
Transitive routing enables multiple use cases, including:
- “Choke” point for all routing across enterprise – we can use central hub or hubs to see all “east-west” traffic by using features like NSG flow logs. Without transitive routing, this information is distributed and hard to correlate
- Flexible VNet access - The network can now emulate how I have network design working on-premises. If there is an unanticipated change in network design, I currently need to add yet another VNet peer – this becomes unwieldy over time
- Scalability – when networks get too big I need to refactor and grow them. Without transit routing, I need to use third party products to provide transit routing overlay – not very efficient. For very large customers the overlay does not provide enough bandwidth to scale up/out. That makes Azure not a viable solutions unfortunately.
I have run into all of these problems with previous customers. When AWS announced Transit Gateway last year, it was a big deal and every cloud infrastructure team started using it. That is a killer service, and something that Azure needs to offer as well.
Custom RBAC is supporting the management groups scope with a few limitations. The MG team and Identity teams are working on removing these limitations but no timeline is available yet.
Azure DNS Private Zones are expected to become available in Azure Government at some point during CY18 H2.