- Newest
- Most votes
- Most comments
There are separate limits for each direction, and they behave very differently. Mixing them up is the usual root cause.
1. On-premises → AWS (routes you advertise into AWS)
- Routes per BGP session on a private VIF or transit VIF, from on-premises to AWS: default 100 each for IPv4 and IPv6 — note each, not a combined total.
- This is adjustable. It can be increased using prefix controls, up to 1,000 each for IPv4 and IPv6.
- What happens when you exceed it: "If you advertise more route prefixes than your configured allocations for IPv4 and IPv6 over the BGP session, the BGP session will go into an idle state and be reported with BGP session status DOWN." That is the failure you observed — and AWS does not proactively notify you as you approach the limit.
- For contrast, a public VIF allows 1,000 routes per BGP session and that limit cannot be increased.
Monitor this. Because there is no built-in alert, set up your own alarm on the advertised prefix count so you are warned before you cross the threshold rather than after the session drops.
2. AWS → on-premises (what AWS advertises out)
- Per Transit Gateway, on a transit VIF: 200 prefixes, combined total for IPv4 and IPv6.
- AWS Cloud WAN core network Direct Connect gateway attachment: up to 5,000 advertised route prefixes to on-premises (adjustable). Note that all transit VIFs attached to that Direct Connect gateway receive all route prefixes advertised by the core network.
That 200 vs 5,000 difference is a genuine architectural input if you are choosing between a Transit Gateway and a Cloud WAN core network for a large, prefix-heavy hybrid network.
3. Summarize — do not enumerate
The allowed-prefixes list is where you control the AWS → on-premises direction, and its semantics differ by gateway type:
- Transit Gateway association: only the prefixes you enter are advertised on-premises, and they appear as originating from the Direct Connect gateway ASN. AWS provisions exactly what is in the list, so a VPC CIDR that is not covered is simply not advertised.
- Virtual private gateway association: the list acts as a filter allowing the same or smaller CIDRs. You must set it to a range that is the same as or wider than the VPC CIDR, because the entire VPC CIDR is provisioned on the virtual private gateway.
Worked example with VPCs 10.77.0.0/16, 10.66.0.0/16, and 192.168.0.0/16 behind a Transit Gateway:
| Allowed prefixes | What on-premises receives |
|---|---|
10.0.0.0/8, 192.168.0.0/16 | 10.0.0.0/8 and 192.168.0.0/16 — 2 prefixes instead of 3, and it scales as you add VPCs inside those ranges |
10.0.0.0/8, 192.168.5.0/24 | 10.0.0.0/8 and 192.168.5.0/24 — you do not receive 192.168.0.0/16, so that VPC is unreachable |
0.0.0.0/0 only | only the default route 0.0.0.0/0 |
When your BGP session on a Direct Connect transit VIF goes to idle after adding more VPCs, you've exceeded the allocated prefix count for that virtual interface. By default, each VIF is allocated 200 prefixes per address family (IPv4 and IPv6). When the number of prefixes advertised on a VIF exceeds the allocated count, the BGP session goes down and enters an idle state.
With Direct Connect's inbound prefix controls, you can now allocate up to 1,000 prefixes per address family on a single transit VIF, which should accommodate your growing number of VPCs. The prefix allocation draws from two capacity pools: your dedicated connection's pool (which scales based on connection speed) and your Direct Connect gateway's pool (which has a total limit of 10,000 prefixes shared across all attached VIFs, with a maximum of 30 VIF attachments).
To prevent this from happening again, you have several options:
-
Increase the prefix allocation on your existing transit VIF to accommodate current and anticipated growth. You can do this through the AWS Direct Connect console or CLI/API. The new allocation takes effect immediately as long as you're not currently exceeding it.
-
Summarize or aggregate your VPC routes into larger CIDR blocks before advertising them. For example, instead of advertising many individual /24 routes, combine them into fewer, larger blocks like /16 routes.
-
Monitor your prefix usage proactively. You can view your connection's prefix pool size, allocated prefixes, and unallocated prefixes through the console or describe-connections command to ensure you have sufficient capacity before onboarding new VPCs.
-
If you're using a Link Aggregation Group (LAG), note that the prefix pool scales with the number of active member connections, providing additional capacity.
The key is to ensure your allocation is at least as large as the number of prefixes you plan to advertise, with some headroom for growth.
Sources
Inbound prefix controls for Direct Connect - AWS Direct Connect
Managing prefix allocations for Direct Connect virtual interfaces - AWS Direct Connect
AWS Direct Connect introduces inbound prefix controls and higher prefix scale - AWS
answered a month ago
Relevant content
asked 5 years ago
asked 2 years ago
asked 6 years ago
