One Firewall, Two Modes: What AWS's Rebuilt Egress Proxy Actually Fixes

On 25 November 2025, AWS’s Networking & Content Delivery blog introduced a new standalone service: AWS Network Firewall proxy, a managed way to stop running your own Squid fleet just to get domain-aware egress filtering. On 4 August 2026 the same team published a second post whose first job was to quietly take the first one apart. A banner now sits at the top of the November post: “We’ve updated the Network Firewall proxy preview based on customer feedback. The proxy is now a native capability of AWS Network Firewall rather than a standalone product.” A little over eight months from launch to un-launch is not a long product lifecycle — it’s barely enough time to finish arguing about the re:Invent keynote. What happened in between, and what the rebuilt version does differently, is a sharper lesson in centralised-egress architecture than either post spells out directly.

The problem: NAT Gateway doesn’t know what a domain name is

Centralising outbound traffic control is one of those requirements that shows up in every landing-zone design review and gets solved badly more often than not. The compliance ask is simple: nobody’s workload should be able to reach an arbitrary destination on the internet, and every attempt should be filterable by domain, not just by IP and port. NAT Gateway, AWS’s default answer to “how do private subnets reach the internet,” does not do this. Read AWS’s own documentation for it end to end and the job described is address translation and connection accounting — how many Elastic IPs you can attach, how many simultaneous connections a single IP supports, how to add secondary addresses when you run out of ports. There’s no mention of a domain name anywhere on the page, because NAT Gateway operates below the layer where domain names exist. It translates a private address to its own and back; it has no opinion on whether that connection was headed to a legitimate API endpoint or a data-exfiltration destination someone stood up an hour ago.

Getting domain-aware filtering has always meant putting something else in the path: a self-managed proxy fleet, or AWS Network Firewall running in what AWS calls source-preservation mode — the default, where the firewall sits inline via VPC route tables, inspects with a Suricata-compatible stateful rules engine that supports domain filtering and 5-tuple rules, and forwards traffic on with the original source and destination IPs untouched. That’s a real, well-documented answer to “filter by domain,” and thousands of VPCs already run it. It doesn’t answer the second half of the landing-zone requirement: doing all of that centrally, once, for every VPC in an organisation, when those VPCs weren’t all carved from the same address plan.

The challenge: source-preservation breaks the moment two VPCs share a CIDR

Centralising anything across a multi-account estate runs into the same wall eventually: AWS’s routing constructs all key off destination CIDR, and enterprise VPC estates are never as tidy as the reference-architecture diagram assumes. Anyone who has tried to peer two VPCs provisioned years apart by different teams has hit the resulting hard rule directly: “You cannot create a VPC peering connection between VPCs that have matching or overlapping IPv4 or IPv6 CIDR blocks.” Transit Gateway route tables are more flexible than a peering connection, but they’re built on the same primitive — a route table entry matches a destination prefix, and nothing about that primitive can disambiguate two spoke VPCs that both happen to be 10.0.0.0/16, an address plan that keeps recurring because it’s the first example in every AWS tutorial.

Source-preservation mode inherits that limitation rather than fixing it. If a centralised firewall keeps every client’s original source IP intact all the way through inspection, whatever sits downstream — a shared NAT path, a partner allow-list, logging that keys on source IP — still has to tell apart two clients that, on paper, carry the identical address. You can solve this with enough per-spoke NAT and route table surgery, and plenty of landing zones do exactly that. It’s the kind of bespoke plumbing that made a managed egress proxy attractive in the first place, and it’s also the kind of plumbing the original standalone Network Firewall proxy preview never touched — it added a new product with its own policy surface to keep in sync with whatever Network Firewall policy a team was already running for transparent inspection, without doing anything about the underlying address-collision problem. Two policies to maintain and one problem left unsolved is a rough trade to ask an architecture team to make for a preview feature.

The solution: one firewall, and a proxy that owns its own address

The August rebuild changes two things at once, and the second is more interesting than the first. First, the policy surface: explicit proxy is now a deployment mode you choose when you create a Network Firewall, called no-source-preservation, sitting alongside the existing source-preservation default. Same firewall resource, same firewall policy, same Suricata-compatible rule groups, same AWS-managed threat-intelligence and domain-reputation lists. AWS’s own framing is direct: “the explicit proxy inherits everything Network Firewall already offers, and you can use the same security policy, and even the same firewall, for both transparent firewalling and explicit proxying.” The duplicate-policy problem from the standalone preview is gone by construction, not by discipline.

Second, and this is the part that actually solves the overlapping-CIDR wall: a no-source-preservation firewall attaches directly to a NAT Gateway. It terminates each client’s connection, inspects it, and re-establishes a new connection to the destination using the attached NAT Gateway’s own IP address as the source — masking the client’s original address entirely. AWS states the consequence plainly: “With this mode, you can centralize egress even from networks with overlapping CIDRs.” By the time traffic leaves the firewall, it no longer carries an address that could collide with anything downstream. Every client funnelled through a given no-source-preservation firewall looks identical to whatever comes next — one NAT Gateway IP, regardless of how many differently-addressed VPCs fed it.

Reaching the proxy doesn’t touch a route table at all, which is its own small relief for anyone who has had to thread a route table change through a change-advisory board. Clients get a firewall-assigned FQDN and connect to it via a PrivateLink VPC endpoint association, pointing standard http_proxy/https_proxy environment variables at that hostname on the default listener ports — 3128 for HTTP, 8443 for HTTPS. One architectural detail worth knowing before you design around it: in no-source-preservation mode, the stateless rules engine sits out entirely. HTTP CONNECT requests go straight to the stateful, Suricata-compatible engine, so any 5-tuple stateless rules you lean on for cheap early-drop filtering simply don’t apply to proxied traffic — plan rule groups with that gap in mind rather than discovering it during an incident.

None of this is finished yet. No-source-preservation mode is public preview, available in exactly one Region — US East (Ohio), us-east-2 — and AWS caps it at one endpoint per firewall for the duration of preview, with the NAT Gateway and the firewall’s access endpoint required to sit in the same Availability Zone. You also commit to a deployment mode at firewall creation time; there’s no migrating an existing source-preservation firewall into no-source-preservation later, only standing up a second firewall resource. And the NAT Gateway doing the address-masking is still a NAT Gateway underneath: AWS’s documented ceiling is 55,000 simultaneous connections per unique destination for each of its IPv4 addresses, extendable to eight addresses total by adding secondary IPs. Centralise enough VPCs behind one no-source-preservation firewall talking to one popular destination, and that ceiling — not the firewall’s inspection throughput — is what you’ll hit first.

The footprint

AWS didn’t fix a bug here; it recognised the wrong product boundary and moved it, in public, eight months into a preview. That’s worth remembering next time a re:Invent launch shows up in a design review as a settled decision — preview status means the shape of the thing is still negotiable, sometimes structurally.

For anyone running or planning centralised egress filtering, the concrete change is this: stop scoping a proxy as a separate acquisition from your firewall estate. If you’re already running Network Firewall for transparent, centralised VPC inspection behind Transit Gateway, a no-source-preservation firewall extends that same policy surface to explicit-proxy clients instead of bolting on a second product to keep in sync. And if overlapping CIDR blocks are the reason your organisation never finished a centralised-egress project, that’s no longer a permanent excuse — it’s a preview-Region constraint with a documented exit ramp. Build the pilot in us-east-2, size it against the NAT Gateway connection ceiling rather than assuming the firewall is the bottleneck, and treat GA — whenever it lands — as the expansion of a validated pattern, not a leap of faith.