Transit Gateway data processing cost is the charge for gigabytes you send into the gateway. The hourly attachment is the other half of the bill, and it is easy to see: one line per VPC that stays attached. The processing fee moves with traffic. A quiet attachment still has an hour price. A busy attachment adds a gigabyte price on top, and standard data transfer can sit beside both. Finance sees "Transit Gateway" as one product. The meter is two products that happen to share a name.
Rutagon reads the attachment list and the bytes that actually crossed. Data transfer cost reduction is the wider path for cross-AZ and internet bytes. This article is the processing fee on the gateway itself.
How Transit Gateway data processing cost is metered
The Transit Gateway pricing page charges for the connections you make, per hour, and for the traffic that flows through the gateway. A Transit Gateway can attach Amazon VPCs, Direct Connect, VPNs, Network Firewall, and SD-WAN appliances, including across accounts. The VPC account owner is billed hourly for each hour their VPC is attached. VPN attachments are billed hourly to the Transit Gateway owner. Direct Connect attachments are billed hourly to the Direct Connect gateway owner. Connect attachments are billed hourly to the Transit Gateway owner. For a peering attachment between two gateways, each owner is billed hourly. Network function attachments are billed hourly to the Network Firewall owner.
Hourly billing starts when the Transit Gateway owner accepts the VPC attachment, and it stops when the attachment is deleted. Each partial VPC attachment hour is billed as a full hour. Deleting the workload and leaving the attachment is a full hour, every hour, until someone deletes the attachment. Site-to-Site VPN connection pricing still applies in addition to the VPN attachment price.
Data processing applies to each gigabyte sent from a VPC, Direct Connect, VPN, or Network Firewall to the Transit Gateway. The page defines a gigabyte as 1,024 megabytes. There is no extra data processing charge for a Connect attachment beyond the charge on the underlying VPC or Direct Connect attachment. A Private IP VPN has no extra processing charge beyond the underlying Direct Connect attachment. Multicast is its own case: processing applies to each gigabyte received by each multicast receiver instance. Processing does not apply to data sent from a peering attachment into a Transit Gateway. Standard AWS data transfer charges still apply on top of all of this. The page points those at the data transfer section of the EC2 pricing page.
The published example is US East (Ohio). You create a Transit Gateway, attach a VPC, and route 1 GB from an EC2 instance in that VPC to another VPC through the gateway. The example states the hourly rate for that Region as $0.10 per hour ($0.05 per VPC attachment). When the gateway is shared across accounts, the hourly fee is charged to the account that owns the attached VPC. The 1 GB of data processing is $0.02, charged to the VPC owner who sent the traffic into the gateway.
A second example sends 1 GB from an instance on Transit Gateway 1 in N. Virginia, across a peering attachment, to Transit Gateway 2 in Oregon. The traffic charges in the example total $0.04. That is $0.02 of data processing on Transit Gateway 1, plus $0.02 of outbound inter-Region data transfer. Transit Gateway 2 does not take a processing charge, because processing does not apply to data sent from a peering attachment. The example also says inbound inter-Region data transfer is free, so the Oregon side has no further charge in that story.
attachment_hour: $0.05 per VPC attachment in the US East (Ohio) example
partial_hour: billed as a full hour, from accept until delete
processing: $0.02 for 1 GB sent into the gateway in that example
who_pays_processing: the VPC owner who sent the traffic
peering_into_a_gateway: no processing charge on the receiving gatewayThose figures are the published examples for the Regions named on the page. Another Region has its own rate. We quote the example, then we look up the Region before we put a dollar figure in a forecast. The direction of the fee does not change with the Region: you pay processing on bytes sent to the gateway, and the sender's VPC owner is the account on that line in the example.
Which paths send bytes into the gateway
Every packet that uses the Transit Gateway as a next hop is a candidate for the processing fee. East-west traffic between two VPCs that you attached on purpose belongs there. Traffic that only exists because the route table is too broad does not. A default route in a private subnet that points at the gateway will send Amazon S3, package mirrors, and health checks through the hub. Each of those gigabytes is processing, and many of them are also a data-transfer charge if they leave the Availability Zone or the Region.
NAT Gateway cost reduction is the sibling meter. A NAT gateway has its own hourly and per-gigabyte processing charges. Hairpinning a subnet through Transit Gateway and then through a NAT in another VPC stacks the Transit Gateway processing fee on the NAT processing fee. We draw the path before we add either hop. Gateway endpoints for S3 and DynamoDB keep that traffic off both devices. Interface endpoints have their own hourly and processing prices, so we compare the path, we do not collect endpoints as a reflex.
Multicast multiplies the gigabyte by the number of receivers. One stream that fans out to ten instances is processing on each receiver's copy, on top of the send into the gateway. We ask whether the receivers need a network fan-out or a queue. A queue has a request meter. A multicast group has a per-receiver gigabyte meter. The application usually wanted one of those, and the console made the other easy.
Shared gateways move the hour charge to the VPC owner's account. A platform team that owns the gateway, and application accounts that own the VPCs, will see the attachment hour on the application bill. Processing follows the account that sent the bytes. A cost allocation fight starts when the platform account expects both lines and the application account is holding the send. We tag the attachment and we name the payer in the same place we name the route.
Peering two Transit Gateways across Regions is the $0.04 shape in the example: processing on the sending gateway, inter-Region transfer on the way out, and no processing on the far gateway for bytes that arrived from the peering attachment. Teams who double-count processing on both gateways overstate the line. Teams who forget the inter-Region transfer understate it. We write both down from the example, then replace the example's $0.02 with the Region's current processing rate if it differs.
What we change, and what we leave attached
The diagnostic is the attachment list, the hour each one has been accepted, the transit gateway route tables that point attachments at each other, and the bytes sent. Cost Explorer will show the processing line. The route table shows which route advertised 0.0.0.0/0 into the hub. We delete attachments whose VPC no longer has a workload, because the partial hour rule means a forgotten attachment bills a full hour until it is gone. We narrow routes so that only the CIDRs that must cross the hub use it.
We leave the gateway in place when it is the hub you meant: many VPCs, a shared VPN or Direct Connect, a firewall attachment, and a route table you can point at one inspection VPC. The $0.05 attachment hour in the Ohio example is small next to a gigabyte price on traffic that did not need the hub. The processing fee is the decision. An idle attachment is a cleanup. A default route through the gateway is a design change.
Rutagon runs this as a short bill review. We list attachments and who pays the hour, we list bytes sent and who pays processing, and we separate multicast and cross-Region peering from ordinary VPC-to-VPC sends. The pricing page is the source for the Ohio example's $0.05 per VPC attachment hour, the $0.02 per gigabyte, and the peering example's $0.04 split. The configuration review asks one question after the rates: which routes are sending bytes into the gateway, and which of those bytes had a cheaper next hop inside the VPC?
Frequently Asked Questions
Who pays Transit Gateway data processing cost?
In the pricing example, data processing is charged to the VPC owner who sends the traffic into the Transit Gateway. The hourly attachment fee, when the gateway is shared, is also charged to the account that owns the attached VPC. The gateway owner pays the hour on VPN, Connect, and their side of a peering attachment. Read the attachment type before you assign the line.
Does a peering attachment get processed twice?
The cross-Region example sends 1 GB from a gateway in N. Virginia to a gateway in Oregon. Processing is $0.02 on the sending gateway. The receiving gateway does not take a processing charge, because processing does not apply to data sent from a peering attachment. Outbound inter-Region data transfer in that example is another $0.02. The total they publish is $0.04.
Is the hourly charge the same thing as processing?
The Ohio example lists them apart: $0.05 per VPC attachment per hour, shown as $0.10 per hour in that story, and $0.02 for 1 GB processed. Hours run from accept until delete, and a partial hour bills as a full hour. Quiet traffic pays the hour, and heavy traffic pays the hour plus the gigabytes.
Do Connect and Private IP VPN add a second processing fee?
The pricing page says Connect has no additional processing charge beyond the underlying VPC or Direct Connect attachment. Private IP VPN has none beyond the underlying Direct Connect attachment. The underlying attachment still processes the gigabyte. You are not billed a second processing line for the Connect or private-IP wrapper itself.
Does multicast bill the sender once?
Processing applies to each gigabyte received by each multicast receiver instance. A fan-out to many instances repeats the gigabyte. We confirm the receiver count before we treat multicast as one send. Ordinary VPC-to-VPC traffic in the Ohio example is one processing charge, on the sender, for the gigabyte they sent.
Ask for an AWS bill review that separates attachment hours from data processing. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.