What Is a Transit VPC and When Do You Need One?

A transit virtual private cloud (VPC) is a hub network that other VPCs and on-premises sites connect to, so they can reach each other through one central point instead of many pairwise links. Managed transit services now cover most of this need, with route tables and attachments instead of self-run routers.

What problem does a hub solve?

Imagine ten VPCs that all need to talk to each other and to an office. Connecting each pair directly means 45 links among the VPCs alone, each with its own routes to maintain. Adding an eleventh VPC means ten more.

A hub changes the shape. Each network connects once, to the hub, and the hub decides who can reach whom. That is easier to reason about and to inspect, because traffic flows through one place where you can apply policy and logging.

What does the cloud provider's current approach look like?

AWS documentation describes AWS Transit Gateway as a network transit hub used to interconnect virtual private clouds and on-premises networks. Its key concepts show how the hub model works in practice:

• Attachments: you can attach VPCs, VPN connections, Direct Connect gateways, SD-WAN or third-party appliances, peering connections to other transit gateways and Client VPN endpoints.
• Route tables: a transit gateway has a default route table and can have additional ones. Routes decide the next hop by destination address.
• Associations: each attachment is associated with exactly one route table, and a route table can have many attachments.
• Route propagation: VPCs, VPN connections and Direct Connect gateways can propagate routes dynamically, while some attachment types need static routes.
• Encryption control: a transit gateway can be configured to enforce encryption in transit for traffic on attached VPCs.

Billing follows attachments and traffic processed, per the same documentation, so a hub has a running cost that grows with usage. Check the current pricing page for your region.

The older pattern, often called a transit VPC, built the hub from virtual router instances you ran yourself inside a VPC. That gave flexibility, such as inspecting traffic with third-party appliances, but it meant you operated, patched and scaled the routers. The managed gateway moved that burden to the provider, and it can still attach appliances for inspection.

What do route tables have to do with security?

Everything. Separate route tables are how you stop a hub from becoming a flat network. NIST SP 800-53 SC-7 asks you to monitor and control communications at key internal managed interfaces and to implement subnetworks that separate public components from internal networks. AC-4 asks you to enforce approved information flows between connected systems.

A constructed example. A company has production, development and shared services VPCs. All three attach to one hub. Production and development are associated with different route tables. Both can reach shared services, such as DNS and logging, but there is no route between production and development. A developer's compromised test VPC cannot reach production databases because the route does not exist.

Without that separation, the default route table would let every attached network see every other, and the hub would turn a small breach into a large one.

What are the common mistakes?

• Using the default route table for everything, which creates one big routing domain.
• Propagating routes from untrusted networks, such as a partner VPN, into the same table as production.
• Forgetting that spokes may need return routes, which leads to one-way failures that look like firewall problems.
• Having no inspection point for traffic that crosses trust zones.
• Not logging who changes routes and attachments.

How to check or apply this

1. Count your VPCs and sites, and list which pairs truly need connectivity.
2. Group them into trust zones, such as production, development, shared services and partners.
3. Give each zone its own route table and associate attachments accordingly.
4. Add routes deliberately rather than relying on automatic propagation across zones.
5. Place inspection or firewall appliances where traffic crosses zones, and send flow logs to central storage.
6. Restrict who may create attachments or change route tables, and alert on changes.
7. Estimate attachment and data processing costs, and compare with simpler peering if you have only two or three networks.
8. Review the whole design after each acquisition, new partner or new region.

Quick check

Sources

• AWS, What is AWS Transit Gateway for Amazon VPC?
• NIST SP 800-53 Rev. 5 control catalog, OSCAL JSON from NIST (SC-7, AC-4)

Last reviewed: 18 October 2026.