Cost optimization and governance for centralized traffic inspection with Transit Gateway and Network Firewall

Organizations frequently use Transit Gateway to route traffic from spoke VPCs in centralized inspection architectures to VPCs where Network Firewall performs deep packet inspection. It's also common to see customers routing all traffic through firewalls without specific and concrete inspection requirements, inspecting far more than their actual business needs dictate. With AWS Network Firewall, customers pay an hourly rate for each firewall endpoint per region and Availability Zone, plus per gigabyte processed. At scale, the per-GB charge dominates. For example, for 10 TB/month of inspected traffic, Network Firewall incurs in approximately $650/monthly data processing costs, on top of endpoint hours. If inspected traffic is not selected carefully, costs escalate fast.

This post covers three Transit Gateway features that combined can help you allocate costs and increase governance to identify and reduce the amount of traffic that is being inspected to what is truly essential.

1. Transit Gateway-attached firewalls and Transit Gateway Metering policies.

The AWS Network Firewall integration with AWS Transit Gateway lets you attach a Network Firewall directly to a Transit Gateway as a network function attachment (as a transit gateway attachment) either within their own account or shared from a different account. This eliminates the need for a dedicated inspection VPC, reducing architectural complexity and removing associated costs (subnets, route tables, potential cross-AZ transfers within the inspection VPC).

Traffic for transit gateway-attached firewalls must be routed through transit gateway route tables, not VPC route tables.

Now, customers can create custom metering policies for Transit Gateway, that define who should be charged based on traffic flow properties, attachment types and specific attachment IDs.

Customers can allocate costs by the source attachment owner (sender), destination attachment owner (receiver), or Transit Gateway owner. For TGW-attached firewalls, this includes the Network Firewall data processing charges, not just the TGW data processing charges. Flexible cost allocation covers standard per-GB data processing only. It does not redistribute the per-endpoint-hour firewall charge, the TLS inspection add-on, or Advanced Threat Protection charges, which remain with the firewall owner's account.

This makes governance more accessible: visibility into which accounts and workloads are driving inspection costs, and the ability to allocate those costs to the right owners.

Deploying Network Firewall following this approach is a prerequisite for leveraging metering policies capabilities. Without native attachment, metering policies can only allocate TGW data processing charges, not the Network Firewall charges themselves.

2. Transit Gateway Policy-Based Routing (PBR)

This new TGW feature gives network administrators rule-based control over how traffic is forwarded across a transit gateway. With PBR, forwarding decisions can be based on a combination of packet attributes including source and destination IP addresses, source and destination ports, and protocol rather than destination IP address alone.

This allows network teams to steer traffic selectively to security appliances or inspection services based on source, port, or protocol, replacing the destination-only routing model and directly controlling how much traffic reaches the firewall and is therefore processed and billed.

How they work together

Combining these features lets you cut inspection down to what truly needs it, then charge the rest back to the owners who drive it. The clearest way to see it is a concrete example, illustrated in the scenario below.

An example organization has a centralised inspection setup with a Network Firewall attached natively to the Transit Gateway. App1 VPC and App2 VPC for two different applications, in separate accounts, send east-west traffic to each other. In the initial state, every flow is routed through the firewall, shown by both arrows running red into the inspection route table. Across all applications the firewall processes 100 TB/month, costing $6,500/month in data processing ($0.065/GB). We'll zoom in on this App1-to-App2 path, which accounts for 10 TB/month ($650) of that total.

The operational sequence to improve on this is:

1. Deploy and observe

Attach Network Firewall natively to the Transit Gateway as a transit gateway attachment. Then configure metering policies to allocate inspection costs to the accounts, IPs, protocols, or port ranges whose traffic is being inspected. This gives you visibility into who is driving cost.

You can find detailed guidance on how to to this in these blogs:

• Flexible Cost Allocation for Transit Gateway
• How to migrate to Transit Gateway-attached AWS Network Firewall

Metering policies are ordered rules evaluated from lowest to highest rule number; when traffic matches a rule, the specified account is charged according to that rule's account setting. Register the firewall's Network Function attachment as a middlebox on the policy so the Network Firewall per-GB charges, not just the TGW charges, can be allocated. Charging the source attachment owner makes each account pay for the traffic it originates.

The application has a route from App1 VPC to App2 VPC that is currently being inspected, but it presents two different flows, one that uses TCP port 443 for calling an HTTPS API in App2, and another one to replicate database data on TCP port 3306. Therefore, the policy should have two rules to reflect that nuance and match both traffic flows:

Rule #	Metered account	Source	Destination	Protocol	Dest port	Purpose
100	Source attachment owner	App1	App2	TCP	443	Charge App1 for the API flow
200	Source attachment owner	App1	App2	TCP	3306	Charge App1 for the replication flow

In the diagram this is the "Metering policy" box: it attributes each flow's data-processing cost to App1, the account originating the traffic. That attribution is what makes the next step possible, because you can now see that the two App1 to App2 flows account for the bulk of the bill.

2. Define concrete, specific inspection requirements.

Use the cost-allocation data to identify which traffic classes drive the spend, then cross-reference against your actual security requirements: which traffic must be inspected (compliance scope, untrusted zones, internet-bound) versus which is inspected by default without a strong requirement (trusted east-west traffic between known workloads).

Here, the App1-to-App2 path we're focusing on turns out to be two different flows to the same destination, and accounts for 10 TB of that inspected traffic ($650/month):

• App1 to App2 on TCP/443: an API call crossing the App1-to-App2 trust boundary. This must be inspected.
• App1 to App2 on TCP/3306: trusted database replication between the same two workloads. This has no inspection requirement.

The 3306 flow is 20% of all inspected traffic, which is 2 TB/month, or $130/month, and it carries no inspection requirement.

3. Implement selective inspection.

This is where plain Transit Gateway route tables are not enough. Both flows share the same source and the same destination; they differ only by port. A route table forwards on destination (and, per attachment, on source), so it cannot send 443 to inspection while letting 3306 bypass. It is all-or-nothing for that source-destination pair, which is why the trusted 3306 flow is being inspected at all.

The routing policy matches on the full 5-tuple, so it separates the two flows on port:

Rule #	Source	Destination	Protocol	Dest port	Target	Result
100	App1	App2	TCP	443	inspection route table	Inspect
200	App1	App2	TCP	3306	non-inspection route table	Bypass
300	0.0.0.0/0	0.0.0.0/0	Any	Any	non-inspection route table	Catch-all bypass

Rule 200 sends the trusted replication traffic straight to its destination, bypassing the firewall, so it is no longer processed or billed.

Rule 300 here is a default-bypass posture: anything not explicitly matched skips inspection. That is the most cost-efficient choice, but it inverts the risk. You must enumerate every flow that needs inspection, because anything you forget silently bypasses the firewall. The opposite posture, default-inspect, points the catch-all at the inspection route table so any unmatched flow is inspected by default, and you write bypass rules only for the specific trusted flows. That is safer for compliance-driven environments but costs more and tends to drift back toward inspecting everything. Choose the default carefully based on your inspection requirements and whether your priority is cost (default-bypass) or assurance that nothing escapes inspection (default-inspect). Either way, because the policy table has an implicit deny, the catch-all must route matched traffic to a real route table, not simply permit it.

Port matching applies only when the protocol is TCP or UDP, which is why rules 100 and 200 specify TCP.

This is exactly what changes between the two diagrams. Now, the 3306 flow follows the Non-inspection route table, while the 443 flow is routed to the network firewall for inspection following the Inspection route table. The one arrow that moves is the whole story.

The result: the firewall now processes 8 TB/month instead of 10 TB for this single path. Data processing drops from $650 to $520/month, a $130/month reduction, by removing one flow that never needed inspection. In real world scenarios, where the different paths and flows are much more numerous, the potential for savings increases exponentially with an increased granularity on selection.

Policy Based Routing (PBR) and metering are two separate levers. PBR reduces how much traffic is inspected, which lowers the bill. Metering reallocates who pays for the traffic that is still inspected. Used together, they cut inspection to what is essential and charge the remainder to the accounts that generate it.

Considerations

• Important: PBR policy tables have an implicit deny for unmatched traffic. A catch-all rule at the bottom of the policy table to route legitimate traffic that doesn't require inspection is needed, or it will be dropped.
• PBR stops BGP advertisement on VPN/Connect attachments: Associating a policy table with a Site-to-Site VPN or Connect (SD-WAN) attachment stops all BGP route advertisement from the Transit Gateway to that peer. Direct Connect behaves differently (its advertisements are governed by the allowed-prefixes list on the DX gateway association). If your design relies on TGW-advertised routes over VPN/Connect, verify the impact before associating a policy table.
• Migration cutover: An attachment can be associated with a policy table or a route table, but not both. To adopt PBR on an attachment that already has a route table, you must disassociate the route table first, a brief routing disruption to plan for.
• Stateful inspection and appliance mode: With a native Transit Gateway-attached firewall, appliance mode is activated automatically, so both directions of a flow land on the same firewall instance for correct session tracking. You don't need to enable it manually (manual appliance-mode configuration only applies to the older customer-managed inspection VPC model).
• Visibility with native attachment: because the firewall lives in an AWS-managed VPC, you do not get VPC flow logs on the firewall endpoint ENIs directly. You do not lose end-to-end visibility, though: Transit Gateway Flow Logs capture the traffic crossing the TGW (including to and from the firewall attachment), and Network Firewall's own alert, flow, and TLS logs capture what the firewall inspects. Used together, these cover traffic-flow and inspection visibility without the self-managed inspection VPC.
• What to always inspect: Traffic crossing trust boundaries (untrusted zones, internet-facing, third-party VPCs), regulated workloads (PCI-DSS, SOC2 scope), and traffic from/to environments with relaxed security controls (sandbox, dev) should always be routed through inspection regardless of cost.
• Metering policy timing: Creating or changing a metering policy entry takes 2 billing hours to take effect. Cost allocation seen during that window won't yet reflect the new rule.
• Dropped traffic billing: When Network Firewall drops packets, data processing usage is charged to the sender account regardless of metering policy configuration.
• Cloud WAN peering: If the Transit Gateway peers with Cloud WAN, customer-managed PBR rules don't apply to the TGW-to-Cloud WAN peering attachment (those are controlled by higher-priority, read-only system-managed entries). Selective inspection via PBR applies to VPC, VPN, and Direct Connect attachments only.

*Using us-east-1 public pricing data as of August 2026.

References Transit Gateway-attached firewalls in Network Firewall - Documentation
AWS Transit Gateway network function attachments
Why and how to migrate to a Transit Gateway-attached AWS Network Firewall
AWS Transit Gateway Policy-Based Routing (PBR): Complete Guide to Rule-Based Traffic Forwarding
Transit Gateway Policy Tables - Documentation
Flexible cost allocation with Transit Gateway Metering Policies