On this page · 11 sections
Summary. Azure's ExpressRoute gateway advertises a maximum of 1,000 IPv4 prefixes and 100 IPv6 prefixes from a virtual network to on-premises, and the Premium SKU does not raise either number. Premium raises the inbound ceiling from 4,000 to 10,000 routes, which is the opposite direction to the one most hub-and-spoke estates run out of first. Microsoft's answer is a virtual-network property called summarizedGatewayPrefixes, and the ExpressRoute gateway documentation now recommends it in its "Advertised prefix scale" section. The property behaves in a way the documentation states only obliquely: it replaces the hub virtual network's own advertised prefix rather than adding a summary alongside it, and Azure performs no validation that the summary covers anything real. The two Microsoft pages that describe the feature — the Azure Virtual Network concept article and the Azure Networking blog post that introduced it — both carry a last-modified date of 20 May 2026, and neither contains the words "preview" or "generally available". The concept article's own ms.date reads 31 March 2026, and the ExpressRoute virtual network gateway page that now recommends the property carries the same 31 March 2026 ms.date and 20 May 2026 last-updated stamp. The property landed on virtual network API version 2025-07-01, and as of 21 August 2026 Microsoft has published no counter that tells you how close a hub sits to the 1,000-prefix line.
What the cap actually is
Three separate numbers govern an ExpressRoute private peering, and teams routinely confuse them.
The first is what on-premises advertises into Azure. The ExpressRoute FAQ states: "ExpressRoute accepts up to 4,000 prefixes for private peering and 200 prefixes for Microsoft peering. You can increase the limit to 10,000 routes for private peering when using ExpressRoute premium."
The second is what Azure advertises back out. The same page: "There's a maximum of 1000 IPv4 prefixes advertised on a single ExpressRoute connection, or through virtual networking peering using gateway transit." The ExpressRoute virtual network gateway documentation puts it more bluntly: "The maximum number of routes advertised by gateway is 1,000 routes."
The third is the overall circuit ceiling: "ExpressRoute supports up to 11,000 routes, covering virtual network address spaces, on-premises networks, and virtual network peering connections."
Set against the SKU table, those numbers do not line up cleanly.
| Limit | Local / Standard SKU | Premium SKU | Raised by Premium? |
|---|---|---|---|
| IPv4 on-premises routes accepted over private peering | 4,000 | 10,000 | Yes |
| IPv6 on-premises routes accepted over private peering | 100 | 100 | No |
| IPv4 VNet routes advertised by the gateway to the circuit | 1,000 | 1,000 | No |
| IPv6 VNet routes advertised by the gateway to the circuit | 100 | 100 | No |
| IPv4 routes advertised to Microsoft peering from on-premises | 200 | 200 | No |
A fourth number sits on the gateway itself rather than the circuit. The gateway documentation gives "Number of routes learned by gateway" as 4,000 for Standard/ERGw1Az and 9,500 for High Performance/ERGw2Az, Ultra Performance/ErGw3Az and every ErGwScale configuration. So the top gateway SKU learns 9,500 routes, Premium raises the circuit to 10,000, and the stated ExpressRoute ceiling is 11,000. Microsoft publishes all three figures and reconciles none of them. We covered the same asymmetry from the AWS side in our analysis of the Direct Connect 1,000-prefix limit versus ExpressRoute route caps.
The 1,000 outbound cap is the one that bites, because Azure counts spokes. The FAQ's own worked example: "if you have a virtual network enabled to allow gateway transit with 1 address space and 500 spoke virtual network enabled using the 'Allow Remote Gateway' option, the virtual network deployed with the gateway advertises 501 prefixes to on-premises." A virtual network with an ExpressRoute gateway can peer with up to 500 other virtual networks. Give each spoke two or three address spaces and a 500-spoke landing zone crosses 1,000 without anyone adding a subnet.
What happens when you cross it
Not a warning. A disconnect. The ExpressRoute FAQ: "The connection between the ExpressRoute circuit and the gateway disconnects including peered virtual network using gateway transit. Connectivity re-establishes when the prefix limit is no longer exceeded."
That is every spoke behind the hub, dropped at once, by an event as ordinary as a platform team adding an address space to a new environment. The blast radius has nothing to do with which spoke pushed the count over the line.
What summarizedGatewayPrefixes does
summarizedGatewayPrefixes is a property on the virtual network resource. The Azure Virtual Network concept article describes the behaviour in two parts:
"Azure VPN Gateway and ExpressRoute Gateway ignore the address space of the virtual network with the gateway (hub) and publish the summarized prefixes instead."
"For each peered virtual network (spoke), Azure VPN Gateway and ExpressRoute Gateway check whether the spoke's address space is covered by the summarized space. If it's covered, the spoke address space isn't advertised."
The operative verb in the first sentence is "ignore". The hub's own address space stops being advertised the moment the property is set, whether or not the summary you supplied covers it. The documentation flags this only as an instruction — "When configuring summarized CIDRs, ensure that the summarized prefix includes the gateway virtual network address space" — and not as a consequence.
A community lab published as erjosito/lab-summarized-gw-prefixes-20260427 tested the property against a Standard ExpressRoute gateway on API version 2025-07-01 and recorded what happens when you ignore that instruction. Setting 172.16.0.0/16 on a hub addressed 10.0.0.0/16 was accepted: "The hub VNet prefix (10.0.0.0/16) is no longer advertised — on-premises would not know how to reach it via the ER gateway." The same lab reports that a partial supernet of 10.0.0.0/15 absorbed the hub and one spoke while a second spoke at 10.2.0.0/16 continued to be advertised individually, and that setting the property back to null restored the original advertisements. That repository is a self-described machine-generated lab writeup with four commits, not a Microsoft statement, and its findings should be treated as a hypothesis to reproduce in your own subscription rather than as documentation.
The behaviour it describes is consistent with what Microsoft does say, though. The concept article's rules are that the prefix list "is an independent value. It can be outside the virtual network's specified address space", that you should not "use overlapping prefixes within the list", and that overlap with peered virtual networks "is allowed and expected in hub-and-spoke designs". An independent value that can sit outside the address space is, by definition, one Azure is not checking against reality.
Three constraints the announcement does not lead with
Only the hub reads it. "The hub virtual network that contains the gateway subnet is the only virtual network that reads the summarizedGatewayPrefixes property. If you set this property on spoke (peered) virtual networks, it's ignored." A Terraform or Bicep module that stamps the property across every virtual network in a landing zone will report success on all of them and change behaviour on one.
It applies before it applies. "You can set the summarizedGatewayPrefixes property even if the virtual network doesn't have a gateway subnet or gateway. However, this property doesn't take effect until the virtual network has a gateway subnet and gateway." Infrastructure-as-code drift checks will show the property as set and converged long before it does anything.
The VPN Gateway side is undocumented. Microsoft describes the property as affecting "Azure VPN Gateway and ExpressRoute Gateway" on three separate pages. The Azure VPN Gateway FAQ does not mention summarizedGatewayPrefixes anywhere. That FAQ does state an inbound limit — "Azure VPN Gateway supports up to 4,000 prefixes. The BGP session is dropped if the number of prefixes exceeds the limit" — and lists what the gateway advertises without ever giving a number for it. It also carries a rule that interacts awkwardly with summarisation: "You cannot advertise the exact prefixes as your virtual network (including peered virtual networks) prefixes... However, you can advertise a prefix that is a superset of your virtual network's address space. For example, if your virtual network uses the address space 10.0.0.0/16, you can advertise 10.0.0.0/8, but not 10.0.0.0/16 or 10.0.0.0/24." Whether summarizedGatewayPrefixes set to exactly the hub's own address space is accepted or filtered on a VPN Gateway is not answered by any page Microsoft has published.
AWS answered the same problem the other way round
| Direction | Azure ExpressRoute private peering | AWS Direct Connect |
|---|---|---|
| On-premises to cloud | 4,000 IPv4 (10,000 with Premium) | 100 each IPv4/IPv6 by default, raisable to 1,000 each with prefix controls |
| Cloud to on-premises | 1,000 IPv4 / 100 IPv6, fixed | 200 combined IPv4+IPv6 per Transit Gateway on a transit VIF |
| Cloud to on-premises, large scale | Reduce the count with summarizedGatewayPrefixes | 5,000 from a Cloud WAN core network Direct Connect gateway attachment |
| Public peering | 200 to Microsoft peering | 1,000 per public VIF, "This limit cannot be increased" |
The AWS Direct Connect quotas page marks its outbound quotas as soft, with the comment "Contact your Solutions Architect (SA) or Technical Account Manager (TAM) for further assistance." Azure's outbound cap carries no such escape hatch.
AWS also exposes the accounting Azure keeps internal. Inbound prefix controls give each dedicated connection a prefix pool sized by link speed — 5,000 on 1 Gbps and 10 Gbps, 30,000 on 100 Gbps, 50,000 on 400 Gbps — from which each virtual interface draws an explicit allocation, defaulting to 100 per address family and capped at 1,000. A Direct Connect gateway holds 10,000 combined IPv4 and IPv6 allocations across at most 30 attached virtual interfaces, and an AWS Interconnect connection silently consumes 2,000 of that 10,000. You read the current state through prefixPoolSizeIpv4, prefixPoolUnallocatedCountIpv4 and totalPrefixPoolAllocations, per the prefix allocations guide. Azure publishes no equivalent counter for advertised prefixes, so the only way to know how close a hub sits to 1,000 is to count the address spaces yourself.
AWS raises the number of routes you may advertise; Azure reduces the number of routes you advertise. Both land in roughly the same place, and only one of them requires you to be right about your address plan before you commit.
What to do this week
Count first. If your hub advertises well under 1,000 prefixes today, summarisation buys you nothing and adds a failure mode. If you are above roughly 700 and growing, treat it as a design change rather than a property toggle.
The summary must cover the hub's own address space, or the hub stops being reachable from on-premises through that gateway. Verify the received routes on the on-premises router after the change, not the Azure-side configuration. And keep the reversion path documented: the property clears back to null, and the community lab reports that the original individual advertisements return when it does.
The real cost here is not the property. It is the address plan the property assumes you already have — a contiguous, non-overlapping allocation per hub that a summary can cleanly describe. Estates that grew by acquisition rarely have one, and no BGP feature will produce it for them.
India-specific considerations
Indian enterprises running ExpressRoute out of the Central India and South India regions typically land a single hub per region and peer both into a shared on-premises core, which doubles the advertised count against one set of on-premises route tables. Under the Digital Personal Data Protection Act 2023, data-residency designs push teams toward more virtual networks rather than fewer, and each additional environment is another set of prefixes against the same 1,000-prefix outbound ceiling. Summarisation helps only if the regional allocations were carved from a plan; retrofitting one after the fact means renumbering.
What is still unknown
Microsoft has not published a maximum length for the summarizedGatewayPrefixes list, has not documented VPN Gateway behaviour, and has not stated whether the property interacts with Azure Route Server beyond confirming that summarisation does not require it. The concept article and the Azure Networking blog post that introduced the feature both carry a last-modified date of 20 May 2026 and were not revised when the capability moved out of preview.
FAQ
How eCorpIT can help
Hub-and-spoke route counting is a landing-zone problem before it is a BGP problem, and it surfaces during migration rather than during design. Our Azure landing zone and Terraform IaC modernization work covers address-plan review, advertised-prefix inventory across hubs, and the module changes needed to set summarizedGatewayPrefixes on the hub alone rather than across every virtual network in the estate. Teams already mid-migration can pick this up as part of our cloud migration services, and the same review usually pairs with a Terraform AzureRM 5 upgrade. Talk to our senior engineering team through /contact-us/.
References
- Summarized Gateway Prefixes for Route Advertisement in Azure Virtual Networks, Azure Networking Blog
Last updated: 21 August 2026.
