# AWS Network Firewall as Forward Proxy: Technical Review of the Preview

AWS has reintroduced forward proxy as a native functionality of Network Firewall, unifying security policies between transparent and explicit proxy modes under a single resource. This review examines what changed from the November 2025 preview, where the functionality genuinely adds value in financial-grade environments, and where operational risks still warrant caution.

- URL: https://fernando.moretes.com/blog/aws-network-firewall-como-forward-proxy-analise-tecnica-do-preview-preview-anno

- Markdown: https://fernando.moretes.com/blog/aws-network-firewall-como-forward-proxy-analise-tecnica-do-preview-preview-anno/article.md?lang=en

- Published: 2026-08-05T09:03:48.410Z

- Category: AI & Agents

- Tags: network-firewall, forward-proxy, egress-security, zero-trust, eks, financial-grade, aws-security, no-source-preservation

- Reading time: 11 min

- Source: [[Preview Announcement] Re-introducing Forward Proxy as AWS Network Firewall Functionality](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-network-firewall-forward-proxy-preview/)

---

In November 2025, AWS launched Network Firewall Proxy as a separate product — with its own policy, disconnected from the existing transparent firewall. Customer feedback was direct: nobody wants to manage two diverging security policies for the same egress perimeter. In August 2026, AWS listened and reintroduced proxy as a Network Firewall functionality, unified under the same firewall policy, in a new deployment mode called no-source-preservation. This review goes beyond the announcement: I examine what this convergence means for egress architectures in financial-grade environments, the real trade-offs of no-source-preservation mode, and why the 'single policy' detail matters more than it appears on the surface.

## Evolution Context: From Bifurcation to Convergence

- **Nov 2025** — First preview — separate product. Proxy with its own policy, disconnected from transparent firewall
- **Ago 2026** — Reintroduced as unified functionality. Same firewall policy for explicit proxy and transparent firewall
- **1 policy** — Single policy for both modes. Managed rule groups, Geo-IP, domain filtering, EKS/ECS container rules
- **us-east-2** — Region available in preview. US East (Ohio) — free during preview period

## What no-source-preservation Mode Is and Why the Name Matters

Network Firewall has traditionally operated in **transparent firewall** mode: traffic passes through the appliance without the source IP being altered, which requires controlled asymmetric routing via Gateway Load Balancer or specific route tables. The client (workload) doesn't need to know a proxy exists — hence 'transparent'. The new **no-source-preservation** mode inverts this premise: the Network Firewall acts as an **explicit forward proxy**, meaning the client's TCP connection terminates at the firewall and a new connection is originated toward the destination. The source IP seen by the destination server is the firewall's own IP, not the originating workload.

This behavior has direct implications in financial-grade environments. First, it eliminates the need for forced symmetric routing — one of the largest sources of operational complexity in hub-and-spoke topologies with Transit Gateway. Second, it enables real **TLS inspection** with actual session termination, which is a prerequisite for any application-layer payload inspection required by frameworks like PCI-DSS and SOC 2. Third, and more subtly, it changes the network identity model: downstream flow logs will see the firewall's IP, not the originating pod or instance — which directly impacts event correlation in SIEMs like Splunk or OpenSearch.

The name 'no-source-preservation' is technically precise and operationally honest: if you depend on source IP for audit correlation, you need to instrument the firewall as the central log collection point, not rely on destination logs to trace the real origin of a request.

## The Design Decision That Actually Matters: Unified Policy

When AWS launched the proxy in November 2025 as a separate product with its own policy, the problem wasn't just operational — it was a **security drift** problem. In any financial-grade environment with multiple teams operating over the same infrastructure, two security policies that should be equivalent will inevitably diverge. A Geo-IP rule updated in the transparent firewall policy may not be replicated in the proxy policy. A new managed rule group added by a SecOps team may cover only one of the two modes. The result is an asymmetric attack surface that is difficult to audit and even harder to justify to a CISO or external auditor.

Unification under a single **firewall policy** resolves this problem structurally. The policy becomes the single source of truth for both operating modes. This has immediate value across three dimensions: (1) **audit and compliance** — a single resource to track in AWS Config, CloudTrail, and Security Hub; (2) **IaC automation** — a single Terraform or CloudFormation block to manage rules, eliminating the need for duplicate modules with synchronization logic; (3) **incident response** — when a SOC analyst needs to block a domain in real time via AWS Firewall Manager, the change propagates to both modes simultaneously.

From a Well-Architected perspective, this is a direct gain in the **Operational Excellence** pillar: it reduces the number of distinct resources to monitor, simplifies the change runbook, and eliminates an entire class of configuration errors by omission. For teams already using AWS Firewall Manager for centralized management across multiple accounts, the unified policy is what makes proxy viable at organizational scale.

## Egress Architecture with Network Firewall in Forward Proxy Mode

Hub-and-spoke topology with Transit Gateway. Network Firewall operates in no-source-preservation (explicit proxy) in the centralized egress VPC. EKS and ECS workloads configure the proxy explicitly via HTTP_PROXY environment variable. The single policy covers managed rules, Geo-IP, domain filtering, and container attribute rules.

### 🏢 Spoke VPCs — Workload Accounts

- EKS Pod HTTP_PROXY set (compute)
- ECS Task HTTP_PROXY set (compute)

### 🔀 Transit Layer

- Transit Gateway Route Table (network)

### 🔒 Egress VPC — Security Hub Account

- AWS Network Firewall no-source-preservation explicit proxy :8080 (security)
- Unified Firewall Policy Managed Rules + Geo-IP Domain Filter + EKS/ECS Rules (security)
- NAT Gateway (post-inspection) (network)

### 📊 Observability & Governance

- CloudWatch Logs Alert + Flow Logs (data)
- AWS Firewall Manager Centralized Policy (security)
- AWS Config Compliance Rules (security)

### 🌐 External Destinations

- Internet Allowed Domains (external)
- Blocked Geo-IP / Category (external)

### Flows

- eks_pod -> tgw: CONNECT :8080 (explicit proxy)
- ecs_task -> tgw: CONNECT :8080 (explicit proxy)
- tgw -> anfw: routed to egress VPC
- anfw -> policy: evaluates unified policy
- anfw -> nat_gw: allowed traffic
(firewall IP as source)
- nat_gw -> internet: inspected egress
- anfw -> blocked: DROP — Geo-IP / category
- anfw -> cw_logs: alert + flow logs
- fw_manager -> policy: distributes policy
- config -> anfw: evaluates compliance

## Where Proxy Mode Genuinely Outperforms Transparent Firewall

The transparent firewall has a structural limitation that rarely appears in marketing documentation: it relies on **FQDN-based rules** that resolve DNS at rule evaluation time. In environments where applications use aggressive connection pooling, CDNs with short TTLs, or dynamic IPs (like many third-party APIs in fintech), the transparent firewall can allow traffic to IPs that no longer correspond to the FQDN resolved when the rule was created. This problem is known as the **DNS rebinding window** and is one of the reasons explicit proxy is preferred in mature Zero Trust architectures.

Proxy mode resolves this differently: since the TCP connection terminates at the firewall, it can inspect the **SNI (Server Name Indication)** from the TLS ClientHello or the HTTP `Host` header before establishing the outbound connection. This means the allow/deny decision is based on the actual domain name the client is trying to reach, not a prior DNS resolution. For PCI-DSS environments that need to guarantee no card data leaves to unauthorized domains, this distinction is fundamental.

Furthermore, the **container attribute-based rules for EKS and ECS** — mentioned in the announcement — gain a new dimension in proxy mode. In transparent firewall, identifying which specific pod originated a connection requires correlation between VPC Flow logs and Kubernetes metadata, which is fragile at scale. In proxy mode, the workload makes an explicit connection to the proxy, and the firewall can log connection context more deterministically. This simplifies traceability in security audits where you need to prove that a specific container did not access an unauthorized endpoint during a defined time period.

## Strengths of the Unified Functionality

- **Single policy, zero drift**: one firewall policy covers both transparent and explicit proxy — managed rule groups, Geo-IP, domain category filtering, and container attribute rules are configured once and applied to both modes.
- **Real TLS inspection**: session termination at the firewall enables application-layer payload inspection, enabling data exfiltration detection in HTTPS traffic — a direct PCI-DSS and SOC 2 requirement.
- **Elimination of forced symmetric routing**: no-source-preservation mode simplifies hub-and-spoke topologies, removing the need for Gateway Load Balancer for centralized egress inspection.
- **Active threat defense and managed rule groups**: the same AWS-managed threat intelligence capabilities (including IP and domain reputation feeds) applied uniformly to proxy traffic.
- **Native Firewall Manager integration**: policy centrally distributed across multiple accounts and VPCs, with compliance trackable via AWS Config and Security Hub.
- **SNI/Host header-based decisions**: eliminates the DNS rebinding window present in transparent firewall, strengthening egress controls in Zero Trust architectures.

> **Real Limitations You Need to Know Before Adopting:** **1. Source IP not preserved — audit impact**: In no-source-preservation mode, the destination server sees the firewall's IP, not the workload's. If you have third-party systems that allowlist by source IP (common in banking APIs and payment gateways), you'll need to renegotiate those agreements or maintain a separate egress path for that traffic. Additionally, destination logs won't serve for incident correlation — you depend 100% on Network Firewall logs as the source of truth.

**2. Preview in single region**: Available only in us-east-2 (Ohio) at announcement time. For financial environments with data residency requirements in other regions (especially sa-east-1 for Brazilian operations), production adoption is not yet viable.

**3. Explicit proxy configuration on the client**: Unlike transparent firewall, explicit proxy mode requires each workload to configure `HTTP_PROXY` / `HTTPS_PROXY`. In EKS environments with hundreds of deployments, this requires a centralized injection mechanism (admission webhook, Kustomize patch, or environment variables via ConfigMap) — without this, workloads that don't configure the proxy simply bypass inspection.

**4. Compatibility with non-HTTP protocols**: Explicit forward proxy works for HTTP/HTTPS via the CONNECT method. Non-HTTP TCP/UDP traffic (such as direct database connections, SFTP, or proprietary protocols) doesn't go through the proxy and requires transparent firewall in parallel — which reintroduces the complexity of two operating modes.

**5. Still in preview**: No availability SLA, no production support, no API stability guarantee. Do not use on workloads that process production data.

## The Threat Model This Functionality Addresses — and What Remains Open

The announcement explicitly mentions two use cases: **data exfiltration** and **malware injection**. It's worth decomposing what the forward proxy actually resolves for each of these vectors, because the answer is not binary.

For **data exfiltration**, explicit proxy with TLS inspection is genuinely effective against exfiltration via HTTP/HTTPS to unauthorized domains. A malicious agent attempting to use `curl` or an HTTP library to send data to an external endpoint will be blocked if the domain is not on the allowlist. However, exfiltration via DNS (DNS tunneling), via non-HTTP protocols, or via authorized SaaS services (such as exfiltrating data to a public S3 bucket via AWS SDK) is not covered by the forward proxy — it requires complementary controls like Route 53 Resolver DNS Firewall for the first case and VPC endpoint policies for the third.

For **malware injection**, the proxy with TLS inspection can detect malicious payloads in HTTP/HTTPS responses using AWS managed rule groups or custom Suricata rules. This is relevant for supply chain attack scenarios where an npm or PyPI package dependency serves a malicious payload. Effectiveness depends directly on signature quality and the ability to inspect TLS traffic — which requires careful certificate pinning configuration on clients that verify the server certificate.

What remains open: **lateral movement** within the VPC is not affected by the egress proxy. East-west communication between pods in the same EKS cluster, or between services in VPCs connected via VPC Peering, does not pass through Network Firewall in proxy mode. For this vector, the correct answer is Kubernetes Network Policy (Cilium or AWS VPC CNI with network policy) combined with Security Groups per pod — not the forward proxy.

## Transparent Firewall vs. Explicit Proxy (no-source-preservation): Technical Comparison
| Criterion | Dimension | Transparent Firewall | Explicit Proxy (no-source-preservation) |
| --- | --- | --- | --- |
| Client configuration | None — transparent to the workload | HTTP_PROXY / HTTPS_PROXY required | — |
| Source IP at destination | Original workload IP preserved | Firewall IP (source not preserved) | — |
| TLS inspection | SNI-based without session termination | Real TLS session termination — payload inspection | — |
| DNS rebinding window | Present — rules based on prior DNS resolution | Eliminated — decision based on SNI/Host header | — |
| Supported protocols | Generic TCP/UDP + HTTP/HTTPS | HTTP/HTTPS via CONNECT — non-HTTP requires transparent in parallel | — |
| Routing complexity | Forced symmetric routing — GWLB or specific route tables | Simplified — no symmetric routing requirement | — |
| Security policy | Unified firewall policy (after Aug 2026) | Same unified firewall policy | — |

## How to Adopt Forward Proxy in a Financial Environment: Recommended Sequence

1. **1. Validate the threat model before any configuration** — Map the exfiltration vectors relevant to your environment: HTTP/HTTPS to external domains, DNS tunneling, non-HTTP protocols. The forward proxy addresses only the first. For the others, define complementary controls (DNS Firewall, VPC endpoint policies) before assuming the proxy covers everything.

2. **2. Audit all workloads that need to configure HTTP_PROXY** — In EKS, use an admission webhook (e.g., OPA Gatekeeper or Kyverno) to ensure all Deployments and StatefulSets have HTTP_PROXY and HTTPS_PROXY variables injected. Workloads without this configuration silently bypass inspection — this is a security risk, not just an operational gap.

3. **3. Configure the unified firewall policy with full logging mode** — Start with action=ALERT (not DROP) for all domains not explicitly allowed. Collect logs in CloudWatch Logs with minimum 90-day retention (PCI-DSS requires 12 months in cold storage). Use CloudWatch Metric Filters to create alarms on access attempts to blocked categories — this generates the baseline of legitimate traffic before hardening rules.

4. **4. Identify and handle non-HTTP traffic before enabling exclusive mode** — Use VPC Flow Logs with Athena analysis to identify TCP/UDP connections that don't go through HTTP. For each identified protocol, decide: (a) migrate to a VPC endpoint if it's an AWS service, (b) maintain transparent firewall in parallel for that specific traffic, or (c) block if it's not legitimate traffic.

5. **5. Implement log correlation to compensate for source IP loss** — Configure Network Firewall to log full connection context, including container metadata when available via container attribute rules. Integrate with your SIEM (Splunk, OpenSearch, or Datadog) using an ingestion pipeline that correlates the timestamp and source port in firewall logs with pod application logs to reconstruct the identity of the originating workload.

6. **6. Progressively harden rules and automate via Firewall Manager** — After 2-4 weeks of baseline in ALERT mode, move to DROP the domains and categories not observed in legitimate traffic. Use AWS Firewall Manager to distribute the updated policy across all AWS Organizations accounts, with Security Hub recording compliance deviations in real time.

## Analysis Through the AWS Well-Architected Lens

- **security**: Direct gain: real TLS inspection, SNI-based decisions (no DNS rebinding window), unified policy eliminating drift between modes. Residual risk: workloads without HTTP_PROXY configured silently bypass inspection — requires compensating control via admission webhook. Non-HTTP traffic remains out of proxy scope.
- **reliability**: Network Firewall is a managed service with high availability by design. No-source-preservation mode does not introduce new failure points relative to transparent firewall. The availability risk lies in the proxy dependency for all HTTP/HTTPS traffic — a misconfigured firewall can block legitimate traffic at scale.
- **sustainability**: Consolidation of controls in a single managed service (vs. multiple third-party proxy appliances) reduces computational overhead and simplifies infrastructure inventory — aligned with the resource efficiency principle of the sustainability pillar.

## Anti-Patterns to Avoid When Adopting Forward Proxy

- **Assuming proxy completely replaces transparent firewall**: Non-HTTP traffic (direct connections to RDS, SFTP, proprietary protocols) doesn't go through explicit proxy. Disabling transparent firewall before mapping all non-HTTP traffic creates immediate security gaps.
- **Relying on destination logs for incident correlation**: In no-source-preservation mode, the source IP in destination logs is the firewall's. Building incident response runbooks that depend on destination logs to identify the originating workload will result in inconclusive investigations.
- **Deploying to production during preview**: The service is in preview without an availability SLA. Financial environments with contractual uptime requirements (99.9%+) should not use preview features for production traffic.
- **Not instrumenting HTTP_PROXY injection as a security control**: Treating HTTP_PROXY configuration in workloads as an optional DevOps task is a mistake. Workloads without this configuration bypass inspection — this must be audited via admission webhook and treated as a mandatory security control.
- **Enabling DROP immediately without traffic baseline**: Starting with DROP action without an observation period in ALERT mode guarantees legitimate traffic disruption. Always collect baseline for 2-4 weeks before hardening rules in production environments.

> **Curator's Note: What I Would Actually Do:** In financial-grade environments where I operate, the decision to adopt the unified forward proxy isn't about the feature itself — it's about the right timing. Policy unification is the correct architectural change, and I would have pushed for it since the November 2025 preview. But no-source-preservation mode in preview in a single region still doesn't justify migrating production workloads: the most expensive lesson I've learned in PCI-DSS environments is that network control changes in production without a documented SLA create more compliance risk than they solve. My approach would be: deploy in a sandbox account with representative synthetic traffic, build the log correlation pipeline before enabling the proxy (not after), and use the preview period to validate TLS termination latency with the specific cipher suites used by banking partners — because that number will come up in any serious architecture review.

## Verdict: Correct Architectural Direction, Adoption Timing Requires Caution

The reintroduction of forward proxy as a unified Network Firewall functionality is the correct design decision. AWS listened to preview feedback and resolved the most important structural problem: policy drift between two operating modes on the same security perimeter. For egress architectures in financial-grade environments, the combination of real TLS inspection, SNI-based decisions (no DNS rebinding window), container attribute rules for EKS/ECS, and unified policy with Firewall Manager represents a qualitative leap over what was previously possible.

However, the adoption verdict is conditional: **do not use in production during preview**. The limitations are real — single-region availability, no SLA, requirement for explicit configuration on each workload, and the impact of source IP loss on existing audit systems. For teams operating in regulated environments, the cost of a network control change without a documented SLA outweighs the benefit of being an early adopter.

The right time for production adoption will be when the service reaches GA in multiple regions (including sa-east-1 for Brazilian operations), with a published SLA and production support. Until then, use the preview to build the log correlation pipeline, validate TLS inspection latency with your partners, and automate HTTP_PROXY injection via admission webhook — because these are the operational blockers that will delay adoption when GA arrives, not the functionality itself.

**Rating: 4/5** — Solid functionality and correct architectural direction. The lost point is for the preview state with limited regional coverage and the non-trivial operational requirements for safe adoption in regulated environments.

**Rating:** 4/5

## References

- [AWS What's New: Re-introducing Forward Proxy as AWS Network Firewall Functionality (Aug 2026)](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-network-firewall-forward-proxy-preview/)
- [AWS What's New: Introducing AWS Network Firewall Proxy in preview (Nov 2025)](https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-firewall-proxy-preview/)
- [AWS Networking Blog: Securing Egress Architectures with Network Firewall Proxy (Nov 2025)](https://aws.amazon.com/cn/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/)
- [AWS Security Reference Architecture: Network Layer](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
- [AWS Network Firewall Developer Guide](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html)
- [AWS Firewall Manager Documentation](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)