can express route circuit connect (in CAC) to multiple gateways (in CAC and CAE) at the same time?

Question

can express route circuit connect (in CAC) to multiple gateways (in CAC and CAE) at the same time?

Vanessa Xu 20

Hello,

We would like to validate our planned Azure ExpressRoute design and understand any limitations or recommended practices.

Current Design

We have an ExpressRoute circuit connected to an ExpressRoute Virtual Network Gateway deployed in a dedicated Site Connection VNet in Canada Central (CAC).
The Site Connection VNet is peered with:
- Non-Production Hub VNet in Canada Central
  - Production Hub VNet in Canada Central
Both hub VNets currently consume on-premises connectivity through the ExpressRoute gateway in the Site Connection VNet using gateway transit / remote gateway design.
The current ExpressRoute gateway SKU is Standard.

Planned Design Change

We are planning to:

Deploy an ExpressRoute Virtual Network Gateway directly in each Hub VNet — Production Hub and Non-Production Hub — in Canada Central.
Migrate ExpressRoute connectivity from the current Site Connection VNet gateway to the hub gateways.
Keep the existing ExpressRoute circuit unchanged.
Potentially upgrade the current ExpressRoute gateway SKU from Standard to the scalable gateway SKU ErGwScale.
Explore using the same ExpressRoute circuit for connectivity to Canada East (CAE) as well.

Questions

Can a single existing ExpressRoute circuit be connected to both the Production Hub gateway and Non-Production Hub gateway in Canada Central at the same time?
Are there any limitations, routing considerations, or Microsoft-recommended practices when migrating from a centralized Site Connection VNet gateway to separate ExpressRoute gateways in each Hub VNet?
Will the existing ExpressRoute circuit continue to advertise and learn routes correctly if it is connected directly to the non-prd Hub VNets (Scalable ErGwScale gateway SKU) and the current Site Connection VNet (Standard SKU gateway) ?
Are there specific requirements or limitations for using ErGwScale, such as:
- Supported regions
- Supported ExpressRoute circuit SKUs
- Minimum gateway subnet size
- Compatibility with existing VNet peering and gateway transit
- Coexistence with VPN gateways, if applicable
We also plan to consume the same ExpressRoute circuit from Canada East (CAE). Can the same ExpressRoute circuit be linked to ExpressRoute gateways deployed in both Canada Central and Canada East?
If connectivity from both CAC and CAE is supported, are there any requirements for:
- ExpressRoute Premium
- FastPath
- Gateway SKU selection
- Regional or geopolitical restrictions
Are there any latency, asymmetric routing, route propagation, or resiliency concerns we should consider when using the same ExpressRoute circuit across Canada Central and Canada East?

Thank you.

Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-02T15:18:59.3866667+00:00
Hello @Vanessa Xu

Thank you for reaching out to the Q&A platform.

Yes, the proposed design is supported, with a few considerations.

1. Can a single ExpressRoute circuit connect to both Production and Non-Production Hub gateways in Canada Central?

Yes. A single ExpressRoute circuit can be connected to multiple ExpressRoute virtual network gateways (VNets) within the same geopolitical region, subject to the circuit connection limits. Standard circuits support up to 10 VNet connections, while Premium increases this limit depending on circuit bandwidth.

2. Migration from a centralized Site Connection VNet gateway to dedicated hub gateways

Technically supported, but Microsoft generally recommends evaluating whether separate gateways are actually required. Moving from a shared gateway-transit model to dedicated gateways increases management overhead and cost. During migration, ensure route advertisements are carefully reviewed to avoid overlapping prefixes or unexpected routing behaviour. Route advertisement limits (1,000 VNet prefixes advertised by a gateway) and gateway scale limits should also be considered

3. Can the circuit connect simultaneously to the existing Site Connection VNet gateway and new Hub gateways?

Yes, provided the circuit still has available VNet connection capacity. The ExpressRoute circuit can maintain multiple VNet gateway connections concurrently during a migration period. Route advertisement limits and overall routing design should be validated to avoid unintended path selection.

4. ErGwScale considerations

Supported ExpressRoute gateway SKU: ErGwScale is a supported ExpressRoute Virtual Network Gateway SKU.

Supports fixed scaling or autoscaling between 1 and 40 scale units. Each scale unit provides approximately 1 Gbps of capacity.

Gateway subnet should be__/27 or larger__; Microsoft recommends using__/26 or larger__ when planning large-scale connectivity.

Existing VNet peering and gateway transit scenarios remain supported

A VNet can have both a VPN gateway and an ExpressRoute gateway, provided standard coexistence requirements are met.

Standard Public IP is required; Basic Public IP is not supported.

5. Can the same ExpressRoute circuit be used for both Canada Central and Canada East?

Yes. Canada Central and Canada East are within the same geopolitical region (North America). A Standard ExpressRoute circuit can be linked to multiple VNets in the same geopolitical region, including gateways deployed in both CAC and CAE. ExpressRoute Premium is not required solely for this scenario. Premium is typically required when connecting VNets across different geopolitical regions

6. Premium, FastPath, and gateway selection requirements

ExpressRoute Premium: Not required for CAC ↔ CAE connectivity because both regions belong to the same geopolitical region.

FastPath: Optional and generally recommended only for high-throughput or low-latency requirements. It is not required simply because multiple regions or gateways are connected to the same circuit.

Gateway SKU: Select based on throughput, route scale, flow count, and resiliency requirements. ErGwScale provides greater scalability and operational flexibility than Standard

7. Routing and resiliency considerations

When the same ExpressRoute circuit is connected to gateways in multiple VNets and regions:

Validate effective routes and BGP advertisements to avoid unexpected path selection.

Review route advertisement limits and total route counts.

Expect slightly higher latency for traffic traversing regions compared to local-region communication.

If inter-VNet communication between CAC and CAE is required, Microsoft generally recommends VNet peering for the best performance, with ExpressRoute primarily used for on-premises connectivity. Overall, the proposed architecture is supported. The primary design considerations are VNet connection limits, route scale limits, migration planning, and whether separate ExpressRoute gateways provide sufficient operational benefit compared to the current gateway-transit design.

Refer:
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-about-virtual-network-gateways
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-howto-linkvnet-portal-resource-manager
https://learn.microsoft.com/en-us/azure/expressroute/virtual-network-connectivity-guidance
https://learn.microsoft.com/en-us/azure/expressroute/scalable-gateway
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-howto-add-gateway-portal-resource-manager
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-locations
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-routing
Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-03T14:26:39.28+00:00

Hello @Vanessa Xu

Following up to see if the above information was helpful. And, if you have any further query do let us know.
Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-06T16:41:07.7333333+00:00

Hello @Vanessa Xu

I wanted to follow up regarding my previous email and check if the information provided was helpful.
Vanessa Xu 20 Reputation points

2026-07-06T21:56:28.2933333+00:00

Thank you for the detailed answers!

Currently, the spoke VNets are peered with the SiteConnect VNet so that the ExpressRoute circuit can learn the spoke subnets.

If the gateway subnet is migrated from the SiteConnect VNet to the Hub VNet, will the existing spoke-to-SiteConnect VNet peerings still be required for the ExpressRoute BGP advertisements? Or will the ExpressRoute gateway in the Hub VNet be able to learn and advertise the spoke subnets through the Hub-to-spoke VNet peerings alone?

1 answer

Your answer

Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-03T14:26:39.28+00:00

Hello @Vanessa Xu

Following up to see if the above information was helpful. And, if you have any further query do let us know.
Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-06T16:41:07.7333333+00:00

Hello @Vanessa Xu

I wanted to follow up regarding my previous email and check if the information provided was helpful.
Vanessa Xu 20 Reputation points

2026-07-06T21:56:28.2933333+00:00

Thank you for the detailed answers!

Currently, the spoke VNets are peered with the SiteConnect VNet so that the ExpressRoute circuit can learn the spoke subnets.

If the gateway subnet is migrated from the SiteConnect VNet to the Hub VNet, will the existing spoke-to-SiteConnect VNet peerings still be required for the ExpressRoute BGP advertisements? Or will the ExpressRoute gateway in the Hub VNet be able to learn and advertise the spoke subnets through the Hub-to-spoke VNet peerings alone?

Answer 1

Hello @Vanessa Xu

If the ExpressRoute gateway is migrated from the SiteConnect VNet to the Hub VNet, the spoke-to-SiteConnect VNet peerings would no longer be required specifically for ExpressRoute route advertisement, provided the hub-and-spoke peerings are configured correctly.

In the new design:

The ExpressRoute gateway resides in the Hub VNet.
Each spoke VNet is peered directly to the Hub VNet.
The Hub-to-Spoke peering has Allow gateway transit enabled.
The Spoke-to-Hub peering has Use remote gateway enabled.

With this configuration, the ExpressRoute gateway in the Hub VNet can learn the address spaces of the peered spoke VNets and advertise those prefixes to on-premises via BGP. Azure automatically advertises the address spaces of the gateway VNet and qualifying peered VNets through the ExpressRoute gateway.

Therefore, once the migration is completed and the hub-spoke peerings are configured with gateway transit appropriately, there is generally no requirement to maintain the existing spoke-to-SiteConnect VNet peerings solely for ExpressRoute route propagation purposes.

As part of the migration, we recommend validating:

Gateway transit settings on all hub-spoke peerings.
Effective routes in the spoke VNets.
Advertised routes on the ExpressRoute circuit.
BGP route tables on the on-premises routers after the change.

This validation helps ensure the spoke prefixes are being learned and advertised as expected before decommissioning the existing SiteConnect gateway connectivity.
Please "Accept Answer" and “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

Sindhuja Dasari 1,860 Reputation points Microsoft External Staff Moderator

2026-07-13T05:37:16.4+00:00

Hello @Vanessa Xu

Following up to see if the above information was helpful. And, if you have any further query do let us know.