What Is a Transit Gateway?

A transit gateway is a cloud networking service that acts as a central hub connecting multiple virtual private clouds (VPCs) and on-premises networks. Instead of building a mesh of individual connections between every network, organizations attach each network to the transit gateway once, and the gateway routes traffic between them.

The term is most closely associated with AWS Transit Gateway, though the hub-and-spoke concept applies across cloud providers. As cloud footprints grow from a handful of VPCs to dozens or hundreds, transit gateways have become the standard way to keep connectivity manageable.

How a Transit Gateway Works (Hub-and-Spoke Model)

A transit gateway sits at the center of a hub-and-spoke topology. Each VPC, VPN connection, or dedicated link becomes a spoke attached to the hub. Traffic from one spoke to another flows through the gateway, which consults its route tables to decide where packets go.

The alternative, connecting every VPC to every other VPC directly, scales terribly: full-mesh peering between n networks requires n(n-1)/2 connections. Ten VPCs would need 45 peering links; with a transit gateway, they need 10 attachments. The hub model also centralizes route management, so adding an eleventh network means one new attachment rather than ten new peerings.

A hub-and-spoke topology connecting VPCs and on-premises networks through a central gateway.

Key Concepts: Attachments, Route Tables, and Peering

Attachments are the connections between the transit gateway and other networks: VPC attachments, VPN attachments, Direct Connect gateway attachments, and peering attachments to other transit gateways.
Route tables control how traffic flows between attachments. A transit gateway can maintain multiple route tables, which allows segmentation: production VPCs can be routed away from development VPCs even though both attach to the same hub.
Peering connects transit gateways to each other, typically across regions, so that a global network can be stitched together from regional hubs.

Transit Gateway vs. VPC Peering

VPC peering creates a direct, one-to-one connection between two VPCs. It is simple and has no per-hour hub cost, which makes it a good fit for a small number of stable connections. However, peering is non-transitive: VPC A peered with B, and B peered with C, does not give A a path to C.

A transit gateway is transitive by design and scales to thousands of attachments, at the cost of an hourly attachment fee and per-GB data processing charges. The practical rule: a few VPCs with simple needs can use peering; growing, segmented, or hybrid environments belong on a transit gateway.

Common Use Cases

Multi-VPC Connectivity

Organizations that separate workloads into many VPCs, whether per team, per application, or per environment, use a transit gateway to interconnect them centrally while enforcing segmentation through route tables.

Hybrid Cloud and On-Premises Integration

A transit gateway terminates VPN and Direct Connect links from corporate data centers, giving on-premises networks a single entry point into the entire cloud environment rather than separate connections into each VPC.

Cost Considerations

Transit gateway pricing has two main components: an hourly charge per attachment and a data processing fee per gigabyte that flows through the gateway. For high-throughput architectures, the data processing fee can dominate, so teams frequently model traffic patterns before migrating and keep chatty, high-volume flows on direct paths where appropriate.

Security Considerations for Transit Gateways

The security implications of centralizing routing receive far less attention than the connectivity benefits, and they deserve more.

Centralized Routing Risk

A transit gateway is a high-value chokepoint. A misconfigured route table can unintentionally connect networks that should never talk to each other, such as a partner-facing VPC and an internal database VPC. Because the hub touches everything, a single routing mistake propagates broadly, and an attacker who gains the ability to modify transit gateway configuration can reshape the entire network’s connectivity.

Encryption Control and Access Segmentation

Traffic between attachments is not encrypted by the gateway itself; encryption depends on the workloads and tunnels around it. Sensitive flows should use TLS or IPSec end to end. Equally important is strict IAM control over who can create attachments and modify route tables, combined with multiple route tables to enforce segmentation domains, so that “attached to the hub” never silently means “able to reach everything on the hub.”

Best Practices for Deploying a Transit Gateway Securely

Use separate route tables to segment environments (production, development, partner, shared services) and deny cross-domain routes by default.
Restrict transit gateway administration with tightly scoped IAM policies and require approval workflows for route changes.
Enable flow logging on the gateway and feed it to your SIEM to detect unexpected inter-VPC traffic.
Route inter-network traffic through inspection VPCs with firewalls where policy requires it.
Encrypt sensitive traffic end to end rather than relying on network position.
Review attachments periodically and remove unused ones, since every attachment is a potential path.

FAQ

Is a transit gateway an AWS-only concept?

AWS popularized the term, and most documentation refers to AWS Transit Gateway. Other clouds offer equivalent hub-and-spoke services, such as Azure Virtual WAN, built on the same model.

When should I use a transit gateway instead of VPC peering?

When you have more than a handful of VPCs, need transitive routing, connect on-premises networks, or want centralized segmentation. Peering remains fine for a small number of direct, stable connections.

Does a transit gateway encrypt traffic?

No. It routes traffic between attachments. Encryption must be handled by the connections and workloads themselves, for example IPSec VPN attachments or TLS between services.