# AWS Network Firewall como Forward Proxy: Análise Técnica do Preview

A AWS reintroduziu o forward proxy como funcionalidade nativa do Network Firewall, unificando políticas de segurança entre os modos transparent e explicit proxy sob um único recurso. Esta análise examina o que mudou em relação ao preview de novembro de 2025, onde a funcionalidade genuinamente agrega valor em ambientes financeiros e onde os riscos operacionais ainda pedem cautela.

- 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=pt

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

- Category: IA & Agentes

- 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/)

---

Em novembro de 2025, a AWS lançou o Network Firewall Proxy como produto separado — com política própria, desconectado do transparent firewall existente. O feedback dos clientes foi direto: ninguém quer gerenciar duas políticas de segurança divergentes para o mesmo perímetro de egresso. Em agosto de 2026, a AWS ouviu e reintroduziu o proxy como funcionalidade do Network Firewall, unificada sob a mesma firewall policy, em um novo modo de deployment chamado no-source-preservation. Esta análise vai além do anúncio: examino o que essa convergência significa para arquiteturas de egresso em ambientes financeiros, os trade-offs reais do modo no-source-preservation, e por que o detalhe de 'política única' é mais importante do que parece na superfície.

## Contexto da Evolução: Da Bifurcação à Convergência

- **Nov 2025** — Primeiro preview — produto separado. Proxy com política própria, desconectado do transparent firewall
- **Ago 2026** — Reintrodução como funcionalidade unificada. Mesma firewall policy para proxy explícito e transparent firewall
- **1 policy** — Política única para ambos os modos. Managed rule groups, Geo-IP, domain filtering, EKS/ECS container rules
- **us-east-2** — Região disponível no preview. US East (Ohio) — preview gratuito durante o período de avaliação

## O Que É o Modo no-source-preservation e Por Que o Nome Importa

O Network Firewall opera tradicionalmente no modo **transparent firewall**: o tráfego passa pelo appliance sem que o IP de origem seja alterado, o que exige roteamento assimétrico controlado via Gateway Load Balancer ou route tables específicas. O cliente (workload) não precisa saber que existe um proxy — daí o termo 'transparent'. O novo modo **no-source-preservation** inverte essa premissa: o Network Firewall atua como **explicit forward proxy**, o que significa que a conexão TCP do cliente termina no firewall e uma nova conexão é originada em direção ao destino. O IP de origem visto pelo servidor de destino é o do próprio firewall, não o do workload original.

Esse comportamento tem implicações diretas em ambientes financeiros. Primeiro, ele elimina a necessidade de roteamento simétrico forçado — uma das maiores fontes de complexidade operacional em topologias hub-and-spoke com Transit Gateway. Segundo, ele viabiliza **TLS inspection** com terminação real de sessão, o que é pré-requisito para qualquer inspeção de payload em nível de aplicação exigida por frameworks como PCI-DSS e SOC 2. Terceiro, e mais sutilmente, ele muda o modelo de identidade de rede: logs de fluxo downstream verão o IP do firewall, não o do pod ou instância de origem — o que tem impacto direto em correlação de eventos em SIEMs como Splunk ou OpenSearch.

O nome 'no-source-preservation' é tecnicamente preciso e operacionalmente honesto: se você depende de IP de origem para correlação de auditoria, precisa instrumentar o firewall como ponto de coleta central de logs, não confiar nos logs de destino para rastrear a origem real da requisição.

## A Decisão de Design que Realmente Importa: Política Unificada

Quando a AWS lançou o proxy em novembro de 2025 como produto separado com política própria, o problema não era apenas operacional — era um problema de **drift de segurança**. Em qualquer ambiente financeiro com múltiplos times operando sobre a mesma infraestrutura, duas políticas de segurança que deveriam ser equivalentes inevitavelmente divergem. Uma regra de Geo-IP atualizada na política do transparent firewall pode não ser replicada na política do proxy. Um managed rule group novo adicionado por um time de SecOps pode cobrir apenas um dos dois modos. O resultado é uma superfície de ataque assimétrica que é difícil de auditar e ainda mais difícil de justificar para um CISO ou para um auditor externo.

A unificação sob uma única **firewall policy** resolve esse problema estruturalmente. A política passa a ser a fonte de verdade única para ambos os modos de operação. Isso tem valor imediato em três dimensões: (1) **auditoria e compliance** — um único recurso para rastrear em AWS Config, CloudTrail e Security Hub; (2) **automação de IaC** — um único bloco Terraform ou CloudFormation para gerenciar regras, eliminando a necessidade de módulos duplicados com lógica de sincronização; (3) **resposta a incidentes** — quando um analista de SOC precisa bloquear um domínio em tempo real via AWS Firewall Manager, a mudança se propaga para ambos os modos simultaneamente.

Do ponto de vista de Well-Architected, isso é um ganho direto no pilar de **Operational Excellence**: reduz o número de recursos distintos a monitorar, simplifica o runbook de mudanças e elimina uma classe inteira de erros de configuração por omissão. Para times que já usam AWS Firewall Manager para gerenciamento centralizado em múltiplas contas, a política unificada é o que torna o proxy viável em escala organizacional.

## Arquitetura de Egresso com Network Firewall no Modo Forward Proxy

Topologia hub-and-spoke com Transit Gateway. O Network Firewall opera em no-source-preservation (explicit proxy) na VPC de egresso centralizada. Workloads em EKS e ECS configuram o proxy explicitamente via variável de ambiente HTTP_PROXY. A política única cobre managed rules, Geo-IP, domain filtering e 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)

### Fluxos

- eks_pod -> tgw: CONNECT :8080 (explicit proxy)
- ecs_task -> tgw: CONNECT :8080 (explicit proxy)
- tgw -> anfw: roteado para egress VPC
- anfw -> policy: avalia política unificada
- anfw -> nat_gw: tráfego permitido
(IP do firewall como origem)
- nat_gw -> internet: egresso inspecionado
- anfw -> blocked: DROP — Geo-IP / categoria
- anfw -> cw_logs: alert + flow logs
- fw_manager -> policy: distribui política
- config -> anfw: avalia conformidade

## Onde o Modo Proxy Genuinamente Supera o Transparent Firewall

O transparent firewall tem uma limitação estrutural que raramente aparece em documentação de marketing: ele depende de **FQDN-based rules** que resolvem DNS no momento da avaliação da regra. Em ambientes onde aplicações usam connection pooling agressivo, CDNs com TTL curto ou IPs dinâmicos (como muitas APIs de terceiros em fintech), o transparent firewall pode permitir tráfego para IPs que já não correspondem ao FQDN que foi resolvido na criação da regra. Esse problema é conhecido como **DNS rebinding window** e é uma das razões pelas quais proxy explícito é preferido em arquiteturas Zero Trust maduras.

O modo proxy resolve isso de forma diferente: como a conexão TCP termina no firewall, ele pode inspecionar o **SNI (Server Name Indication)** do TLS ClientHello ou o header `Host` do HTTP antes de estabelecer a conexão de saída. Isso significa que a decisão de allow/deny é baseada no nome do domínio real que o cliente está tentando alcançar, não em uma resolução DNS prévia. Para ambientes PCI-DSS que precisam garantir que nenhum dado de cartão saia para domínios não autorizados, essa distinção é fundamental.

Além disso, as **container attribute-based rules para EKS e ECS** — mencionadas no anúncio — ganham uma dimensão nova no modo proxy. No transparent firewall, identificar qual pod específico originou uma conexão requer correlação entre logs de VPC Flow e metadados do Kubernetes, o que é frágil em escala. No modo proxy, o workload faz uma conexão explícita ao proxy, e o firewall pode logar o contexto da conexão de forma mais determinística. Isso simplifica a rastreabilidade em auditorias de segurança onde você precisa provar que um container específico não acessou um endpoint não autorizado durante um período de tempo definido.

## Pontos Fortes da Funcionalidade Unificada

- **Política única, drift zero**: uma firewall policy cobre transparent e explicit proxy — managed rule groups, Geo-IP, domain category filtering e container attribute rules são configurados uma vez e aplicados em ambos os modos.
- **Inspeção TLS real**: terminação de sessão no firewall permite inspeção de payload em nível de aplicação, habilitando detecção de exfiltração de dados em tráfego HTTPS — requisito direto de PCI-DSS e SOC 2.
- **Eliminação do roteamento simétrico forçado**: o modo no-source-preservation simplifica topologias hub-and-spoke, removendo a necessidade de Gateway Load Balancer para inspeção de egresso centralizado.
- **Active threat defense e managed rule groups**: as mesmas capacidades de threat intelligence gerenciadas pela AWS (incluindo feeds de reputação de IP e domínio) aplicadas uniformemente ao tráfego proxy.
- **Integração nativa com Firewall Manager**: política distribuída centralmente em múltiplas contas e VPCs, com conformidade rastreável via AWS Config e Security Hub.
- **Decisão baseada em SNI/Host header**: elimina a DNS rebinding window presente no transparent firewall, fortalecendo controles de egresso em arquiteturas Zero Trust.

> **Limitações Reais que Você Precisa Conhecer Antes de Adotar:** **1. IP de origem não preservado — impacto em auditoria**: No modo no-source-preservation, o servidor de destino vê o IP do firewall, não o do workload. Se você tem sistemas de terceiros que fazem allowlisting por IP de origem (comum em APIs bancárias e gateways de pagamento), precisará renegociar esses acordos ou manter um caminho de saída separado para esse tráfego. Além disso, logs de destino não servirão para correlação de incidentes — você depende 100% dos logs do Network Firewall como fonte de verdade.

**2. Preview em região única**: Disponível apenas em us-east-2 (Ohio) no momento do anúncio. Para ambientes financeiros com requisitos de residência de dados em outras regiões (especialmente sa-east-1 para operações brasileiras), a adoção em produção ainda não é viável.

**3. Configuração explícita de proxy no cliente**: Diferente do transparent firewall, o modo explicit proxy requer que cada workload configure `HTTP_PROXY` / `HTTPS_PROXY`. Em ambientes EKS com centenas de deployments, isso exige um mecanismo de injeção centralizado (admission webhook, Kustomize patch, ou variáveis de ambiente via ConfigMap) — sem isso, workloads que não configuram o proxy simplesmente bypassam a inspeção.

**4. Compatibilidade com protocolos não-HTTP**: Forward proxy explícito funciona para HTTP/HTTPS via método CONNECT. Tráfego TCP/UDP não-HTTP (como conexões diretas a bancos de dados, SFTP, ou protocolos proprietários) não passa pelo proxy e requer o transparent firewall em paralelo — o que reintroduz a complexidade de dois modos de operação.

**5. Ainda em preview**: Sem SLA de disponibilidade, sem suporte de produção, sem garantia de estabilidade de API. Não use em workloads que processam dados de produção.

## Modelo de Ameaça que Esta Funcionalidade Resolve — e o que Ainda Fica em Aberto

O anúncio menciona explicitamente dois casos de uso: **data exfiltration** e **malware injection**. Vale decompor o que o forward proxy realmente resolve em cada um desses vetores, porque a resposta não é binária.

Para **exfiltração de dados**, o proxy explícito com inspeção TLS é genuinamente eficaz contra exfiltração via HTTP/HTTPS para domínios não autorizados. Um agente malicioso que tenta usar `curl` ou uma biblioteca HTTP para enviar dados para um endpoint externo será bloqueado se o domínio não estiver na allowlist. No entanto, exfiltração via DNS (DNS tunneling), via protocolos não-HTTP, ou via serviços SaaS autorizados (como exfiltrar dados para um bucket S3 público via AWS SDK) não é coberta pelo forward proxy — requer controles complementares como Route 53 Resolver DNS Firewall para o primeiro caso e políticas de endpoint de VPC para o terceiro.

Para **malware injection**, o proxy com inspeção TLS pode detectar payloads maliciosos em respostas HTTP/HTTPS usando os managed rule groups da AWS ou regras Suricata customizadas. Isso é relevante para cenários de supply chain attack onde uma dependência de pacote npm ou PyPI serve um payload malicioso. A eficácia depende diretamente da qualidade das assinaturas e da capacidade de inspecionar tráfego TLS — o que requer configuração cuidadosa de certificate pinning em clientes que verificam o certificado do servidor.

O que permanece em aberto: **lateral movement** dentro da VPC não é afetado pelo egress proxy. Comunicação leste-oeste entre pods no mesmo cluster EKS, ou entre serviços em VPCs conectadas via VPC Peering, não passa pelo Network Firewall em modo proxy. Para esse vetor, a resposta correta é Network Policy no Kubernetes (Cilium ou AWS VPC CNI com network policy) combinada com Security Groups por pod — não o forward proxy.

## Transparent Firewall vs. Explicit Proxy (no-source-preservation): Comparação Técnica
| Critério | Dimensão | Transparent Firewall | Explicit Proxy (no-source-preservation) |
| --- | --- | --- | --- |
| Configuração no cliente | Nenhuma — transparente para o workload | HTTP_PROXY / HTTPS_PROXY obrigatório | — |
| IP de origem no destino | IP original do workload preservado | IP do firewall (source não preservado) | — |
| Inspeção TLS | Baseada em SNI sem terminação de sessão | Terminação real de sessão TLS — inspeção de payload | — |
| DNS rebinding window | Presente — regras baseadas em resolução DNS prévia | Eliminada — decisão baseada em SNI/Host header | — |
| Protocolos suportados | TCP/UDP genérico + HTTP/HTTPS | HTTP/HTTPS via CONNECT — não-HTTP requer transparent em paralelo | — |
| Complexidade de roteamento | Roteamento simétrico forçado — GWLB ou route tables específicas | Simplificado — sem necessidade de roteamento simétrico | — |
| Política de segurança | Firewall policy unificada (após Aug 2026) | Mesma firewall policy unificada | — |

## Como Adotar o Forward Proxy em um Ambiente Financeiro: Sequência Recomendada

1. **1. Valide o modelo de ameaça antes de qualquer configuração** — Mapeie os vetores de exfiltração relevantes para seu ambiente: HTTP/HTTPS para domínios externos, DNS tunneling, protocolos não-HTTP. O forward proxy resolve apenas o primeiro. Para os demais, defina controles complementares (DNS Firewall, VPC endpoint policies) antes de assumir que o proxy cobre tudo.

2. **2. Audite todos os workloads que precisam configurar HTTP_PROXY** — Em EKS, use um admission webhook (ex: OPA Gatekeeper ou Kyverno) para garantir que todos os Deployments e StatefulSets tenham as variáveis HTTP_PROXY e HTTPS_PROXY injetadas. Workloads sem essa configuração bypassam silenciosamente a inspeção — isso é um risco de segurança, não apenas uma lacuna operacional.

3. **3. Configure a firewall policy unificada com modo de log completo** — Inicie com action=ALERT (não DROP) para todos os domínios não explicitamente permitidos. Colete logs no CloudWatch Logs com retenção mínima de 90 dias (PCI-DSS requer 12 meses em cold storage). Use CloudWatch Metric Filters para criar alarmes em tentativas de acesso a categorias bloqueadas — isso gera o baseline de tráfego legítimo antes de endurecer as regras.

4. **4. Identifique e trate tráfego não-HTTP antes de ativar o modo exclusivo** — Use VPC Flow Logs com análise no Athena para identificar conexões TCP/UDP que não passam por HTTP. Para cada protocolo identificado, decida: (a) migrar para um endpoint de VPC se for um serviço AWS, (b) manter o transparent firewall em paralelo para esse tráfego específico, ou (c) bloquear se não for tráfego legítimo.

5. **5. Implemente correlação de logs para compensar a perda de IP de origem** — Configure o Network Firewall para logar o contexto de conexão completo, incluindo metadados de container quando disponíveis via container attribute rules. Integre com seu SIEM (Splunk, OpenSearch, ou Datadog) usando um pipeline de ingestão que correlaciona o timestamp e porta de origem nos logs do firewall com os logs de aplicação do pod para reconstruir a identidade do workload originador.

6. **6. Endureça regras progressivamente e automatize via Firewall Manager** — Após 2-4 semanas de baseline em modo ALERT, mova para DROP os domínios e categorias não observados no tráfego legítimo. Use AWS Firewall Manager para distribuir a política atualizada em todas as contas do AWS Organizations, com Security Hub registrando desvios de conformidade em tempo real.

## Análise pelo Lens do AWS Well-Architected

- **security**: Ganho direto: inspeção TLS real, decisões baseadas em SNI (sem DNS rebinding window), política unificada que elimina drift entre modos. Risco residual: workloads sem HTTP_PROXY configurado bypassam inspeção silenciosamente — requer controle compensatório via admission webhook. Tráfego não-HTTP permanece fora do escopo do proxy.
- **reliability**: O Network Firewall é um serviço gerenciado com alta disponibilidade por design. O modo no-source-preservation não introduz novos pontos de falha em relação ao transparent firewall. O risco de indisponibilidade está na dependência do proxy para todo tráfego HTTP/HTTPS — um firewall mal configurado pode bloquear tráfego legítimo em escala.
- **sustainability**: Consolidação de controles em um único serviço gerenciado (vs. múltiplos appliances de proxy de terceiros) reduz overhead computacional e simplifica o inventário de infraestrutura — alinhado com o princípio de eficiência de recursos do pilar de sustentabilidade.

## Anti-Padrões a Evitar na Adoção do Forward Proxy

- **Assumir que o proxy substitui completamente o transparent firewall**: Tráfego não-HTTP (conexões diretas a RDS, SFTP, protocolos proprietários) não passa pelo proxy explícito. Desativar o transparent firewall antes de mapear todo o tráfego não-HTTP cria brechas de segurança imediatas.
- **Confiar em logs de destino para correlação de incidentes**: No modo no-source-preservation, o IP de origem nos logs de destino é o do firewall. Construir runbooks de resposta a incidentes que dependem de logs de destino para identificar o workload originador resultará em investigações inconclusivas.
- **Implantar em produção durante o preview**: O serviço está em preview sem SLA de disponibilidade. Ambientes financeiros com requisitos de uptime contratual (99.9%+) não devem usar funcionalidades em preview para tráfego de produção.
- **Não instrumentar a injeção de HTTP_PROXY como controle de segurança**: Tratar a configuração de HTTP_PROXY nos workloads como uma tarefa de DevOps opcional é um erro. Workloads sem essa configuração bypassam a inspeção — isso deve ser auditado via admission webhook e tratado como um controle de segurança obrigatório.
- **Ativar DROP imediatamente sem baseline de tráfego**: Iniciar com ação DROP sem um período de observação em modo ALERT garante interrupção de tráfego legítimo. Sempre colete baseline por 2-4 semanas antes de endurecer regras em ambientes de produção.

> **Nota do Curador: O que Eu Faria na Prática:** Em ambientes financeiros onde opero, a decisão de adotar o forward proxy unificado não é sobre a funcionalidade em si — é sobre o momento certo. A unificação de política é a mudança arquitetural correta, e eu teria pressionado por ela desde o preview de novembro de 2025. Mas o modo no-source-preservation em preview em uma única região ainda não justifica migração de workloads de produção: a lição mais cara que aprendi em ambientes PCI-DSS é que mudanças em controles de rede em produção sem SLA documentado criam mais risco de compliance do que resolvem. Minha abordagem seria: implantar em uma conta de sandbox com tráfego sintético representativo, construir o pipeline de correlação de logs antes de habilitar o proxy (não depois), e usar o período de preview para validar a latência de terminação TLS com as suites de cifras específicas usadas pelos parceiros bancários — porque esse número vai aparecer em qualquer revisão de arquitetura séria.

## Veredicto: Direção Arquitetural Correta, Timing de Adoção Requer Cautela

A reintrodução do forward proxy como funcionalidade unificada do Network Firewall é a decisão de design correta. A AWS ouviu o feedback de preview e resolveu o problema estrutural mais importante: drift de política entre dois modos de operação no mesmo perímetro de segurança. Para arquiteturas de egresso em ambientes financeiros, a combinação de inspeção TLS real, decisões baseadas em SNI (sem DNS rebinding window), container attribute rules para EKS/ECS e política unificada com Firewall Manager representa um salto qualitativo em relação ao que era possível antes.

No entanto, o veredicto de adoção é condicionado: **não use em produção durante o preview**. As limitações são reais — disponibilidade em região única, ausência de SLA, necessidade de configuração explícita em cada workload, e o impacto da perda de IP de origem em sistemas de auditoria existentes. Para times que operam em ambientes regulados, o custo de uma mudança de controle de rede sem SLA documentado supera o benefício de ser early adopter.

O momento certo para adoção em produção será quando o serviço atingir GA em múltiplas regiões (incluindo sa-east-1 para operações brasileiras), com SLA publicado e suporte de produção. Até lá, use o preview para construir o pipeline de correlação de logs, validar a latência de TLS inspection com seus parceiros, e automatizar a injeção de HTTP_PROXY via admission webhook — porque esses são os bloqueadores operacionais que vão atrasar a adoção quando o GA chegar, não a funcionalidade em si.

**Rating: 4/5** — Funcionalidade sólida e direção arquitetural correta. O ponto perdido é pelo estado de preview com cobertura regional limitada e os requisitos operacionais não triviais para adoção segura em ambientes regulados.

**Rating:** 4/5

## Referências

- [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)