Transit Gateway charges whoever sends, so an inspection VPC pays for every gigabyte it did not originate
Data processing is billed per gigabyte sent to the Transit Gateway, to the owner of the attachment that sent it. Route spoke traffic through an inspection VPC and every gigabyte is sent twice: once by the spoke, once by the inspection VPC on the way back. The charge doubles and half of it lands on the central network account. Flexible Cost Allocation exists to move it, with conditions.
· Venerable Networks
Every Transit Gateway bill has two lines: attachment hours and data processing. The hours are easy. The data processing charge has a rule about who pays it, and in a centralised inspection design that rule puts half the charge on the one account that originated none of the traffic.
The two rules
From the Transit Gateway pricing page:
The VPC account owner is billed hourly for each hour that their Amazon VPCs are attached to an AWS Transit Gateway.
Data processing charges apply for each gigabyte sent from a VPC, Direct Connect or VPN or Network Firewall to the AWS Transit Gateway (1 gigabyte = 1024 megabytes).
And in the pricing example, the rate and the recipient:
Transit Gateway data processing charge: 1 GB was sent from EC2 instance in a VPC attached to Transit Gateway. The Transit Gateway Data Processing will result in a charge of $0.02. Data Processing is charged to the VPC owner who sends the traffic to Transit Gateway.
Three things to hold on to. The charge is per gigabyte sent to the Transit Gateway, not per gigabyte that passes through it. It is charged to the owner of the attachment that sent it. And a reply is a send, so a request-response exchange is billed once in each direction, to each end.
For two spokes talking directly through a Transit Gateway, that is as simple as it sounds. Spoke A sends a gigabyte, spoke A pays $0.02. Spoke B replies with a gigabyte, spoke B pays $0.02. Two gigabytes moved, $0.04 total, each party paying for what it sent.
What inspection does to the count
Now put an inspection VPC in the path, the standard pattern: spoke route tables send everything to the inspection attachment, the firewall inspects, and the inspection VPC's route table sends it back to the Transit Gateway for delivery to the real destination.
Trace one gigabyte from spoke A to spoke B:
- Spoke A sends 1 GB to the Transit Gateway. Spoke A is charged $0.02.
- The Transit Gateway delivers it to the inspection VPC. Not a send; no charge.
- The firewall inspects it and the inspection VPC sends 1 GB back to the Transit Gateway. The inspection VPC's owner is charged $0.02.
- The Transit Gateway delivers it to spoke B. No charge.
The reply from B to A traces the same four steps. Spoke B is charged $0.02 for sending it, and the inspection VPC is charged $0.02 again for sending it onward.
| One gigabyte each way, spoke A ↔ spoke B | Spoke A | Spoke B | Inspection VPC | Total |
|---|---|---|---|---|
| Direct through the Transit Gateway | $0.02 | $0.02 | — | $0.04 |
| Through an inspection VPC | $0.02 | $0.02 | $0.04 | $0.08 |
Two consequences. The Transit Gateway data processing bill for inspected traffic is double what the same traffic costs uninspected, because every gigabyte is sent to the Transit Gateway twice. And half of the doubled total lands on the inspection VPC's owner, typically a central network or security account that originated none of it. Across an organisation, that account's Transit Gateway data processing line equals the sum of every spoke's, for traffic it only forwarded.
This is on top of whatever the inspection itself costs: Network Firewall data processing, or the appliances' instance hours. It is also the reason the inspection VPC's route table design matters for cost and not only for correctness. Lab 17 is about an inspection VPC where appliance mode is silently not working, and the symptom that surfaced it was a cross-zone data transfer line on the central account's bill, the same account that, under the rule above, is already carrying half the processing charge.
The same rule, elsewhere
Direct Connect. Data arriving from on-premises through a Direct Connect gateway attachment is sent to the Transit Gateway by that attachment, so the charge goes to its owner, which is usually the central connectivity account rather than the workload VPC the data is for. AWS names this as a problem worth solving, in the Flexible Cost Allocation documentation's list of scenarios:
Hybrid environment cost allocation: Allocate costs for data entering AWS from on-premises through Direct Connect Gateway to the destination VPC account owner rather than the central IT admin account owner.
Peering. The rule has one documented exemption:
Data processing charges do not apply for data sent from a peering attachment to a Transit Gateway.
The pricing example for inter-Region peering totals $0.04 for a gigabyte: $0.02 processing on the sending Transit Gateway and $0.02 inter-Region data transfer out. The receiving Transit Gateway charges nothing for the gigabyte the peering attachment hands it. So a gigabyte that crosses two Transit Gateways over peering is processed once, not twice.
Flexible Cost Allocation
Until late 2025 the sender rule was the only rule. Flexible Cost Allocation adds a metering policy per Transit Gateway that decides who is billed, by flow:
By default, transit gateway uses a sender-based cost allocation model where data processing charges are allocated to the account that owns the source attachment. You can create custom metering policies that define which accounts should be charged based on traffic flow properties such as attachment types, specific attachment IDs, or network addresses.
Three choices of who pays for a matching flow: the source attachment owner (the default), the destination attachment owner, or the Transit Gateway owner. A policy holds up to 50 ordered entries, evaluated lowest rule number first, matching on attachment type, attachment ID, CIDR, port range and protocol. One policy per Transit Gateway, and only the Transit Gateway owner can create or change it.
The feature that addresses the inspection problem directly is middlebox attachments:
Transit gateway metering policies support Middlebox attachments allowing you to flexibly allocate data processing charges for network traffic routed via middlebox appliances such as network firewalls and load balancers. … You can define metering policies to flexibly allocated data processing usage on middlebox attachments to the original source attachment, final destination attachment or transit gateway account owner.
Declare the inspection VPC's attachment as a middlebox, and step 3 in the trace above, the inspection VPC sending the gigabyte back, can be billed to spoke A instead of to the inspection account. Up to 10 middlebox attachments per policy; VPC, VPN and Network Function (AWS Network Firewall) attachments qualify, and for Network Function attachments the firewall's own data processing charge follows the same allocation.
aws ec2 create-transit-gateway-metering-policy \
--transit-gateway-id tgw-0123456789abcdef0 \
--middle-box-attachment-ids tgw-attach-0inspection000000Then add entries for the flows whose billing should change. The default entry, which cannot be deleted, keeps everything unmatched on the sender.
The conditions
The documentation's considerations section is where the design constraints live, and three of them decide whether the middlebox allocation works for a given inspection VPC at all.
The 5-tuple must survive inspection.
Middlebox metering policy assumes traffic between the original source and destination attachment is hair-pinned via the specified middle-box attachment … Hence the network 5-tuple (source/destination IPs, source/destination ports and protocol) for flows ingressing and egressing out of middle-box attachments must match. Flows with 5-tuple mis-matches on middle-box attachments (e.g. NAT transformation in inspection VPC) are treated as regular source-destination attachment flows.
An inspection VPC that NATs, a proxy, anything that rewrites addresses or ports, breaks the match. The flow out of the middlebox no longer looks like the flow in, so it is billed as an ordinary send from the inspection VPC: the default rule, the central account pays. Transparent inline inspection qualifies. Explicit proxies do not.
North-south is not a middlebox flow.
All egress-only flows on the middlebox attachment (for example north-south traffic to internet via IGW in an inspection VPC) are treated as regular source-destination flows.
Spoke-to-internet through the inspection VPC's own internet gateway or NAT Gateway never comes back to the Transit Gateway, so there is no second send to reallocate. The spoke paid for its one send and that is the end of it. The middlebox allocation is for east-west, where the hairpin happens.
Dropped packets bill the sender regardless.
For Network Function attachments when AWS Network firewall drops packets, all data processing usage is charged back to the sender account regardless of metering policy configuration.
And the hours are not in scope. Flexible Cost Allocation covers data processing and data transfer usage. It does not apply to attachment hourly charges, which stay with the attachment owner. Changes take effect at the end of the next billing hour, and the documentation carries a note worth reading before enabling it in an organisation that spans jurisdictions: reassigning usage between accounts can have tax implications.
What to do with it
Model inspection as 2× on the processing line, with half of it on the hub. Before the inspection VPC exists, take the spoke-to-spoke Transit Gateway data processing you have today and double it; that is the new total, and the increase is the hub account's. If that number is surprising, it is better to be surprised by the model.
Decide who should pay before you build, because the default is the hub. With no metering policy, the sender rule puts the second charge on whoever owns the inspection VPC. A chargeback model that depends on spokes paying for their own inspected traffic needs a metering policy with the inspection attachment declared as a middlebox, and it needs the inspection to be transparent.
Check the inspection VPC for NAT before you rely on middlebox allocation. If the firewall or proxy rewrites the 5-tuple, the allocation silently falls back to the sender rule and the hub keeps paying. Nothing errors; the bill just does not move.
Expect the peering exemption and the Direct Connect default. A gigabyte over inter-Region peering is processed once. A gigabyte arriving from on-premises is processed to the Direct Connect attachment's owner, not the VPC it was for, unless a policy entry says otherwise.
Read the cost allocation tags as categorisation, not allocation. Tags organise charges within an account. Metering policies decide which account the charge is in. The documentation separates the two deliberately, and a chargeback that only uses tags cannot move the inspection charge off the hub.
The sender rule is one sentence on the pricing page. Inspection makes every gigabyte a two-sender event, and until you tell the Transit Gateway otherwise, the second sender is you.