AWS Transit Gateway: Scalability & Limits Explained
Published on · Updated on
Corrected route and attachment quota scope, added per-AZ bandwidth and packet rates, updated PMTUD behavior, and replaced generic monitoring and pricing claims.
AWS Transit Gateway scales across attachments, route tables, and Availability Zones. Its published maximums have different scopes and increase paths, and a quota or throughput figure is not a promise of end-to-end application performance. This article summarizes current AWS quota guidance and shows what to measure as a network grows. For route selection and segmentation, see AWS Transit Gateway route tables explained.
Unless a quota is marked otherwise, AWS lists Transit Gateway quotas by Region. Confirm the default and adjustment path for the account and Region you plan to use in the current Transit Gateway quotas page and Service Quotas before designing around a ceiling.
How Transit Gateway Scales
A transit gateway is a regional routing hub. You can add VPC, VPN, Direct Connect gateway, peering, and Connect attachments, and use multiple TGW route tables to apply different routing policies. Growth depends on the count and types of attachments, the number of routes installed across the gateway, and the traffic handled in each Availability Zone.
For a VPC attachment, select one subnet in each Availability Zone where workloads need to reach the TGW. Adding attachments or AZs can expand the available paths, but does not by itself guarantee a particular application throughput or latency.
Current Quotas to Plan Around
The table gives selected defaults from AWS's quota page. “Yes” means AWS lists the quota as adjustable through Service Quotas. Rows that say to contact a Solutions Architect or Technical Account Manager require assistance; that wording is not a promise that AWS will approve a higher value. “No” is a fixed quota in the published table.
| Quota | Default and scope | AWS increase path |
|---|---|---|
| Transit gateways per account | 5 per Region | Yes, Service Quotas |
| TGW route tables | 20 per transit gateway | Yes, Service Quotas |
| Static and dynamic routes | 10,000 combined across all route tables on one transit gateway | Contact your Solutions Architect or Technical Account Manager |
| Attachments | 5,000 total per transit gateway across supported attachment types | Yes, Service Quotas |
| Transit gateways per VPC | 5 per VPC | No |
| Peering attachments | 50 per transit gateway; one between two transit gateways or between a transit gateway and a Cloud WAN core network edge | 50 is adjustable; one per pair is fixed |
| Pending peering attachments | 10 per transit gateway | Yes, Service Quotas |
| Connect peers (GRE tunnels) | 4 per Connect attachment | No |
| Routes advertised from a virtual router appliance to a Connect peer | 1,000 per Connect peer | Contact your Solutions Architect or Technical Account Manager |
| Routes advertised from a Connect peer to a virtual router appliance | 5,000 per Connect peer | No |
| Static routes for one prefix to one attachment | 1 per prefix and attachment | No |
The 5,000 figure is a total attachment quota on each transit gateway, not a separate allowance for 5,000 VPCs. Every attachment on that TGW counts toward the same total, regardless of which AWS account owns it. AWS also permits no more than one VPC attachment from a particular VPC to the same TGW; a VPC can be attached to up to five transit gateways. Check the exact row scope before adding VPN, Direct Connect, Connect, or peering capacity to a VPC count.
The route ceiling is also easy to misread: 10,000 static and dynamic routes is the combined total across every route table on one transit gateway, not 10,000 routes in each table. Review route counts alongside the segmentation model before approaching that threshold.
Route Scale and Propagation
Route propagation can reduce manual updates for supported dynamic sources, but it does not change the total route quota. A VPC attachment contributes its VPC CIDR blocks; it does not import arbitrary VPC subnet-route entries. Transit Gateway peering uses static routes for remote prefixes. See the detailed guide to associations, propagation, and route selection before changing route tables to reduce route count.
For Connect, check both directions of the advertised-route limits. The 1,000-route figure is routes advertised from the virtual router appliance to the Connect peer; the 5,000-route figure is routes advertised from the Connect peer to the appliance. They are separate quotas, with different adjustment paths.
Attachment Types, Connect, and Peering
A Connect attachment and a peering attachment solve different problems. Transit Gateway Connect uses GRE tunnels and BGP between the TGW and a virtual appliance, such as an SD-WAN router, carried over an underlying VPC or Direct Connect gateway attachment. It allows up to four Connect peers per Connect attachment. Each peer is limited to up to 5 Gbps and 300,000 packets per second; AWS lists those peer limits as fixed. See AWS's Connect attachment documentation.
Peering connects two transit gateways, including across Regions. It is not a Connect tunnel, and it does not propagate routes between the two TGW route tables. Create static routes to the peering attachment on each side for the remote prefixes and their return paths. The quota page lists up to 100 Gbps in each direction and 7.5 million packets per second per available AZ for a peered transit gateway connection; those figures are scoped per AZ, not an end-to-end guarantee. AWS's TGW routing guide covers peering routes.
For a comparison of Direct Connect and Site-to-Site VPN attachment choices, see AWS Direct Connect vs. Site-to-Site VPN.
Bandwidth, Packets, and MTU
AWS publishes these throughput ceilings by attachment type and Availability Zone in the Transit Gateway quotas. Use them as planning limits, then measure the real path with representative traffic and both directions.
| Traffic scope | Published default | Increase path |
|---|---|---|
| VPC attachment, per AZ | Up to 100 Gbps ingress and 100 Gbps egress; up to 7,500,000 packets per second | Contact your Solutions Architect or Technical Account Manager |
| Direct Connect gateway or peered TGW connection, per available AZ | Up to 100 Gbps each direction; up to 7,500,000 packets per second per attachment | Contact your Solutions Architect or Technical Account Manager |
| Connect peer (GRE tunnel) | Up to 5 Gbps and 300,000 packets per second per peer | No; four peers are allowed per Connect attachment |
AWS may provide bandwidth above the published default for VPC, Direct Connect gateway, and peered TGW connections. That does not make the listed figure an application throughput guarantee. Packet size, traffic mix, routes, underlying transport, destination capacity, and AZ placement affect realized performance. Site-to-Site VPN tunnel throughput has its own constraints and varies with factors such as packet size, protocol, customer gateway, and network path; consult the VPN bandwidth and throughput guidance.
MTU and Path MTU Discovery
The Transit Gateway quota page lists an MTU of up to 8,500 bytes for traffic between VPCs, Direct Connect, Transit Gateway Connect, and peering attachments. It says traffic over VPN connections can have an MTU of 1,500 bytes. The separate Site-to-Site VPN tunnel quota is a maximum MTU of 1,446 bytes with a corresponding maximum TCP MSS of 1,406 bytes. AWS notes that tunnel settings can lower those values; account for IPsec encapsulation overhead and verify the configured tunnel MTU and MSS. These are limits documented at different service layers. When a path includes an AWS Site-to-Site VPN tunnel, use the actual tunnel limit as the more restrictive packet-size constraint. AWS also enforces TCP MSS clamping at the transit gateway.
PMTUD support depends on the ingress attachment. AWS documents PMTUD for traffic entering on VPC and Connect attachments, where the TGW can generate ICMPv4 “fragmentation needed” and ICMPv6 “Packet Too Big” messages. It does not support PMTUD for traffic entering on Site-to-Site VPN, Direct Connect, or peering attachments; the Site-to-Site VPN service also documents that its connection does not support PMTUD. If a path includes one of those attachment types, do not assume the TGW or VPN will signal the usable MTU; set and test packet sizes for the complete path. See the Transit Gateway quota documentation and Site-to-Site VPN quotas.
What CloudWatch Shows—and What It Does Not
Amazon VPC publishes Transit Gateway metrics to CloudWatch every 60 seconds in the AWS/TransitGateway namespace. Gateway and attachment metrics include bytes and packets in or out, plus drop counts for blackhole routes and destinations with no route. These signals help identify traffic changes and routing drops.
Only VPC attachments support per-AZ metrics. The published Transit Gateway metrics do not report route-table inventory or application latency. Track route and attachment counts from the VPC/EC2 APIs, configuration inventory, or your Infrastructure as Code state; use Service Quotas for quota details and increase requests. Measure latency from the workload path with application or host telemetry. AWS documents the available Transit Gateway CloudWatch metrics and dimensions.
For a diagnostic workflow that distinguishes CloudWatch metrics, Network Manager, Flow Logs, and route analysis, see AWS network dashboard troubleshooting.
Plan Capacity Before the Limit
- Count the right resources. Maintain separate counts for route tables, total TGW attachments by type, per-AZ traffic, and routes across all tables on each TGW.
- Leave operational headroom. Plan for new accounts, networks, routes, and failover paths instead of targeting a published maximum.
- Review increase paths early. Request adjustable quotas through Service Quotas; contact AWS account support for rows that require a Solutions Architect or Technical Account Manager. Fixed quotas have no increase path in the published table.
- Test realistic traffic. Measure both directions, expected packet sizes, and failover behavior. A per-AZ ceiling does not establish throughput across an entire application path.
- Keep cost and route design together. Route changes can alter attachment usage, traffic processing, and inter-Region transfer.
Transit Gateway Pricing
AWS charges attachment-hours and, for applicable attachment types, data processing; standard AWS data-transfer charges can also apply. Transit Gateway Connect data processing is charged through its underlying VPC or Direct Connect attachment rather than as an additional Connect processing charge. Site-to-Site VPN and inter-Region peering can involve separate charges, and the payer varies with attachment type and account ownership. Because rates depend on Region, traffic volume, attachment mix, and path, use the current AWS Transit Gateway pricing page and AWS Pricing Calculator for an estimate instead of relying on an old example amount.
Frequently Asked Questions
Is 100 Gbps the throughput for the whole transit gateway?
No. AWS lists up to 100 Gbps in each direction per VPC attachment per AZ and separately scopes Direct Connect gateway and peering values per available AZ. It is a published service quota, not guaranteed workload throughput.
Does a Connect attachment provide 20 Gbps?
It can have up to four peers, each with a published limit of up to 5 Gbps, so AWS states a total of up to 20 Gbps per Connect attachment when the underlying VPC or Direct Connect transport supports that bandwidth. This is an aggregate ceiling, not a throughput promise.
Does Transit Gateway support Path MTU Discovery?
For traffic entering through VPC and Connect attachments, yes. For Site-to-Site VPN, Direct Connect, and peering ingress, AWS does not support TGW PMTUD. Check the full path's MTU and test the packet sizes your applications send.