A transit gateway is a managed regional network hub that interconnects many virtual private clouds, VPN connections and dedicated on-premises links through a single routing point. In cloud networking it replaces a dense mesh of pairwise connections with a hub-and-spoke topology, so each network attaches once and routing policy is managed centrally.
The term is most closely associated with AWS Transit Gateway, but the same pattern exists on other platforms, for example Azure Virtual WAN hubs and Network Connectivity Center in Google Cloud. In the Cloud subject a transit gateway is the standard answer once an organization grows beyond a handful of VPCs and VPC peering becomes hard to manage.
How a transit gateway routes traffic
Each network joins the hub through an attachment. A VPC attachment places an elastic network interface in one subnet per availability zone, and traffic from that VPC is sent to the hub by a route in the VPC route table that points at the transit gateway. The hub then forwards the packet according to its own routing tables.
The core mechanism is the separation of association and propagation. An attachment is associated with exactly one transit gateway route table, which decides where its outbound traffic goes. Attachments can propagate their prefixes into one or more route tables, which decides who can reach them. Combining these two controls creates segmented networks on one shared hub.
The following table lists the attachment types that a typical transit gateway supports.
| Attachment type | Connects | Routing method |
|---|---|---|
| VPC attachment | A virtual private cloud in the same region | Static or propagated VPC CIDR |
| Site-to-site VPN | On-premises routers over IPsec tunnels | Static routes or BGP |
| Dedicated link | Private circuit through a cloud interconnect service | BGP |
| Peering attachment | Another transit gateway, often in a different region | Static routes |
| Connect attachment | Virtual appliances such as SD-WAN routers | GRE tunnels with BGP |
Transit gateway compared with VPC peering
VPC peering links exactly two networks and is non-transitive, so traffic cannot pass through one peered VPC to reach a third. With n networks a full mesh needs n(n-1)/2 peering connections, which is 45 for 10 VPCs and 190 for 20. A transit gateway needs only one attachment per network.
| Criterion | VPC peering | Transit gateway | VPN gateway per VPC |
|---|---|---|---|
| Topology | Point-to-point | Hub and spoke | Point-to-site or site-to-site |
| Transitive routing | No | Yes, controlled by route tables | No |
| Scale | Manageable for a few VPCs | Thousands of attachments | One gateway per VPC |
| Data processing charge | None within a region | Charged per gigabyte | Charged by the hour and per tunnel |
| Central inspection | Not possible | Possible through an inspection VPC | Limited |
The trade-off is cost and an extra hop. Peering has no per-gigabyte processing fee inside a region, so chatty pairs of VPCs with heavy traffic are sometimes peered directly even when a transit gateway exists for everything else.
Key parameters and limits
Several settings shape how a transit gateway behaves and what it costs. Exact quotas differ by provider and change over time, so the values below describe typical AWS defaults and should be verified against current service limits before a design is finalized.
| Parameter | Typical value or option | What it affects |
|---|---|---|
| Bandwidth per VPC attachment | Up to about 50 Gbps burst | Throughput for large data flows |
| Bandwidth per VPN tunnel | About 1.25 Gbps | Need for ECMP across several tunnels |
| Private ASN | 64512 to 65534 or a 4-byte range | BGP sessions with on-premises routers |
| Default route table association | Enabled or disabled | Whether new attachments join a flat network |
| Appliance mode | Enabled per attachment | Symmetric routing through stateful firewalls |
| Maximum transmission unit | 8500 bytes for VPC traffic, 1500 for VPN | Fragmentation and throughput |
Equal-cost multipath (ECMP) over several VPN tunnels lets hybrid links exceed the single-tunnel limit. Appliance mode is essential when traffic passes through stateful firewalls in an inspection VPC, because without it the two directions of a flow can land in different availability zones and be dropped.
Common designs and pitfalls
Most enterprise landing zones use one of a few established patterns. The segmented hub keeps production, non-production and shared services in separate route tables, while a centralized egress VPC hosts the NAT gateways and internet gateway for all spokes, which reduces duplicated NAT costs.
Multi-region designs place one transit gateway in each region and join them with peering attachments. Because these inter-region peerings use static routes only, each region’s route tables must list the remote prefixes explicitly, and summarizing address space per region keeps those lists short. Traffic between regions also incurs inter-region data transfer charges on top of the hub’s processing fee, so latency-sensitive or high-volume flows deserve a deliberate placement decision.
Ownership is another design question. In a multi-account organization the hub usually lives in a dedicated network account and is shared with application accounts through a resource sharing service, so application teams can create attachments while route tables remain under central control.
- Leaving default association enabled lets every new attachment reach every other network, which defeats segmentation.
- Overlapping CIDR blocks cannot be routed through the hub, so IP address planning must come first.
- Forgetting the VPC-side routes is the most common reason a new attachment appears healthy but carries no traffic.
- Ignoring data processing charges can make a hub surprisingly expensive for high-volume replication traffic.
- Asymmetric routing through firewalls without appliance mode causes intermittent connection resets.
Troubleshooting usually starts with VPC flow logs and the transit gateway’s own flow logs, then a route analysis tool that traces the path from source to destination through each route table.
A plain-language summary
Imagine a company with dozens of separate office buildings. Building a private road between every pair of buildings would create a tangle of roads. A transit gateway is like one central interchange: every building gets a single road to it, and the interchange decides which traffic may go where.
In the cloud, the buildings are private networks and the interchange is a managed service. The result is fewer connections, simpler rules and one place to control traffic between networks and the company’s own data centers.
An example from practice
A retail company running on AWS had grown to 30 VPCs across several accounts, linked by more than a hundred peering connections and separate VPN tunnels to two data centers. Adding a new application meant updating many route tables by hand, and auditors could not easily confirm that test systems were isolated from payment systems.
The network team deployed one transit gateway per region with three route tables: production, non-production and shared services. On-premises sites connected through BGP over a dedicated link, and all internet-bound traffic was routed through a central inspection VPC with appliance mode enabled. Onboarding a new VPC became a single attachment and one route table association, and the isolation between payment and test environments could be demonstrated directly from the route tables.