What a Transit Gateway actually costs (2026)

A Transit Gateway bills per attachment per hour plus per GB processed, and the hourly charge does not land where you would expect. For VPC attachments AWS bills the account that owns the VPC, not the account that owns the gateway, which quietly turns a shared network resource into a distributed bill.

What does a Transit Gateway charge for?

Two meters. Per the AWS Transit Gateway pricing page, "you are charged for the number of connections that you make to the Transit Gateway per hour and the amount of traffic that flows through AWS Transit Gateway."

Current rates are on that page and are region-specific. The structure is what matters: the attachment charge is fixed and continuous, so a hub with forty VPCs attached carries forty hourly charges before any packet moves. Attachments are the thing that accumulates, because removing one requires knowing nothing depends on it, and nobody knows that. What an attachment creates is covered in the VPC attachment documentation, and the ceiling in the Transit Gateway quotas.

Who actually pays for an attachment?

This is the part that surprises people, and AWS states it plainly:

The VPC account owner is billed hourly for each hour that their Amazon VPCs are attached to an AWS Transit Gateway.

Not the Transit Gateway owner. In the standard hub-and-spoke layout, where a network account owns the gateway and shares it through Resource Access Manager, every spoke account pays its own attachment charge. The network team owns the resource and sees almost none of its cost.

Other attachment types bill differently, and the differences are not intuitive:

Three different owners across four attachment types. Any chargeback model that assumes "network costs sit in the network account" will be wrong in both directions at once: understating spoke accounts and overstating the hub.

The practical consequence for a FinOps team is that Transit Gateway spend has to be assembled across accounts rather than read off one. Group by account and usage type together:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Virtual Private Cloud"]}}'

Transit Gateway charges appear under the VPC service name alongside NAT Gateway and endpoint charges, so usage type is the only thing that separates them.

Does data processing get charged twice?

Once per gateway the traffic passes through, which is not the same as once per transfer. Traffic between two VPCs attached to the same Transit Gateway is processed by that gateway and charged once. Traffic that crosses two gateways, through a Transit Gateway peering connection between Regions, is processed by each one.

And the data processing charge sits on top of transfer, not instead of it. If the two VPCs are in different Availability Zones, the underlying cross-AZ charge of $0.01 per GB in each direction still applies. If they are in different Regions, inter-Region transfer applies. Transit Gateway adds a layer of processing cost to whatever the traffic was already going to cost.

This is the same shape as the exemption on the EC2 data transfer pricing page, which grants free in-Region transfer to services like S3 and DynamoDB and then withdraws it: "If other AWS services are in the path of your data transfer, you will be charged their associated data processing costs. These services include, but are not limited to, PrivateLink endpoints, NAT Gateway and Transit Gateway." A Transit Gateway in the path removes the free-transfer exemption.

When is a Transit Gateway cheaper than peering?

When you have enough VPCs that the peering mesh stops being manageable, and the crossover is a governance point more than a cost one. VPC peering has no hourly charge and no data processing charge; you pay only the underlying transfer, and same-AZ peering traffic is free even across accounts. Transit Gateway adds an hourly charge per attachment and a per-GB processing charge on every byte.

So on pure cost, peering wins for a small number of VPCs that talk to each other directly, and it is not close: peering adds no meter at all. Transit Gateway is buying transitive routing, centralised policy and the ability to attach VPN and Direct Connect to the same hub. Those are real, and they are the justification. Cost is not.

The failure mode worth avoiding is a Transit Gateway deployed for two VPCs because it is the recommended pattern, then left in place as the pattern for everything. Ten attachments carrying almost no traffic is ten hourly charges buying route management you could have done with two peerings.

What should you check first?

Attachments with no traffic. They are pure hourly charge, and they are the commonest waste here because deleting an attachment feels riskier than leaving it:

aws ec2 describe-transit-gateway-attachments \
  --query 'TransitGatewayAttachments[].{tgw:TransitGatewayId,id:TransitGatewayAttachmentId,
           type:ResourceType,owner:ResourceOwnerId,state:State}' \
  --output table

Cross-reference the attachment IDs against the per-attachment metrics in the Transit Gateway CloudWatch metrics reference (BytesIn and BytesOut) over a full month. An attachment with zero bytes for a month is either a disaster recovery path nobody has tested or an artefact of a migration that finished. Both are worth a conversation, and one of them is free money.

Note that none of this appears in Cost Optimization Hub, which generates no recommendations for networking resources at all, and that Transit Gateway spend is grouped under the VPC service name in Cost Explorer rather than under a name matching the thing you provisioned. That combination is why it goes years unexamined, the same reason EC2 - Other does.