- Newest
- Most votes
- Most comments
Yes, this is exactly what TGW Policy-Based Routing (PBR) is designed for. Selective inspection based on source, destination, port, and protocol is a listed use case, and your dev-to-prod-on-443 example maps directly onto it. Here are your specific questions.
a) Making unmatched traffic route normally instead of being dropped
This is the most important point to get right. A policy table has an implicit deny: if a packet matches no rule, it is dropped (Policy table concepts). To avoid that, add a catch-all rule at the highest rule number with all match fields set to Any, pointing at your normal (non-inspection) route table. Rules are evaluated in ascending order and evaluation stops at the first match, so the pattern is:
- Low rule numbers: specific inspection rules (for example, source dev CIDR, destination prod CIDR, TCP, dest port 443) targeting your inspection route table.
- Highest rule number: catch-all (Any/Any/Any) targeting your normal route table.
The documentation calls this out directly as a best practice: add a default rule at a high rule number if you want unmatched traffic to reach a route table rather than be silently dropped. Note that a policy table replaces the standard route table on an attachment (an attachment can be associated with a policy table or a route table, but not both), so the catch-all's target is a TGW route table you point it at, it is not an automatic passthrough.
b) Do you still need appliance mode on the inspection VPC attachment
Yes. Appliance mode is what keeps both directions of a flow pinned to the same Availability Zone on the inspection VPC attachment, which a stateful firewall requires. PBR only changes which route table a flow is forwarded to, it does not affect AZ affinity. So for any flow you steer into the firewall, appliance mode on the inspection VPC attachment is still required.
c) Return traffic and bidirectional rules
You need to account for both directions yourself. PBR classifies traffic on the attachment where the packet enters the transit gateway, and it is not flow-aware, it does not automatically create a reverse rule. The forward flow (dev to prod, dest 443) is classified on the dev-side attachment, while the return flow (prod to dev) enters on the prod-side attachment and needs its own matching rule to take the same inspection path. If you only define the forward rule, the return traffic will hit the implicit deny or take a different path, and the stateful firewall will drop the asymmetric half of the flow. So plan matching rules for both directions, and keep appliance mode enabled so the pinned-AZ symmetry holds end to end.
On scale (~200 attachments)
A few things to plan for:
- Each attachment is associated with either a policy table or a route table, not both. Decide which attachments carry the policy table, typically the source attachments whose traffic you want to classify.
- Customer-managed rules use rule numbers from 1 to 50,000 per policy table, so a large fleet of flow rules is well within range.
- Leave gaps between rule numbers (for example 100, 200, 300) so you can insert rules later without renumbering, and put the most specific rules at the lowest numbers so a broad rule does not shadow them.
- After changes, verify the full evaluated order with GetTransitGatewayPolicyTableEntries before sending live traffic, especially to confirm your catch-all is last and nothing shadows your inspection rules.
References:
PBR can do this but there are some key pointers to look out for:
A policy table replaces the route table on an attachment, you can't have both. And if no rule matches, traffic gets dropped. It is an implicit deny, not a fallback. So you need a catch-all rule at the bottom that points unmatched traffic to your normal route table. Something like rule 50000, all sources, all destinations, all protocols → your default TGW route table. Without that, anything that does not match a specific rule is blackholed.
From the docs: "If no customer-managed rule matches and no system-managed rule matches, the traffic is dropped (implicit deny)." They also recommend always including a catch-all rule for exactly this reason. [+] https://docs.aws.amazon.com/vpc/latest/tgw/tgw-policy-tables-concepts.html
With the catch-all in place, your setup looks like this: specific rules at low numbers catch dev→prod on 443 and send it to an "inspection" route table that has a route to your firewall VPC. Everything else hits the catch-all and goes to your default route table for direct routing. That's your selective inspection. There is actually an example in the docs showing exactly this pattern HTTP traffic to a specific CIDR goes to an inspection route table, everything else goes to a default route table. [+] https://docs.aws.amazon.com/vpc/latest/tgw/tgw-policy-tables.html#tgw-policy-table-example-steering
Appliance mode - yes, still needed on the inspection VPC attachment. PBR decides which traffic goes to inspection but does not change AZ routing behavior once traffic arrives. Without appliance mode you get asymmetric flows and the stateful firewall drops return packets. This is the same requirement you have without PBR symmetric routing through the same AZ firewall endpoint is on you. [+] https://repost.aws/knowledge-center/transit-gateway-asymmetric-route-fix
Return traffic - PBR is not stateful. You need rules for both directions. If you write dev→prod 443 but not the return (prod→dev on ephemeral ports), the response takes a different path and your firewall sees half a flow. Either write matching return rules or your inspection won't work. Most people write explicit pairs.
On 200 attachments part, the policy table sits on the attachment you associate it with. Rule limit is 50,000 per policy table (rule numbers 1–50,000) so you have plenty of room. Best practice from AWS is to leave gaps between rule numbers (increments of 10 or 100) so you can insert new rules later without renumbering. [+] https://docs.aws.amazon.com/vpc/latest/tgw/tgw-policy-tables-concepts.html#tgw-policy-table-best-practices.
I hope this helps!
Relevant content
- AWS OFFICIALUpdated 8 months ago
Thanks for the response! One thing I'm not clear on, if I attach a policy table to my VPC attachment, what happens to the route table that's currently associated with it? Do they work together?