Skip to content
AWS aws networking 6 min read

Transit Gateway

When you have two VPCs (Virtual Private Clouds — your own isolated networks inside AWS) and want them to talk to each other, you just create a peering connection between them. But the moment you have five, ten, or fifty VPCs, plus a few on-premises offices over VPN, peering turns into a nightmare of point-to-point links that you have to manage by hand. A Transit Gateway (TGW) fixes this: it is a single regional router that everything connects to, so traffic flows through one central hub instead of a tangled mesh of direct links.

What a Transit Gateway is

A Transit Gateway is a managed, regional hub-and-spoke router. Each network — a VPC, a VPN connection, a Direct Connect link, or even another Transit Gateway in a different region — attaches to the hub once. After that, the hub can route traffic between any of those attached networks. You build it once, attach your spokes, and the TGW does the forwarding.

The big difference from VPC peering is that a Transit Gateway is transitive. With peering, if VPC A peers with B, and B peers with C, A still cannot reach C — peering does not forward through the middle. With a Transit Gateway, A, B, and C all attach to the same hub, and any of them can reach any other (subject to your route tables). One hub replaces what would otherwise be a web of individual peering links.

Connecting N VPCs with peering needs up to N × (N − 1) / 2 connections — 10 VPCs means 45 separate links to manage. A Transit Gateway needs just N attachments, all pointing at one hub.

When to use this (and when not to)

  • Use a Transit Gateway when you have many VPCs (roughly four or more), or a growing number, especially mixed with VPN / Direct Connect to on-premises networks. It centralises routing, scales cleanly, and supports transitive traffic.
  • Do not use a Transit Gateway for just two VPCs. Plain VPC peering is cheaper (no hourly hub charge, no per-attachment fee), simpler, and has no extra latency hop.
  • Do not use it as a blanket “connect everything to everything” — segment with route tables (below) so, for example, your dev VPCs cannot reach production.

Attachments and route tables

Two concepts do all the work in a Transit Gateway.

Attachments are how a network connects to the hub. The common types are a VPC attachment (you pick one subnet per Availability Zone in the VPC, and the TGW places an interface there), a VPN attachment, a Direct Connect gateway attachment, and a peering attachment to a TGW in another region. Each attachment is the “spoke” plugged into the hub.

Transit Gateway route tables decide which attachments can talk to which. This is separate from your VPC subnet route tables — the TGW has its own routing layer. By default everything can reach everything, but you create multiple TGW route tables and associate each attachment with one, then control which routes propagate into it. This is how you build network segmentation: put production attachments on one route table and dev on another so the two groups stay isolated.

You also still need routes inside each VPC. In every VPC’s subnet route table, you add a route sending the other networks’ CIDR blocks (a CIDR, or Classless Inter-Domain Routing block, is an IP range like 10.1.0.0/16) to the Transit Gateway. Routing is therefore done in two places: the VPC route table points traffic at the TGW, and the TGW route table decides where it goes from there.

Transit Gateway vs VPC peering vs VPN mesh

Transit GatewayVPC peeringManual VPN mesh
TopologyHub-and-spoke (one hub)Point-to-point linksPoint-to-point tunnels
Transitive routingYesNoNo
Scales to many networksYes, easilyPainful past a handfulPainful
On-premises (VPN / DX)Built inNo (peering is VPC-only)Yes, but you manage each
CostHourly per attachment + per-GBFree hourly; cross-AZ data onlyPer VPN tunnel + data
Extra latencySmall hop through the hubNone (direct)Tunnel overhead
Best forMany VPCs + hybridExactly 2 VPCsLegacy / specific needs

Create a Transit Gateway — console

  1. Open the VPC console and choose Transit gateways in the left menu.
  2. Click Create transit gateway. Give it a Name tag (for example, tgw-core).
  3. Leave Default route table association and Default route table propagation enabled for a simple “everything talks to everything” setup (disable them later when you want segmentation).
  4. Click Create transit gateway and wait until its State becomes Available (a few minutes).
  5. Go to Transit gateway attachments and click Create transit gateway attachment.
  6. Choose your Transit Gateway, set Attachment type to VPC, pick the VPC, and select one subnet per Availability Zone you want reachable. Click Create.
  7. Repeat the attachment step for each VPC.
  8. Finally, in each VPC’s subnet route table, add a route for the other VPCs’ CIDR ranges (or a summarised range like 10.0.0.0/8) with the target set to your Transit Gateway.

Create a Transit Gateway — AWS CLI

# 1. Create the hub
aws ec2 create-transit-gateway \
  --description "Core hub" \
  --tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=tgw-core}]'

# 2. Attach a VPC (one subnet per AZ)
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0a1b2c3d4e5f \
  --vpc-id vpc-0a1b2c3d \
  --subnet-ids subnet-0a1b2c3d subnet-0e5f6a7b

# 3. In the VPC's subnet route table, send other VPCs' traffic to the TGW
aws ec2 create-route \
  --route-table-id rtb-0a1b2c3d \
  --destination-cidr-block 10.1.0.0/16 \
  --transit-gateway-id tgw-0a1b2c3d4e5f

Output:

{
    "TransitGatewayVpcAttachment": {
        "TransitGatewayAttachmentId": "tgw-attach-0c1d2e3f4a5b",
        "TransitGatewayId": "tgw-0a1b2c3d4e5f",
        "VpcId": "vpc-0a1b2c3d",
        "State": "pending",
        "SubnetIds": [
            "subnet-0a1b2c3d",
            "subnet-0e5f6a7b"
        ]
    }
}

The attachment moves from pending to available in a minute or two.

The cost and latency gotcha

A Transit Gateway is powerful, but it is not free and not invisible.

  1. You pay an hourly charge per attachment (roughly $0.05/attachment-hour in us-east-1 — about $36/month per VPC attached).
  2. You pay a per-GB data-processing charge on every gigabyte that flows through the hub (roughly $0.02/GB).
  3. Traffic now takes an extra hop through the hub, adding a small amount of latency versus a direct peering link.

So for ten VPCs the math is easy and the TGW wins handily. For exactly two VPCs, plain peering has no hourly hub fee and no per-GB processing charge, so it is cheaper and slightly faster — use peering there and save the Transit Gateway for when the count grows.

Cost trap: every attachment bills hourly even when idle. Clean up attachments for decommissioned VPCs, and prefer route summarisation over many specific routes to keep things manageable.

Best Practices

  • Reach for a Transit Gateway once you have four or more VPCs or need on-premises connectivity alongside them; stick with peering for just two.
  • Use multiple TGW route tables to segment environments (prod vs dev vs shared) instead of letting everything route to everything.
  • Attach the TGW to one subnet per Availability Zone so traffic stays in-AZ where possible and survives an AZ failure.
  • Plan non-overlapping CIDR blocks across all VPCs up front — the TGW cannot route between two networks that use the same IP range.
  • Watch per-GB data-processing and per-attachment costs in Cost Explorer, and delete attachments for VPCs you retire.
  • Enable VPC Flow Logs on attached subnets so you can audit and troubleshoot traffic crossing the hub.
Last updated June 15, 2026
Was this helpful?