AWS Transit Gateway Policy-Based Routing (PBR): Complete Guide to Rule-Based Traffic Forwarding

27 minute read

Content level: Intermediate

This article provides a complete guide to AWS Transit Gateway Policy-Based Routing (PBR) — a new feature enabling traffic forwarding decisions based on source/destination IP, ports, and protocol instead of destination-only routing. It covers implementation steps, use cases, limitations, troubleshooting, and benefits for network engineers and security architects building multi-VPC architectures with selective security inspection requirements.

Introduction

AWS Transit Gateway has introduced Policy-Based Routing (PBR) — a powerful new feature that fundamentally changes how network administrators can control traffic forwarding across their transit gateway infrastructure. Until now, Transit Gateway routing decisions were limited to destination IP address only. With PBR, you can now make forwarding decisions based on a 5-tuple combination of packet attributes: source IP, destination IP, source port, destination port, and protocol.

This article provides a comprehensive guide covering the feature overview, real-world use cases, step-by-step implementation, routing evaluation logic, limitations, troubleshooting, and customer benefits.

What is Transit Gateway Policy-Based Routing?
What Changed - Before vs After PBR
Key Concepts
How Routing Evaluation Works
Real-World Scenario and Use Cases
Step-by-Step Implementation via Console
Architecture Diagram
Limitations
Troubleshooting Guide
Customer Benefits and Advantages
Best Practices
Conclusion
Related Resources

What is Transit Gateway Policy-Based Routing?

Policy-Based Routing (PBR) for AWS Transit Gateway gives network administrators rule-based control over how traffic is forwarded across a transit gateway. Instead of routing solely based on destination IP address, PBR enables forwarding decisions based on:

Match Attribute	Description	Example
Source CIDR Block	Source IP address or CIDR	`10.1.10.0/24`
Destination CIDR Block	Destination IP address or CIDR	`10.2.0.0/16`
Protocol	IANA protocol number	TCP (6), UDP (17), ICMP (1), GRE (47)
Source Port Range	Source port or port range	`1024-65535`
Destination Port Range	Destination port or port range	`443` or `80-8080`

PBR is configured through policy tables — ordered lists of rules that classify traffic and direct matching packets to a specified transit gateway route table. A policy table replaces the standard route table on an attachment.

Key highlights:

Available in all AWS Regions where Transit Gateway is available
No additional charge beyond standard Transit Gateway fees
No activation required — PBR is enabled on all transit gateways by default
Supports IPv4 and IPv6 CIDR formats
Compatible with all TGW attachment types: VPC, Direct Connect, VPN (Site-to-Site), Client VPN, Transit Gateway Connect, and Peering

What Changed — Before vs. After PBR

Before PBR (Traditional TGW Routing)

Limitation	Impact
Destination-only routing	TGW route tables could only forward based on destination CIDR — no source awareness
No port/protocol differentiation	All TCP/UDP/ICMP traffic to the same destination followed the same path
All-or-nothing inspection	Either ALL traffic or NO traffic went through security appliances
Complex multi-VPC workarounds	Required separate VPCs, multiple TGW attachments, NACLs, or third-party appliances with hairpin routing
No centralized traffic steering	Per-subnet routing was limited to VPC route tables, not at TGW level
Operational overhead	Managing multiple route tables and associations for different traffic flows

After PBR (What is Now Possible)

Capability	Benefit
5-tuple matching	Make forwarding decisions on source, destination, protocol, and ports
Selective traffic steering	Send only specific flows through security/inspection appliances
Multiple routing domains from one attachment	Different traffic types use different route tables without multiple attachments
Ordered rule evaluation	Predictable, priority-based rule processing (first match wins)
Implicit deny (Zero Trust)	Unmatched traffic is dropped — enforce allowlist-style routing at TGW level
Centralized policy enforcement	Single point of control for traffic routing decisions across your entire network
Cost optimization	Inspect only what requires inspection — reduce unnecessary appliance processing

Side-by-Side Comparison

Scenario	Before PBR	After PBR
Inspect only HTTPS traffic from one subnet	Route ALL traffic through firewall OR deploy complex per-subnet routing	Single policy rule: match source + port 443 → firewall route table
Route different apps over different paths	Multiple TGW attachments per VPC, complex route table management	One attachment, multiple rules pointing to different route tables
Block unauthorized traffic patterns at TGW	Not possible at TGW level — relied on NACLs and Security Groups	Policy table implicit deny — centralized enforcement at transit layer
Isolate regulated workloads routing	Separate VPCs, separate attachments, peering complexity	Same VPC, different subnets, policy rules enforce routing isolation
Protocol-specific routing (e.g., GRE tunnels)	All protocols followed same path	Match protocol 47 (GRE) and route to specific tunnel endpoint

Key Concepts

Policy Table

A policy table is an ordered set of rules associated with a Transit Gateway attachment. Each rule specifies:

Match criteria — packet attributes used to classify traffic
Target route table — the TGW route table used to forward matched traffic

Important: An attachment can be associated with EITHER a policy table OR a route table, but NOT both.

Policy Rules (Entries)

Each rule in a policy table contains:

Component	Description	Required?
Rule Number	Integer from 1–50,000 that determines evaluation order	Yes
Source CIDR Block	IPv4/IPv6 CIDR to match source IP	No (defaults to Any)
Destination CIDR Block	IPv4/IPv6 CIDR to match destination IP	No (defaults to Any)
Protocol	IANA protocol number (1, 6, 17, 47, or *)	No (defaults to Any)
Source Port Range	Port or range (only for TCP/UDP)	No (defaults to Any)
Destination Port Range	Port or range (only for TCP/UDP)	No (defaults to Any)
Target Route Table	TGW route table for forwarding matched traffic	Yes

Entry Types

Type	Created By	Rule Number	Precedence	Modifiable
System-managed	AWS (e.g., Cloud WAN)	Displays as `*`	Evaluated FIRST	No
Customer-managed	You	1–50,000	Evaluated AFTER system entries	Yes

Implicit Deny

If no rule matches the incoming traffic (neither system-managed nor customer-managed), the traffic is dropped silently. This is the implicit deny behavior — similar to how security groups work with an implicit deny-all at the end.

How Routing Evaluation Works

Understanding the evaluation flow is critical for designing correct policy tables.

Evaluation Order

┌─────────────────────────────────────────────────────────────────┐
│           TRANSIT GATEWAY POLICY TABLE EVALUATION               |
└─────────────────────────────────────────────────────────────────┘

  Packet arrives at TGW attachment associated with Policy Table
                              │
                              ▼
               ┌──────────────────────────────┐
               │  STEP 1: System-Managed      │
               │  Entries (Rule # = *)        │
               │  Evaluated FIRST             │
               └──────────────┬───────────────┘
                         │         │
                    MATCH          NO MATCH
                         │         │
                         ▼         ▼
              ┌────────────┐  ┌──────────────────────────────┐
              │ APPLY rule │  │  STEP 2: Customer-Managed    │
              │ STOP eval. │  │  Entries (ascending order)   │
              └────────────┘  │  Rule 100 → Rule 200 → ...   │
                              └──────────────┬───────────────┘
                                        │         │
                                   MATCH          NO MATCH
                                        │         │
                                        ▼         ▼
                             ┌────────────┐  ┌────────────┐
                             │ APPLY first│  │  STEP 3:   │
                             │ matching   │  │  IMPLICIT  │
                             │ rule. STOP.│  │  DENY      │
                             └────────────┘  │  (DROP)    │
                                             └────────────┘

Key Evaluation Rules

System-managed entries always evaluate first — regardless of their content, they have higher priority than any customer-managed entry.
Customer-managed entries evaluate in ascending numeric order — Rule 100 is evaluated before Rule 200, which is evaluated before Rule 300.
First match wins — once a rule matches, evaluation stops immediately. No subsequent rules are checked.
All specified conditions must match — if a rule specifies both source CIDR and destination port, BOTH must match for the rule to apply.
Omitted fields match everything — if you leave source CIDR blank, it matches any source IP.
Implicit deny at the end — if no rule matches, traffic is dropped.

Evaluation Example

Consider this policy table:

Rule #	Source CIDR	Dest CIDR	Protocol	Dst Port	Target Route Table
100	10.1.10.0/24	*	TCP (6)	443	tgw-rtb-firewall
200	10.1.10.0/24	*	*	*	tgw-rtb-inspection
300	*	*	*	*	tgw-rtb-default

Scenario A: Packet from 10.1.10.5 → 10.2.0.100 on TCP port 443

Rule 100: Source matches ✓, Protocol TCP ✓, Dst Port 443 ✓ → MATCH → tgw-rtb-firewall

Scenario B: Packet from 10.1.10.5 → 10.2.0.100 on TCP port 22 (SSH)

Rule 100: Source matches ✓, Protocol TCP ✓, Dst Port 443 ✗ → NO MATCH
Rule 200: Source matches ✓, Protocol Any ✓ → MATCH → tgw-rtb-inspection

Scenario C: Packet from 10.1.30.5 → 10.2.0.100 on any protocol

Rule 100: Source 10.1.10.0/24 ✗ → NO MATCH
Rule 200: Source 10.1.10.0/24 ✗ → NO MATCH
Rule 300: Source Any ✓, Dest Any ✓ → MATCH → tgw-rtb-default

Scenario D: If Rule 300 did NOT exist and packet is from 10.1.30.5:

Rule 100: NO MATCH
Rule 200: NO MATCH
No more rules → IMPLICIT DENY → PACKET DROPPED

Real-World Scenario and Use Cases

Use Case 1: Multi-Tier Security Inspection for Financial Services (Primary Scenario)

Business Requirement

A financial services company has a shared VPC with multiple workload tiers that have different compliance requirements:

PCI-DSS workloads (Subnet: 10.1.10.0/24) — All HTTPS traffic (port 443) must pass through a Next-Generation Firewall (NGFW) for TLS inspection and threat detection
SOX-regulated workloads (Subnet: 10.1.20.0/24) — All traffic must be deep-packet-inspected by an IDS/IPS appliance for audit compliance
General workloads (Subnet: 10.1.30.0/24) — Route directly to destination without any inspection (reduce latency and cost)

Without PBR (Old Approach — Complex)

Previously, achieving this required:

Three separate VPCs (one per compliance tier)
Three separate TGW attachments
Three route table associations
Complex VPC peering or PrivateLink for inter-tier communication
Multiple NAT gateways and route configurations
Higher operational complexity and cost

With PBR (New Approach — Simple)

Now you can achieve the same outcome with:

One source VPC with multiple subnets
One TGW attachment for the source VPC
One policy table with three rules
Clear, auditable rule-based logic

Use Case 2: Application-Based Traffic Engineering

Scenario: A media company routes video streaming traffic (UDP ports 1024-65535) over a high-bandwidth dedicated path, while management/control traffic (SSH, HTTPS) routes over a standard path.

Rule #	Match Criteria	Target
100	Protocol=UDP, DstPort=1024-65535	tgw-rtb-high-bandwidth
200	Protocol=TCP, DstPort=22	tgw-rtb-management
300	Protocol=TCP, DstPort=443	tgw-rtb-management
400	Catch-all	tgw-rtb-default

Use Case 3: Zero Trust Network Segmentation

Scenario: An enterprise wants to enforce that only approved traffic flows are permitted at the transit layer — anything not explicitly allowed is dropped.

Rule #	Match Criteria	Target
100	Src=10.1.0.0/16, Dst=10.2.0.0/16, Proto=TCP, DstPort=443	tgw-rtb-approved
200	Src=10.1.0.0/16, Dst=10.3.0.0/16, Proto=TCP, DstPort=5432	tgw-rtb-database
(no catch-all)	—	Implicit Deny (DROP)

By intentionally NOT including a catch-all rule, all traffic that doesn't match an approved flow is silently dropped at the transit gateway level — true Zero Trust enforcement.

Use Case 4: Hybrid Cloud with Selective VPN Inspection

Scenario: Traffic from on-premises (via Direct Connect) destined for sensitive cloud workloads must pass through a cloud-based firewall. Other on-premises-to-cloud traffic routes directly.

Rule #	Match Criteria	Target
100	Dst=10.100.0.0/16 (sensitive VPC)	tgw-rtb-firewall-inspection
200	Dst=10.200.0.0/16 (public apps VPC)	tgw-rtb-direct
300	Catch-all	tgw-rtb-default

The policy table is associated with the Direct Connect gateway attachment, so only on-premises-originating traffic is subject to these rules.

Use Case 5: Multi-Tenant SaaS Isolation

Scenario: A SaaS provider hosts multiple tenants in separate VPCs. Traffic from the shared services VPC must be routed to tenant-specific inspection points based on destination.

Rule #	Match Criteria	Target
100	Dst=10.10.0.0/16 (Tenant A)	tgw-rtb-tenant-a
200	Dst=10.20.0.0/16 (Tenant B)	tgw-rtb-tenant-b
300	Dst=10.30.0.0/16 (Tenant C)	tgw-rtb-tenant-c
400	Catch-all	tgw-rtb-shared-services

Step-by-Step Implementation (Console)

This section walks through implementing Use Case 1 (Multi-Tier Security Inspection) using the AWS Management Console.

Prerequisites

Before you begin, ensure you have:

An existing Transit Gateway
A source VPC (workloads) with TGW attachment already created
A Firewall VPC with TGW attachment already created
An IDS/IPS VPC with TGW attachment already created
Destination/Spoke VPCs with TGW attachments already created
IAM permissions for the PBR APIs (see IAM section below)

Required IAM Permissions

Your IAM principal needs the following actions:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "ec2:CreateTransitGatewayPolicyTable",
            "ec2:DescribeTransitGatewayPolicyTables",
            "ec2:DeleteTransitGatewayPolicyTable",
            "ec2:AssociateTransitGatewayPolicyTable",
            "ec2:DisassociateTransitGatewayPolicyTable",
            "ec2:GetTransitGatewayPolicyTableAssociations",
            "ec2:GetTransitGatewayPolicyTableEntries",
            "ec2:CreateTransitGatewayPolicyTableEntry",
            "ec2:ModifyTransitGatewayPolicyTableEntry",
            "ec2:DeleteTransitGatewayPolicyTableEntry"
        ],
        "Resource": "*"
    }]
}

Step 1: Create Target Route Tables

Each rule in your policy table needs a target route table. Create one for each traffic path.

Open the Amazon VPC Console → https://console.aws.amazon.com/vpc/
In the left navigation pane, under Transit Gateways, select Transit gateway route tables
Click Create transit gateway route table
Configure:
- Name tag: tgw-rtb-firewall
- Transit gateway ID: Select your existing Transit Gateway
Click Create transit gateway route table

Repeat to create:

tgw-rtb-inspection (for IDS/IPS path)
tgw-rtb-default (for direct routing path)

Step 2: Add Routes to Each Route Table

For `tgw-rtb-firewall`:

Select the route table tgw-rtb-firewall from the list
Navigate to the Routes tab
Click Create static route
Configure:
- CIDR: 0.0.0.0/0
- Choose attachment: Select your Firewall VPC attachment
Click Create static route

For `tgw-rtb-inspection`:

Select tgw-rtb-inspection
Navigate to Routes tab → Click Create static route
Configure:
- CIDR: 0.0.0.0/0
- Choose attachment: Select your IDS/IPS VPC attachment
Click Create static route

For `tgw-rtb-default`:

Select tgw-rtb-default
Navigate to Routes tab → Click Create static route
Configure:
- CIDR: 10.2.0.0/16 (your destination spoke VPC CIDR)
- Choose attachment: Select the destination Spoke VPC attachment
Click Create static route
Add additional routes as needed for other destination VPCs

Step 3: Disassociate Existing Route Table from Source VPC Attachment

⚠️ Critical: An attachment cannot have both a route table AND a policy table. You must disassociate the existing route table first.

In the left pane, go to Transit gateway route tables
Select the route table currently associated with your source workload VPC attachment
Navigate to the Associations tab
Select the row showing your source VPC attachment
Click Delete association
In the confirmation dialog, click Delete association
Wait for the state to change from Disassociating to complete

Step 4: Create the Policy Table

In the left navigation pane, under Transit Gateways, select Transit gateway policy tables
Click Create transit gateway policy table
Configure:
- Name tag: multi-tier-security-policy
- Transit gateway ID: Select your Transit Gateway
Click Create transit gateway policy table
Wait for state to become Available
Note the Policy Table ID (e.g., tgw-ptb-0ca78a549EXAMPLE)

Step 5: Create Policy Table Entries (Rules)

Rule 100 — PCI HTTPS Traffic → Firewall

Select the policy table multi-tier-security-policy
Navigate to the Entries tab
Click Create entry
Under Entry details:
- Rule number: 100
- Target transit gateway route table: Select tgw-rtb-firewall
Under Rule conditions:
- Source CIDR block: 10.1.10.0/24
- Destination CIDR block: (leave blank — matches any destination)
- Protocol: Select TCP (6)
- Source port range: (leave blank — matches any source port)
- Destination port range: 443
Click Create entry

Rule 200 — SOX Regulated Traffic → Deep Inspection

Still on the Entries tab → Click Create entry
Under Entry details:
- Rule number: 200
- Target transit gateway route table: Select tgw-rtb-inspection
Under Rule conditions:
- Source CIDR block: 10.1.20.0/24
- Destination CIDR block: (leave blank)
- Protocol: Select Any (*)
- Source port range: (automatically set to Any — grayed out)
- Destination port range: (automatically set to Any — grayed out)
Click Create entry

Rule 300 — Catch-All → Direct Routing

Still on the Entries tab → Click Create entry
Under Entry details:
- Rule number: 300
- Target transit gateway route table: Select tgw-rtb-default
Under Rule conditions:
- Source CIDR block: (leave blank — matches any)
- Destination CIDR block: (leave blank — matches any)
- Protocol: Select Any (*)
Click Create entry

Step 6: Associate Policy Table with Source VPC Attachment

Select the policy table multi-tier-security-policy
Navigate to the Associations tab
Click Create association
In the Create association modal:
- Transit gateway policy table: Pre-filled
- Transit gateway ID: Pre-filled
- Transit gateway attachment: Select your source workload VPC attachment from the dropdown
Click Create
Wait for state to transition from Associating → Associated

Step 7: Verify the Complete Configuration

Select the policy table multi-tier-security-policy
Entries tab — confirm all three rules appear in correct order:

Rule #	Source CIDR	Dest CIDR	Protocol	Src Port	Dst Port	Target Route Table
100	10.1.10.0/24	*	TCP (6)	*	443	tgw-rtb-firewall
200	10.1.20.0/24	*	*	*	*	tgw-rtb-inspection
300	*	*	*	*	*	tgw-rtb-default

Associations tab — confirm the source VPC attachment shows State: Associated
Test traffic flows:
- From 10.1.10.x host: curl https://10.2.0.100 → should traverse firewall
- From 10.1.20.x host: ping 10.2.0.100 → should traverse IDS/IPS
- From 10.1.30.x host: ping 10.2.0.100 → should route directly

Architecture Diagram

Complete Architecture for Multi-Tier Security Inspection

┌──────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                      │
│                            AWS TRANSIT GATEWAY                                       │
│                                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────────┐  │
│  │                POLICY TABLE: multi-tier-security-policy                        │  │
│  │                                                                                │  │
│  │  ┌─────────────────────────────────────────────────────────────────────────┐   │  │
│  │  │ Rule 100 │ Src: 10.1.10.0/24 │ Proto: TCP │ DstPort: 443                │   │  │
│  │  │          │ → Target: tgw-rtb-firewall                                   │   │  │
│  │  ├─────────────────────────────────────────────────────────────────────────┤   │  │
│  │  │ Rule 200 │ Src: 10.1.20.0/24 │ Proto: Any │ Port: Any                   │   │  │
│  │  │          │ → Target: tgw-rtb-inspection                                 │   │  │
│  │  ├─────────────────────────────────────────────────────────────────────────┤   │  │
│  │  │ Rule 300 │ Src: Any           │ Proto: Any │ Port: Any (Catch-all)      │   │  │
│  │  │          │ → Target: tgw-rtb-default                                    │   │  │
│  │  └─────────────────────────────────────────────────────────────────────────┘   │  │
│  └────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                      │
│         ┌──────────────┐      ┌──────────────┐      ┌──────────────┐                 │
│         │tgw-rtb-      │      │tgw-rtb-      │      │tgw-rtb-      │                 │
│         │firewall      │      │inspection    │      │default       │                 │
│         │              │      │              │      │              │                 │
│         │ 0.0.0.0/0 →  │      │ 0.0.0.0/0 →  │      │ 10.2.0.0/16→ │                 │
│         │ FW-VPC-Att   │      │ IDS-VPC-Att  │      │ Spoke-Att    │                 │
│         └──────┬───────┘      └──────┬───────┘      └──────┬───────┘                 │
│                │                     │                     │                         │
└────────────────┼─────────────────────┼─────────────────────┼─────────────────────────┘
                 │                     │                     │
                 ▼                     ▼                     ▼
┌────────────────────────┐ ┌────────────────────────┐ ┌────────────────────────────┐
│   FIREWALL VPC         │ │   IDS/IPS VPC          │ │   DESTINATION SPOKE VPC    │
│   10.0.100.0/24        │ │   10.0.200.0/24        │ │   10.2.0.0/16              │
│                        │ │                        │ │                            │
│  ┌──────────────────┐  │ │  ┌──────────────────┐  │ │  ┌──────────────────────┐  │
│  │ Next-Gen Firewall│  │ │  │ Suricata/Snort   │  │ │  │ Application Servers  │  │
│  │ (Palo Alto/      │  │ │  │ IDS/IPS          │  │ │  │ Databases            │  │
│  │  Fortinet/AWS    │  │ │  │ Deep Packet      │  │ │  │ Microservices        │  │
│  │  Network FW)     │  │ │  │ Inspection       │  │ │  │                      │  │
│  └──────────────────┘  │ │  └──────────────────┘  │ │  └──────────────────────┘  │
│         │              │ │         │              │ │                            │
│         │ Inspected    │ │         │ Inspected    │ │                            │
│         │ traffic back │ │         │ traffic back │ │                            │
│         ▼ to TGW       │ │         ▼ to TGW       │ │                            │
└────────────────────────┘ └────────────────────────┘ └────────────────────────────┘

                 ▲
                 │  (Associated with Policy Table)
                 │
┌────────────────────────────────────────────┐
│         SOURCE WORKLOAD VPC                │
│         10.1.0.0/16                        │
│                                            │
│  ┌──────────────┐  ┌──────────────┐        │
│  │ PCI Subnet   │  │ SOX Subnet   │        │
│  │ 10.1.10.0/24 │  │ 10.1.20.0/24 │        │
│  │              │  │              │        │
│  │ HTTPS→FW     │  │ ALL→IDS/IPS  │        │
│  └──────────────┘  └──────────────┘        │
│                                            │
│  ┌──────────────┐                          │
│  │ General Sub  │                          │
│  │ 10.1.30.0/24 │                          │
│  │              │                          │
│  │ ALL→Direct   │                          │
│  └──────────────┘                          │
│                                            │
│  TGW Attachment: tgw-attach-source-vpc     │
│  Associated with: Policy Table             │
└────────────────────────────────────────────┘

Limitations

Understanding the limitations helps you design your architecture correctly from the start.

#	Limitation	Details	Workaround
1	Cloud WAN peering attachments	Customer-managed PBR entries are NOT supported on TGW-to-Cloud WAN (CWAN) peering attachments. Only system-managed entries control traffic on these attachments.	Use PBR on other attachment types; rely on Cloud WAN segment policies for CWAN traffic
2	BGP route advertisements stop	Associating a policy table with VPN (Site-to-Site) or Connect attachments stops all BGP route advertisements to the peer	Verify routing impact before associating. Direct Connect is unaffected (uses allowed-prefixes list)
3	Exclusive association	An attachment can have EITHER a policy table OR a route table — never both	Disassociate the route table before associating a policy table
4	System entries take precedence	System-managed entries (from Cloud WAN) always evaluate before customer rules and cannot be modified	Design customer rules knowing they only apply to unmatched traffic
5	Port ranges limited to TCP/UDP	Source and destination port matching only works for TCP (6) and UDP (17). For ICMP, GRE, or Any — ports are always `*`	Use source/destination CIDR for non-TCP/UDP traffic differentiation
6	Rule number range	Rules must be between 1 and 50,000	Use gaps (100, 200, 300) for future insertion flexibility
7	Empty policy table = drop all	An attachment associated with an empty policy table drops ALL traffic	Always add at least one rule (or a catch-all) before associating
8	Referenced route tables cannot be deleted	A TGW route table referenced as a target by any policy entry cannot be deleted	Remove or update policy entries referencing the route table first

Troubleshooting Guide

Problem 1: Traffic is Being Dropped Unexpectedly

Symptoms: Applications lose connectivity after policy table association.

Diagnosis:

Check the PacketDropCountNoPolicy CloudWatch metric — if incrementing, traffic is arriving but no rule matches
Review your policy table entries — is there a catch-all rule?
Verify rule evaluation order — a broader rule at a lower number may be matching before your intended rule

Resolution:

Add a catch-all rule at a high rule number (e.g., Rule 50000) with all attributes set to Any
Reorder rules to ensure specific rules have lower numbers than broad rules

Problem 2: A Rule is Not Matching Traffic as Expected

Symptoms: Traffic bypasses the intended rule and matches a later rule or gets dropped.

Diagnosis:

Verify rule evaluation order — first match wins. A broader rule at a lower number may be shadowing your specific rule
Use GetTransitGatewayPolicyTableEntries API or check the console Entries tab to view ALL entries including system-managed ones
System-managed entries (shown as Rule #: *) evaluate BEFORE your rules

Resolution:

Reorder rules — move specific rules to lower numbers
Check that all match conditions in your rule actually match the traffic (all conditions must match for a rule to apply)
Confirm system-managed entries aren't intercepting your traffic

Problem 3: Port Ranges Are Not Being Applied

Symptoms: Rule matches traffic regardless of port, even though port range is specified.

Diagnosis:

Port ranges are only evaluated when Protocol is TCP (6) or UDP (17)
If Protocol is set to ICMP (1), GRE (47), or Any (*), port values are automatically set to Any and ignored

Resolution:

Set the Protocol field to TCP or UDP explicitly if you need port-based matching
If you submitted port ranges with a non-TCP/UDP protocol via API, the request would be rejected with a validation error

Problem 4: Cannot Delete a Route Table

Symptoms: Route table deletion fails with a dependency error.

Diagnosis:

A TGW route table referenced as a target in any policy table entry cannot be deleted

Resolution:

Use GetTransitGatewayPolicyTableEntries and filter by target-route-table-id to find referencing rules
Update or delete those policy entries to remove the reference
Retry the route table deletion

Problem 5: Cannot Associate a Policy Table to an Attachment

Symptoms: Association request fails or the button is grayed out.

Diagnosis:

The attachment may already have a route table associated — check the attachment's current associations
The attachment type may not be supported (TGW-to-CWAN peering attachments don't support customer PBR)

Resolution:

Disassociate the existing route table first (Transit gateway route tables → Associations tab → Delete association)
Verify the attachment type is supported

Problem 6: Policy Table is Empty and All Traffic is Dropped

Symptoms: After associating a policy table, ALL traffic from that attachment is dropped.

Diagnosis:

An attachment associated with an empty policy table drops all ingressing packets (same behavior as an empty route table)

Resolution:

Add at least one rule to the policy table
Or temporarily reassociate the attachment with a route table to restore connectivity while you configure the policy

Useful CloudWatch Metric for Monitoring

Metric	Namespace	Description
`PacketDropCountNoPolicy`	`AWS/TransitGateway`	Count of packets dropped because no policy rule matched

Customer Benefits and Advantages

1. Granular Traffic Control Without Complexity

Before: Achieving source-based or port-based routing at the transit layer required complex multi-VPC architectures, multiple TGW attachments, and intricate route table management.

Now: A single policy table with ordered rules provides the same (and better) granularity with a fraction of the operational complexity.

2. Significant Cost Optimization

Before: Organizations had to route ALL traffic through expensive security appliances (firewalls, IDS/IPS) because TGW couldn't differentiate traffic types — leading to over-provisioned appliances and unnecessary data processing charges.

Now: Inspect only what needs inspection. If only 20% of your traffic requires firewall inspection, you reduce appliance throughput needs by 80%, directly saving on:

Security appliance licensing costs
EC2 instance sizes for virtual appliances
TGW data processing for unnecessary hops
Network latency for non-inspected traffic

3. Compliance Simplification

Before: Meeting compliance requirements (PCI-DSS, SOX, HIPAA) for traffic inspection required architectural isolation — separate VPCs per compliance tier.

Now: Multiple compliance tiers coexist in the same VPC with different subnets. Policy rules enforce the inspection requirements at the transit layer — auditable, centralized, and simple to demonstrate to auditors.

4. Zero Trust at the Transit Layer

Before: Zero Trust principles were enforced at the instance level (Security Groups) or subnet level (NACLs). The transit layer was permissive by default.

Now: The implicit deny behavior of policy tables means traffic must be explicitly approved for routing. Unauthorized flows are dropped before they reach any VPC — true network-level Zero Trust.

5. Operational Simplicity

Aspect	Benefit
Single point of control	All routing decisions centralized in one policy table
Auditable rules	Clear, ordered rules visible in console and API
No agent required	Works at the network layer — no application changes needed
Immediate effect	Rules apply in real-time — no propagation delay
Reversible	Disassociate policy table to revert to standard routing instantly

6. No Additional Cost

PBR is available at no extra charge beyond standard Transit Gateway fees. There's no per-rule charge, no per-evaluation charge, and no premium tier needed. This makes it accessible to all customers regardless of scale.

7. Multi-Path Traffic Engineering

Network engineers can implement sophisticated traffic engineering patterns directly at the AWS transit layer — routing different application traffic over different network paths based on protocol and port characteristics, similar to what was previously only possible with on-premises SD-WAN solutions.

Best Practices

Rule Design

Practice	Reason
Leave gaps between rule numbers (100, 200, 300)	Allows inserting new rules later without renumbering
Put most specific rules first (lower numbers)	Prevents broad rules from shadowing specific ones
Always include a catch-all rule	Prevents unintended silent drops (unless you specifically want Zero Trust deny-all)
Configure protocol before port ranges	Port ranges only work with TCP/UDP — setting protocol first determines field availability

Operational

Practice	Reason
Use `GetTransitGatewayPolicyTableEntries` to verify	Confirms all entries (including system-managed) and evaluation order
Test with non-production traffic first	Verify rules work as expected before routing production workloads
Monitor `PacketDropCountNoPolicy` metric	Alerts you when traffic is being dropped due to no matching rule
Document your rule purpose	Use naming conventions or external documentation to track why each rule exists
Use IAM conditions for governance	Restrict which attachments can have policy tables associated (tag-based conditions)

Architecture

Practice	Reason
Associate same policy table with multiple attachments	Reuse rule sets across similar traffic sources
Plan return traffic path	Traffic returning from inspection appliances uses destination-based routing on their own route table — ensure routes exist
Consider asymmetric routing	Inspection only happens on ingress to the policy-table-associated attachment — plan accordingly for stateful appliances

Conclusion

AWS Transit Gateway Policy-Based Routing represents a significant advancement in cloud networking capabilities. It bridges the gap between traditional on-premises router functionality (where policy-based routing has been standard for decades) and cloud-native networking.

Key Takeaways:

PBR enables 5-tuple-based routing decisions at the transit layer — something previously impossible in AWS
No additional cost and no activation required — available on all existing Transit Gateways
Dramatically simplifies architectures that previously required complex multi-VPC designs for traffic differentiation
Enables selective security inspection — reducing costs while meeting compliance requirements
Implements Zero Trust at the network transit layer through implicit deny
Compatible with all TGW attachment types except Cloud WAN peering

For organizations running hub-and-spoke or complex multi-VPC architectures with security inspection requirements, PBR eliminates significant architectural complexity while providing more granular control than was previously possible.

Related Resources

Topics: Networking & Content Delivery
Tags: AWS Transit Gateway
Language: English

EXPERT

Vatsal

published 20 days ago337 views

No comments

Relevant content

Troubleshooting EC2 Connectivity Issues Caused by Docker Network CIDR Overlap with Transit Gateway
EXPERT
jonthomascampbell
published 7 months ago
Reducing EDA Data Transfer Costs with a Dedicated Direct Connect Gateway
EXPERT
H_Shah
published 21 days ago
AWS Site-to-Site VPN Configuration Guide for FortiGate Firewalls
EXPERT
tapple (AWS)
published a year ago
How to set transit gateway as Target for the default route “local” route for for inter-subnet (east-west) inspection through firewall deployed in separate networking account
rePost-User-6802861
asked 3 years ago
AWS Transit Gateway Routing Features
Accepted Answer
AWS-User-5108973
asked 7 years ago
Transit Gateway Routes
stevenjwilliams0728
asked 4 years ago
How do I troubleshoot and resolve asymmetric routing and return traffic issues in my transit gateway?
AWS OFFICIALUpdated 7 months ago
How do I troubleshoot Transit Gateway and VPC internet connectivity issues through a centralized egress VPC?
AWS OFFICIALUpdated 7 months ago
How do I migrate my VPN from a virtual private gateway to a transit gateway?
AWS OFFICIALUpdated 4 years ago
How can I achieve ECMP routing with multiple Site-to-Site VPN tunnels that are associated with a transit gateway?
AWS OFFICIALUpdated 3 years ago

AWS Transit Gateway Policy-Based Routing (PBR): Complete Guide to Rule-Based Traffic Forwarding

Introduction

Table of Contents

What is Transit Gateway Policy-Based Routing?

What Changed — Before vs. After PBR

Before PBR (Traditional TGW Routing)

After PBR (What is Now Possible)

Side-by-Side Comparison

Key Concepts

Policy Table

Policy Rules (Entries)

Entry Types

Implicit Deny

How Routing Evaluation Works

Evaluation Order

Key Evaluation Rules

Evaluation Example

Real-World Scenario and Use Cases

Use Case 1: Multi-Tier Security Inspection for Financial Services (Primary Scenario)

Business Requirement

Without PBR (Old Approach — Complex)

With PBR (New Approach — Simple)

Use Case 2: Application-Based Traffic Engineering

Use Case 3: Zero Trust Network Segmentation

Use Case 4: Hybrid Cloud with Selective VPN Inspection

Use Case 5: Multi-Tenant SaaS Isolation

Step-by-Step Implementation (Console)

Prerequisites

Required IAM Permissions

Step 1: Create Target Route Tables

Step 2: Add Routes to Each Route Table

For tgw-rtb-firewall:

For tgw-rtb-inspection:

For tgw-rtb-default:

Step 3: Disassociate Existing Route Table from Source VPC Attachment

Step 4: Create the Policy Table

Step 5: Create Policy Table Entries (Rules)

Rule 100 — PCI HTTPS Traffic → Firewall

Rule 200 — SOX Regulated Traffic → Deep Inspection

Rule 300 — Catch-All → Direct Routing

Step 6: Associate Policy Table with Source VPC Attachment

Step 7: Verify the Complete Configuration

Architecture Diagram

Complete Architecture for Multi-Tier Security Inspection

Limitations

Troubleshooting Guide

Problem 1: Traffic is Being Dropped Unexpectedly

Problem 2: A Rule is Not Matching Traffic as Expected

Problem 3: Port Ranges Are Not Being Applied

Problem 4: Cannot Delete a Route Table

Problem 5: Cannot Associate a Policy Table to an Attachment

Problem 6: Policy Table is Empty and All Traffic is Dropped

Useful CloudWatch Metric for Monitoring

Customer Benefits and Advantages

1. Granular Traffic Control Without Complexity

2. Significant Cost Optimization

3. Compliance Simplification

4. Zero Trust at the Transit Layer

5. Operational Simplicity

6. No Additional Cost

7. Multi-Path Traffic Engineering

Best Practices

Rule Design

Operational

Architecture

Conclusion

Related Resources

Relevant content

For `tgw-rtb-firewall`:

For `tgw-rtb-inspection`:

For `tgw-rtb-default`: