Transit Gateway: the hub-and-spoke tax on multi-VPC AWS

Transit Gateway is the AWS hub-and-spoke service. Spoke VPCs attach to a central TGW, and the TGW handles routing between them. The billing model is simple on paper: $0.05 per attachment per hour, $0.02 per GB of traffic processed. Same in US and EU, slightly higher in Asia-Pacific.

The trap sits in three places. The first is that the per-GB charge applies to every byte that crosses the TGW, in either direction, regardless of whether it stays in the region. The second is that VPC peering, which the TGW often replaces, is free for the connection and free for same-AZ traffic. So the move from peering mesh to TGW hub usually adds cost rather than removing it. The third is that cross-AZ traffic that also crosses the TGW shows up on a completely separate bill line, under EC2 data transfer, where the network team is not looking.

The shape that produces most of the bill

A 12-VPC hub-and-spoke with 20 TB of monthly TGW traffic and 40% of that traffic also crossing AZ boundaries runs about $1,300 per month. Of that, $80 is the attachment hours, $400 is the data-processing fee, and the remaining $80 is the cross-AZ surcharge under EC2 data transfer. The rest comes from outbound internet traffic and DX connectivity that nobody attributes to the TGW because it is not on the TGW line.

The split matters. If you only look at the AWSTransitGateway bill line, you miss most of the cost. The CFO sees the total. The network team sees a sliver.

The four patterns we find in audits

1. Unused attachments still on the clock

Every attachment bills $36 per month whether or not traffic flows. After a VPC retirement, the attachment often outlives the VPC by weeks. We have found accounts with five dead attachments billing $180 a month for nothing. The fix is a one-line Terraform deletion and a check in the monthly review.

2. AWS-native traffic crossing the TGW

S3 and DynamoDB traffic that should leave the VPC through a Gateway VPC Endpoint instead enters the TGW, gets routed back out, and bills twice. The Gateway endpoint is free. The TGW data-processing fee on that traffic is $0.02 per GB. For a workload pushing 5 TB a month to S3, the difference is $100 per month per VPC, multiplied by however many VPCs you forgot to add the endpoint to.

3. Two chatty VPCs that should be peered

The default architecture diagram has every VPC attached to the TGW. The actual traffic pattern usually has two or three pairs of VPCs that talk to each other constantly: app-to-database, ingest-to-warehouse, prod-to-shared-services. A direct peering between the chatty pair is free for the connection and free for same-AZ traffic, while the TGW path is $0.02 per GB on both directions. For a 10 TB pair, that is $400 per month in fees you do not need.

4. Inspection VPC pattern doubling the data-processing fee

A common security architecture routes east-west traffic through an inspection VPC running a firewall. With a TGW in the middle, traffic crosses the TGW once on the way to inspection, and again on the way to the destination. Both transits bill the per-GB fee. The fix is either to scope inspection to flows that genuinely need it, or to use TGW route tables to bypass inspection for traffic already known to be safe. We see firewall-driven double billing wipe out 30% of the inspection budget routinely.

When TGW is the right choice

VPC peering scales badly. Every pair of VPCs that needs to communicate needs its own peering connection and its own route table edit on both sides. Above six or eight VPCs the operational cost of maintaining the mesh outweighs the per-GB charge of running it through TGW. At 20 VPCs the mesh has 190 connections and is unmaintainable.

TGW also gives you a central place to inspect traffic, attach a Network Firewall, and apply route tables that segment by environment. Those are real architectural wins. The cost question is not "TGW or peering" in absolute terms, it is "which traffic goes through TGW and which is peered around it".

The four moves that bring the bill down

First, audit the attachment list. Anything attached to a retired VPC, anything attached to a sandbox that nobody uses, anything attached "just in case" three years ago. Delete it. Each line is $36 per month.

Second, add Gateway VPC Endpoints for S3 and DynamoDB on every VPC that talks to those services. The endpoint is free. The TGW data-processing fee on the same traffic is not.

Third, identify the two or three chatty pairs and peer them directly. Keep TGW for the rest. The peering connection is free for same-AZ traffic and bills only the cross-AZ portion at the regular regional rate.

Fourth, audit cross-AZ usage on the TGW path. If 60% of your TGW traffic also crosses an AZ, the EC2 data transfer line is bigger than the TGW line itself. Consolidating chatty workloads to a single AZ is rarely possible end-to-end, but it is often possible for the loud component. A single multi-AZ Kafka cluster can move the needle alone.

What the calculator does for you

We built a free Transit Gateway cost calculator that takes attachment counts, monthly data, and your cross-AZ percentage, and shows the three components separately. It is a five-second sanity check before you commit to a TGW architecture or after you suspect one is over budget.

For real numbers on a real account, the 14-day audit pulls actual TGW spend, identifies the noisy VPCs, the dead attachments, and the routes that should be peered. Free, read-only IAM role, one-page summary the CFO can sign off on.