Three AWS networking limits that changed shape, not just value

Stale quotas are a known hazard, and the usual advice is to check the current docs. That advice is incomplete. The expensive failures are not the ones where a number got bigger. They are the ones where the limit stopped being the same kind of thing — a total became a per-destination budget, one number became two with different adjustability, a hard ceiling became an allocation you configure and can overrun into an outage.

In each of those cases, recalling the old number correctly still lands you on the wrong design. You reach for more instances of the wrong resource, or you file a quota increase for something that cannot be increased, or you assume graceful degradation where there is none.

Three that come up constantly in review, each verified against the current documentation.

NAT Gateway's 55,000 connections is per destination, not per gateway#

The number most people carry is "55,000 simultaneous connections per NAT Gateway." The documentation is more specific:

Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination.

A unique destination is a combination of destination IP address, destination port, and protocol. That changes the arithmetic in both directions, which is why the scalar version misleads so reliably.

If your egress fans out across many destinations — a few thousand distinct API hosts, package mirrors, webhook endpoints — each destination carries its own 55,000 budget. Your real ceiling is far above 55,000, and a second NAT Gateway added "for connection headroom" bought you nothing but an hourly charge and a second set of route table entries to keep straight.

If your egress concentrates on one destination — a single third-party API behind one address on 443, one managed database endpoint — you hit 55,000 on that tuple while the gateway is otherwise idle. No amount of aggregate headroom helps, because the budget is not shared.

The design consequence is the part the scalar hides. When you exhaust a single destination's budget, the lever is more IPv4 addresses on the same NAT Gateway, not more NAT Gateways. A NAT Gateway supports up to 8 IPv4 addresses (one primary and seven secondary), and each address gets its own per-destination budget. Note that a public NAT Gateway is capped at 2 Elastic IPs by default and needs a quota increase to go past that.

The mechanics of how ports get consumed, and the separate 350-second idle timeout that makes long-lived connections fail in a way that looks like packet loss, are covered in the NAT Gateway guide.

Route tables have two route limits, and the one that binds cannot be raised#

"50 routes per route table" is a figure with real staying power. The current quotas are two separate numbers:

• Non-propagated routes: 500, adjustable up to 1,000, and enforced separately for IPv4 and IPv6.
• Propagated routes: 100, marked not adjustable.

The gap between them is the whole story. In a hybrid design, the routes arriving from on-premises through virtual private gateway propagation land in the propagated bucket. That is the bucket capped at 100, and it is the one you cannot open with a support case.

So a team that discovers it is advertising 140 prefixes from the data centre has exactly two real options: summarize on the customer gateway so fewer, larger prefixes arrive, or move the termination to a Transit Gateway and manage the route table yourself. Filing a quota increase is not on the list, and finding that out after the change window has opened is a bad time to learn it.

One operational aside from the same page: past 125 routes, AWS recommends paginating your describe-route-tables calls. If you have automation that reconciles route tables and assumes a single response page, it will quietly start seeing a truncated view of reality right around the point your routing gets complicated enough to need the automation.

The quota as a design constraint — how it interacts with per-AZ route tables and how to plan address space so you never approach it — is in the VPC guide.

Direct Connect's prefix limit is now an allocation you set, and overrunning it drops BGP#

This is the one where the shape change is most complete. The old model was a fixed inbound prefix ceiling per virtual interface. The current model is inbound prefix controls: capacity pools with allocations you assign per VIF.

The numbers that matter:

| Scope | Value | | --- | --- | | Default allocation per VIF | 100 per address family | | Maximum allocation per VIF | 1,000 per address family | | Pool per dedicated connection | 5,000 (1/10 Gbps), 30,000 (100 Gbps), 50,000 (400 Gbps) | | Total allocations per Direct Connect gateway | 10,000, combined IPv4 and IPv6 | | VIF attachments per Direct Connect gateway | 30 |

You can now have a transit VIF allocated 1,000 prefixes alongside a private VIF allocated 50, on the same connection. If you set nothing, you get 100 per address family — which means a VIF you provisioned without thinking about prefixes has a limit you did not choose.

The sharp edge is the failure behaviour, and it is worth reading the documentation's own wording:

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.

That is not "extra prefixes are ignored" and not "the newest advertisement is dropped." Advertising one prefix past your allocation takes the session down, so the blast radius is every prefix on that VIF, not the marginal one. A routine on-premises route summarization change that accidentally deaggregates is enough to do it.

Public VIFs sit outside this model entirely and keep the existing 1,000 inbound prefix limit, which is a reasonable thing to get wrong if you are reading quickly.

The BGP-side view of this — why the session going idle is harder to diagnose than a link failure, and how hold timers and BFD change how long you spend not knowing — is in the hybrid connectivity guide.

The pattern worth taking away#

All three follow the same shape. A limit that used to be one scalar is now either scoped more narrowly (NAT Gateway, per destination), split into pieces with different rules (route tables, propagated versus not), or turned into a configurable allocation with an unforgiving overrun behaviour (Direct Connect).

None of these are obscure services. They are the three things a hybrid AWS network is built out of. The reason the old numbers persist is that they are close enough to work right up until the moment your design depends on them, which is exactly when you have the least time to re-read a quotas page.

Two concrete habits are worth more than memorizing the current values, because the current values will also drift:

Check adjustability, not just the number. "500, adjustable to 1,000" and "100, not adjustable" are different kinds of fact, and only one of them can be solved with a support case at 2am.

Check the overrun behaviour. Whether exceeding a limit degrades, drops the marginal request, or tears down a session is the difference between a warning and an outage, and it is rarely the thing people remember.

If you want to see the propagated-route limit and the propagation-is-opt-in behaviour cause a real failure rather than reading about them, the Transit Gateway propagation lab and the VPN route propagation lab both start from a working-looking configuration and make you find it.