vWAN vHub connection to another Subscription vNets

Question

Hello,
i am planning a vWAN (assume in Subscription X) , where all vHubs will be in the same subscription.
and all vNets are in another subsctription (Y)
so all connections from any vHub will be cross subscription (X < -- > Y)

1- is there any traffic speed/Bandwidth limitation for cross subscription connection - a side from vHub routing units and NVA max throughput-

2-is there any routing limitations for for cross subscription connection? e.g. vHub can still receive 10,000 routes from the vNets and can handle 2000 VMs in all connected vNets?

3-Is there any limitation about the number of connection from one vHub to vNets in the other subscription ?

4-any other limitation?

5-Is this design make sense?
the main driver is isolating the billing ,responsbility, and ownership of the vWAN from the main business (services) subscription.

Answer 1

Hello @ZEIN Ahmed OBS/S EUR ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand that you are planning an Azure Virtual WAN cross-subscription setup, where all virtual hubs will be in the hub subscription and all Vnets will be in the spoke subscription and you have some questions related to this setup. I've answered them below.

Is there any traffic speed/bandwidth limitation for cross-subscription connection - aside from vHub routing units and NVA max throughput?

No, there are no traffic bandwidth limitation for cross-subscription connection. The same VWAN limitations applies.

Refer: https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about#hub

Are there any routing limitations for cross-subscription connection? e.g. vHub can still receive 10,000 routes from the vNets and can handle 2000 VMs in all connected vNets?

No other routing limitations for cross-subscription connections. Yes, vHub can still receive 10,000 routes from the vNets and can handle 2000 VMs in all connected vNets.

Refer: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#virtual-wan-limits

Is there any limitation about the number of connections from one vHub to vNets in the other subscription?

No, connections are used when VPN sites connect into a hub. It is not considered in case of Vnet connections.

Refer: https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-faq#is-there-a-network-throughput-or-connection-limit-when-using-azure-virtual-wan

Any other limitation?

• You can manage cross-tenant virtual network connections only through PowerShell or the Azure CLI. You cannot manage cross-tenant virtual network connections in the Azure portal.
• Make sure that the virtual network address space in the remote tenant/subscription doesn't overlap with any other address space within any other virtual networks already connected to the parent virtual hub.
• You need to assign required permissions to modify and access the virtual networks in the remote tenant/subscription.

Refer: https://learn.microsoft.com/en-us/azure/virtual-wan/cross-tenant-vnet

Does this design make sense?

Yes, it does and is recommended.

The hub and each spoke can be implemented in different resource groups, and, even better, in different subscriptions. When you peer virtual networks in different subscriptions, both subscriptions can be associated to the same or a different Microsoft Entra tenant. This allows for a decentralized management of each workload, while sharing services maintained in the hub.

Refer: https://learn.microsoft.com/en-us/azure/architecture/networking/hub-spoke-vwan-architecture

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/virtual-wan-network-topology

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hi, These are just the control plane changes. There will not be any limitations with data path like bandwith, routes exchange, number of connections. This design is expected and many users use this for their billing ease.