Centralized egress traffic inspection with third-party firewalls and proxy appliances in a multi-account AWS environment
This post shows how to architect centralized egress inspection in a multi-account AWS environment when organizational policy requires third-party firewalls and proxy appliance that does not support GENEVE. It covers how to chain an explicit proxy (fronted by NLB) with NGFWs (behind GWLB) using subnet placement and route table design to deliver defense-in-depth without both appliances needing the same encapsulation protocol.
Enterprise organizations running on AWS often need strict security controls on all outbound traffic. Many run dedicated egress accounts where next-generation firewalls (NGFWs) inspect packets and forward proxy appliances handle URL filtering, content inspection, and data loss prevention (DLP). Infrastructure and security teams frequently mandate specific proxy products due to organizational policy, compliance obligations, or existing license investments, leaving limited flexibility to switch tooling.
AWS Network Firewall proxy provides a managed alternative for customers without these constraints (see Securing Egress Architectures with Network Firewall Proxy ). This post addresses organizations that must use third-party firewalls to stay cloud-agnostic and whose infrastructure teams require specific forward proxy appliances, such as Secure Web Gateways (SWGs) that do not support the Generic Network Virtualization Encapsulation (GENEVE) protocol. Integrating these appliances into a centralized egress path is the problem we solve here.
This post covers how to architect centralized egress inspection using AWS Transit Gateway (TGW), AWS Gateway Load Balancer (GWLB), third-party NGFWs, and an explicit forward proxy that lacks GENEVE support.
Architecture overview
Figure 1. Centralized egress inspection with third-party firewall (GWLB) and explicit forward proxy (NLB)
Components:
● AWS Transit Gateway (TGW) - Central routing hub across workload accounts and the egress account.
● AWS Gateway Load Balancer (GWLB) - Distributes traffic to NGFW appliances using GENEVE encapsulation.
● Gateway Load Balancer Endpoints (GWLBe) - Next-hop targets in VPC route tables, backed by AWS PrivateLink.
● Third-party NGFWs - EC2-based firewalls behind GWLB. Require GENEVE support.
● Explicit forward proxy / SWG - EC2-based proxy handling HTTP CONNECT requests. No GENEVE support.
● Network Load Balancer (NLB) - Fronts the proxy fleet at Layer 4. Cannot be used as a route table target.
● NAT Gateway - Internet exit point after both inspection tiers complete.
Proxy deployment model
This design uses an explicit forward proxy. Workloads open HTTP CONNECT tunnels to the proxy on a designated port. The proxy terminates the inbound connection, applies policy, then opens a separate connection to the destination. That termination and reinitiation means the proxy naturally performs source network address translation (SNAT). If Transport Layer Security (TLS) inspection is enabled, the proxy presents a generated certificate to the client, so workloads must trust the proxy certificate authority (CA).
Note: Transparent proxy mode is an alternative that preserves original source IPs for firewall visibility but adds routing complexity and requires disabling source/destination checks. This post covers explicit proxy, where SNAT causes the firewall to see only the proxy's IP as the source.
Transit Gateway design and traffic symmetry
A single TGW shared via AWS Resource Access Manager (RAM) connects workload VPCs to the egress VPC. Two route tables handle segmentation:
● Spoke route table - Attached to workload VPC connections. Default route points to the egress VPC attachment.
● Egress route table - Attached to the egress VPC connection. Has specific routes for workload CIDRs pointing back to spoke attachments.
Appliance mode must be enabled on the egress VPC attachment. Without it, TGW hashes flows across Availability Zones (AZs) and forward/return traffic can land on different firewall instances. A firewall that receives return traffic for a session it never established will drop the packet. Appliance mode pins both directions of a flow to the same AZ.
Symptoms of broken symmetry: TCP resets (firewall sees data without a SYN), silent drops on unknown sessions, and intermittent failures affecting a subset of flows. Verify with VPC Flow Logs on TGW attachment and firewall subnets.
Egress traffic flow
Workload VPC → TGW → Egress VPC → Proxy/SWG (via NLB) → GWLB (firewall) → NAT Gateway → Internet
Proxy runs first in the chain. Unauthorized URLs and policy violations get caught before consuming firewall cycles.
Step 1: Workload to Transit Gateway
Workload VPCs carry a default route to the TGW. The spoke route table sends internet-bound traffic to the egress VPC attachment.
Step 2: Workload to proxy via NLB
Workloads address the NLB directly through their proxy configuration (environment variables, Proxy Auto-Configuration (PAC) file, or application settings). Traffic reaches the NLB via normal VPC routing. No route table manipulation is involved.
Key point: NLB cannot be a route table target. Valid route targets are NAT Gateway, TGW, GWLBe, elastic network interface (ENI), VPC endpoint, and VPC peering. Traffic reaches the proxy because applications are configured to send it there, not because a route entry steers it.
The proxy evaluates outbound requests against URL filtering rules, DLP policies, TLS inspection (if configured), and category-based access controls.
Step 3: Proxy to firewall via GWLB
After the proxy allows the request, it opens its own connection to the destination. The proxy's IP becomes the source (SNAT). The proxy subnet route table points 0.0.0.0/0 to the GWLBe, steering that outbound traffic into the firewall tier. GWLB encapsulates with GENEVE and distributes across the NGFW fleet. After inspection, traffic returns via GWLB hairpin to the post-inspection subnet.
Step 4: Firewall to internet via NAT Gateway
Post-inspection subnet routes 0.0.0.0/0 to the NAT Gateway. NAT translates the source (proxy IP) to its Elastic IP and sends traffic to the internet.
Return traffic follows the reverse path: NAT Gateway performs reverse translation (EIP back to proxy IP). The NAT Gateway subnet routes the proxy subnet CIDR to GWLBe, sending return traffic through the firewall for inspection. After inspection, GWLBe delivers the packet to the proxy via local VPC routing. The proxy correlates the response with the original client session and responds to the workload through TGW.
Egress VPC route table summary
| Route table | Destination | Target |
|---|---|---|
| TGW attachment subnet | Workload CIDRs | TGW |
| Proxy subnet (egress) | 0.0.0.0/0 | GWLBe |
| Proxy subnet (egress) | Workload CIDRs | TGW |
| Post-inspection subnet | 0.0.0.0/0 | NAT Gateway |
| NAT Gateway subnet | Proxy subnet CIDR | GWLBe (return-path inspection) |
Why proxy subnet CIDR for return traffic? The proxy performs SNAT. All outbound traffic uses the proxy's IP as source. When return traffic arrives at the NAT Gateway, it reverse-translates to the proxy IP, not a workload IP. The NAT Gateway subnet routes that traffic to GWLBe for return-path firewall inspection before delivery to the proxy.
Handling the non-GENEVE proxy constraint
The proxy cannot sit behind GWLB because it does not speak GENEVE. That is the central constraint. It means GWLB cannot distribute traffic to the proxy, you need a separate load balancing layer, and the architecture must chain two inspection tiers that use different protocols.
Solution:
● NLB fronts the proxy fleet. Layer 4 distribution, no GENEVE dependency. Health checking and cross-zone balancing included.
● Separate subnets per tier. Each tier gets its own subnet and route table. This is what makes the chaining work.
● Explicit addressing instead of route steering. Workloads point at the NLB through proxy config. The route table only matters after the proxy initiates its outbound connection (proxy subnet 0.0.0.0/0 -> GWLBe).
● Source/destination checks stay enabled. Explicit proxy terminates connections, so all traffic on its ENI uses its own IP.
Simplifying with explicit proxy configuration
The explicit proxy model sidesteps the hardest part of traffic steering. Workloads connect to the proxy directly. No route table entry needed to get traffic there. Configuration options:
● Environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
● PAC files for conditional proxy selection
● AWS Systems Manager for fleet-wide push
Trade-offs: requires changes in every workload, non-HTTP protocols bypass the proxy, and you need a NO_PROXY list for internal endpoints (Amazon Simple Storage Service (S3) gateway endpoints, AWS Security Token Service (STS), instance metadata).
For workloads that cannot use explicit proxy configuration, route the TGW attachment subnet default route to the proxy ENI directly. That is a valid route target. It requires disabling source/destination checks and reintroduces routing complexity.
High availability and failover considerations
● Deploy across at least two AZs. Per-AZ GWLBe endpoints and NAT Gateways.
● Proxy tier: NLB detects instance failures within seconds. Active sessions on a failed instance are lost (the proxy holds TCP state for both sides). Auto Scaling replaces instances; clients reconnect.
● Firewall tier: GWLB removes unhealthy targets. Session survival during replacement is vendor dependent. GWLB flow stickiness limits blast radius to flows pinned to the failed target.
● AZ-level failure: Appliance mode pins the flows to an AZ. If that AZ loses all firewalls, those flows break until clients reconnect through a healthy AZ. GWLB cross-zone load balancing can mitigate this at the cost of cross-AZ data transfer.
DNS considerations
With explicit proxy, the proxy resolves destination domains, not the workload. Workloads only need to resolve the NLB address. Confirm the proxy subnet can reach Amazon Route 53 Resolver (use outbound endpoints for on-premises DNS). Enable query logging in the egress VPC for audit. Watch for split-horizon DNS returning wrong addresses to the proxy.
Getting started
What you need before you start
An AWS Organization with a dedicated egress account. TGW shared via RAM. NGFW instances that support GENEVE (Palo Alto VM-Series, Fortinet FortiGate, and Check Point are common choices). Your proxy/SWG Amazon Machine Image (AMI). Subnets planned across at least two AZs in the egress VPC.
Setting up the Transit Gateway
Create the TGW and share it with your organization. Set up two route tables: one for spokes (default route to egress VPC attachment) and one for the egress VPC (workload CIDRs pointing back to spoke attachments). Enable appliance mode on the egress VPC attachment. This setting is easy to miss during initial deployment and hard to troubleshoot later when flows start failing intermittently.
Deploying the firewall tier
Stand up GWLB in the firewall subnets across your AZs. Register your NGFW instances as targets. Create GWLBe endpoints in the post-proxy subnets, one per AZ. These endpoints become the next hop in the proxy subnet route table and are what connects the proxy tier to the firewall tier.
Deploying the proxy tier
Launch proxy instances in the proxy subnets. Put an internal NLB in front of them. NLB is the right choice here because it operates at Layer 4, does not require GENEVE from its targets, and provides the health checking and distribution you need without adding protocol complexity. Configure listeners on your designated proxy port.
Wiring up the route tables
The route table summary above has the full picture. The two entries that matter most: proxy subnet sends 0.0.0.0/0 to the GWLBe (this is how post-proxy traffic enters the firewall), and NAT Gateway subnet sends proxy subnet CIDR to GWLBe (this ensures return traffic gets inspected on the way back). Get these wrong and sessions will fail silently or intermittently.
Configuring workloads
Push proxy settings to workloads via environment variables, PAC files, or Systems Manager. Set NO_PROXY to exclude internal AWS endpoints that should not traverse the proxy (S3 gateway endpoints, STS, instance metadata at 169.254.169.254). If TLS inspection is enabled, distribute the proxy CA certificate to workload trust stores.
Validating the setup
Confirm outbound requests from a workload show up in proxy logs first, then NGFW logs, and exit through the NAT Gateway. If requests time out, check the proxy subnet route table (0.0.0.0/0 should point to GWLBe). If connections reset intermittently, verify appliance mode is enabled and check for asymmetric flow logs across AZs.
Operational guidance
VPC Flow Logs on all egress subnets and TGW Flow Logs give you baseline visibility. GWLB and NLB both publish health and throughput metrics to Amazon CloudWatch. Forward NGFW and proxy logs to your security information and event management (SIEM) solution for correlation.
Cost drivers: TGW and GWLB data processing, NLB and NAT Gateway hourly charges, and EC2 compute for the appliance fleet. Route AWS service traffic through VPC endpoints to bypass the egress path and reduce processing charges.
This architecture addresses network-level egress controls. Additional guardrails such as Service Control Policies (SCPs) and VPC endpoint policies are needed to prevent workloads from bypassing the proxy path. Non-proxy-aware traffic is out of scope for this post.
Conclusion
This post covered centralized egress inspection for organizations that must run third-party firewalls and policy-mandated proxy appliances. The decisions that matter:
● NLB is not a route table target. Workloads reach the proxy through explicit configuration, not route steering.
● Proxy subnet route table chains traffic to GWLBe, connecting the two inspection tiers without requiring both to support GENEVE.
● Appliance mode pins the flows to an AZ, maintaining symmetric routing through stateful firewalls.
● DNS resolution moves to the proxy. Route 53 Resolver in the egress VPC must be configured to support this.
Organizations without a hard requirement for specific third-party products should evaluate AWS Network Firewall proxy to eliminate the operational overhead of self-managed appliance fleets.
Additional resources
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article