Direct Connect prefix limit rose to 1,000 on 20 August 2026 - your VIFs still default to 100

Summary. On 20 August 2026 AWS announced inbound prefix controls for Direct Connect, raising the number of on-premises routes a private or transit virtual interface can accept from 100 to 1,000 per address family. The price of the capability is $0: AWS says it is "available at no additional cost" in all commercial Regions, both GovCloud Regions, and the two China Regions. What did not move is the default. Every existing VIF and every new VIF still starts at 100 prefixes per address family unless you set the allocation yourself. What also did not move is the other direction: AWS still advertises a maximum of 200 prefixes combined across IPv4 and IPv6 from a Transit Gateway to on-premises on a transit VIF. Azure ExpressRoute, meanwhile, accepts 4,000 IPv4 routes on Standard and 10,000 on Premium, but caps IPv6 at 100 on both tiers and caps gateway-advertised routes at 1,000. Two hyperscalers, the same BGP scale problem, and answers that point in opposite directions.

What AWS changed

The AWS announcement is dated 20 August 2026 and is short. Inbound prefix controls let you "allocate and manage inbound route-prefix allocations" for private and transit VIFs on dedicated and hosted connections, up to 1,000 prefixes each for IPv4 and IPv6.

Before this, the Direct Connect quotas page enforced a flat 100 routes per BGP session on a private or transit VIF. AWS's own framing of the workaround is worth reading closely, because it is the architecture most large hybrid estates are already running: "If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections."

The mechanism is allocation, not a raised ceiling. The user guide describes capacity pools at two levels - the dedicated connection and the Direct Connect gateway - and you draw from both when you attach a VIF. Public VIFs are outside the scheme entirely and keep their existing limit of 1,000 inbound prefixes.

The default did not move, and that is the part that bites

Read this line from the user guide twice: "If you don't select any value, AWS applies the default allocation of 100 prefixes per address family."

Nothing about a running estate improved on 20 August 2026. The ceiling you can ask for went up tenfold. The number your VIFs are actually configured with did not change at all.

To move, you set prefixPoolAllocatedCountIpv4 and prefixPoolAllocatedCountIpv6 on the VIF. The prefix allocations page gives the CLI form:

            aws directconnect update-virtual-interface-attributes \
    --virtual-interface-id dxvif-abc12345 \
    --prefix-pool-allocated-count-ipv4 500 \
    --prefix-pool-allocated-count-ipv6 100
          

The change "takes effect immediately" and the BGP session stays up as long as advertised prefixes do not exceed the new allocation. Reductions are guarded: "The API rejects requests to reduce an allocation below the number of prefixes currently in use on the VIF."

The return path is still 200, and that is the direction most estates blow up on

Raising inbound capacity does nothing for what AWS sends you. The quotas page still lists 200 combined IPv4 and IPv6 as the number of prefixes a Transit Gateway advertises to on-premises on a transit VIF. A Cloud WAN core network attachment goes to 5,000, but that is a different product on a different attachment.

What fills those 200 slots is the allowed prefixes list on the Direct Connect gateway, and it behaves differently by gateway type. AWS documents that for a Transit Gateway association "only the allowed prefixes entered will be advertised to on-premises", originating from the Direct Connect gateway ASN - so the list is the advertisement, not a filter over it. For a virtual private gateway the same list is a filter, and a narrower entry silently yields nothing: with a VPC on 10.0.0.0/16, an allowed list of 10.0.0.0/24 returns no route at all, while 10.0.0.0/15 returns 10.0.0.0/16. Teams that summarise on the AWS side to fit under 200 hit this asymmetry first.

Put the two clouds side by side by direction and the mismatch is obvious.

The Azure figures come from the route advertisement table in the ExpressRoute FAQ, which is explicit that Premium lifts only one row: "Increased routing table limit from 4000 routes to 10,000 routes for private peering." IPv6 stays at 100 on both SKUs. Gateway-advertised routes stay at 1,000 IPv4 and 100 IPv6 on both SKUs.

So the honest reading of 20 August is narrower than the headline. On IPv4 inbound, AWS closed part of a gap it was losing by 40 to 1 and is now losing by 4 to 1. On IPv6 inbound, AWS went from parity with Azure to 10 times Azure's ceiling, and Azure's Premium tier does not fix it. On the cloud-to-on-premises direction, AWS is still five times tighter than Azure on IPv4.

Azure went the other way: advertise fewer routes, not accept more

Microsoft's answer to the same pressure is summarizedGatewayPrefixes, a virtual network property documented in Advertised gateway prefixes in Azure virtual networks. Instead of raising a limit, it reduces what crosses the link: set a covering CIDR on the hub and Azure "ignore[s] the address space of the virtual network with the gateway (hub) and publish[es] the summarized prefixes instead", suppressing every peered spoke whose address space the summary covers.

Microsoft names the trigger condition directly - use it when "You're approaching ExpressRoute advertised-prefix limits (for example, 1,000 IPv4 prefixes and 100 IPv6 prefixes)". The ExpressRoute FAQ gives the arithmetic that gets teams there: a hub with one address space and 500 spokes using Allow Remote Gateway "advertises 501 prefixes to on-premises".

Three constraints on the Azure side that the overview page states and that are easy to miss. The property is read only on the hub - "If you set this property on spoke (peered) virtual networks, it's ignored." Overlapping prefixes inside the list are not allowed. And the summary must include the gateway virtual network's own address space, or you have removed the hub from the advertisement. The portal how-to adds one more for dual-stack estates: "For dual-stack (IPv4 + IPv6) virtual networks, add both IPv4 and IPv6 summarized prefixes explicitly."

The two failure modes read the same and behave differently

This is the part the announcements do not compare, and it decides how bad a bad day gets.

AWS states the consequence twice in the same words. From the user guide: "If the number of prefixes advertised on a VIF exceeds the allocated count, the BGP session on that VIF will go down and enter an idle state (BGP DOWN)." The troubleshooting section prescribes a manual fix - "Increase the allocation by using the UpdateVirtualInterfaceAttributes API or the console." Neither AWS page states that the session recovers on its own once the prefix count falls back under the allocation.

Azure states recovery explicitly, at both layers. For the BGP route limit: "BGP sessions disconnect. BGP sessions are restored once the prefix count gets below the limit." For the connection prefix limit: "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."

Same trigger, documented differently. If you are writing a runbook, do not assume AWS behaves like Azure here. Assume an operator action is required and prove otherwise in a test window.

There is a second, quieter failure mode on the Azure side. Summarization suppresses covered spokes from advertisement, so a spoke that is inside your summary but not actually reachable becomes a black hole rather than an unreachable route. AWS's failure is loud - the session drops. Azure's is silent - traffic leaves and is discarded. The loud one is easier to operate.

The pools you will hit before you reach 1,000

The 1,000 figure is a per-VIF cap, not a budget. Three other numbers sit above it.

Ten VIFs at the full 1,000 IPv4 allocation exhaust a Direct Connect gateway exactly - AWS gives that as its own worked example. And one note in the user guide will surprise anyone running a hybrid interconnect: "AWS Interconnect connections consume 2,000 prefixes from the 10,000 per-DXGW allocation limit." That is a fifth of the gateway budget gone before you allocate anything.

Link aggregation groups scale with billable members, and the guardrail runs backwards from what you expect: you cannot remove a LAG member if doing so would drop the pool below the total already allocated across that LAG's VIFs. Shrink the allocations first, then the LAG.

How to tell if this is you

Four checks, in order.

1. Count what your on-premises edge actually advertises per VIF today. If any VIF is near 100 on either address family, you have been living on the old ceiling and probably have a summarization workaround in place.

1. Count what you need AWS to advertise back. If that number is above 200 on a transit VIF, nothing announced on 20 August helps you, and route summarization on the AWS side remains mandatory.

1. Check IPv6 separately. Dual-stack estates that summarized IPv6 to stay under 100 on AWS can now stop; the same estates on Azure cannot, because 100 is still the ExpressRoute IPv6 ceiling on Premium.

1. Add up allocations per Direct Connect gateway, including 2,000 for any AWS Interconnect attachment, and confirm the total sits under 10,000 with room for the next attachment.

AWS shipped the tooling for step 1 three weeks earlier. BGP route visibility, announced 30 July 2026, exposes accepted and advertised routes with AS path and community values through the console and the ListVirtualInterfaceRoutes API. Use it before you set an allocation, not after a session drops.

The real cost of this change is not the $0 on the bill. It is the review of every VIF, every gateway budget and every summarization workaround that was built to survive the old ceiling and now silently constrains the new one. Teams running an Azure landing zone with Terraform already have the hub-and-spoke inventory this audit needs; teams mid-cloud migration usually do not, and that is where the 100-prefix default quietly becomes a cutover blocker.

What is still unknown

Three things the documentation does not settle. AWS does not state whether a BGP session that entered the idle state recovers automatically once advertised prefixes fall back under the allocation. AWS does not publish a figure for how long an allocation change takes to propagate beyond "immediately". And Microsoft's advertised gateway prefixes overview page carries a last-updated date of 20 May 2026, which predates the August update feed entry describing the feature as generally available - so treat the GA status as unconfirmed by the documentation until the Learn page is refreshed.

India-specific considerations

Indian enterprises running hybrid links out of Mumbai and Hyderabad regions face the same ceilings, with two local wrinkles. Multi-region estates that terminate on a single Direct Connect gateway hit the 10,000 combined allocation faster than single-region ones, because each region's transit VIF draws from the same gateway budget. And BFSI workloads under Digital Personal Data Protection Act 2023 data-residency requirements often segment aggressively by entity, which multiplies VIF count - and the 30-VIF-per-gateway cap, not the prefix count, is usually what binds first in that design.

FAQ

How eCorpIT can help

eCorpIT's senior engineering teams audit hybrid connectivity as part of cloud migration and landing-zone work, mapping every virtual interface, prefix allocation and gateway budget against the limits above before a cutover exposes them. We are an ISO 27001:2022 certified, CMMI Level 5 organisation and an AWS and Microsoft partner, and we design network architectures aligned with Digital Personal Data Protection Act 2023 residency requirements. If your hybrid estate has been architected around a 100-prefix ceiling, talk to us about what changes now.

References

1. AWS Direct Connect introduces inbound prefix controls and higher prefix scale - AWS What's New, 20 August 2026

1. Inbound prefix controls for Direct Connect - AWS Direct Connect User Guide

1. Managing prefix allocations for Direct Connect virtual interfaces - AWS Direct Connect User Guide

1. Direct Connect quotas - AWS Direct Connect User Guide

1. AWS Direct Connect now supports BGP route visibility on Virtual Interfaces - AWS What's New, 30 July 2026

1. Allowed prefixes interactions for Direct Connect gateways - AWS Direct Connect User Guide

1. Example: Allowed to prefixes in a transit gateway configuration - AWS Direct Connect User Guide

1. Advertised gateway prefixes in Azure virtual networks - Microsoft Learn

1. Configure advertised gateway prefixes for a virtual network using the Azure portal - Microsoft Learn

1. ExpressRoute FAQ - Microsoft Learn

Last updated: 21 August 2026.