AWS Network Firewall ganha modelo de política NGFW com capacidade separada para firewall e IPS

O que mudou

A AWS anunciou em 10 de novembro de 2026 a política next-generation firewall (NGFW) para o AWS Network Firewall, o serviço gerenciado que aplica controle de acesso e detecção de ameaças em Amazon VPCs. A mudança central é estrutural: em vez de misturar regras de firewall e de IPS (Intrusion Prevention System) numa mesma política, o novo modelo as separa em camadas distintas, cada uma com sua própria capacidade de regras.

Na prática, isso resolve um problema conhecido de quem já opera o Network Firewall em produção: regras de firewall (controle de acesso, deny-by-default, liberação de domínios aprovados) e regras de IPS (assinaturas de ameaça, managed rule groups) competiam pelo mesmo teto de capacidade. Com a NGFW policy, você aloca regras de firewall e regras de IPS separadamente, sem um lado roubar espaço do outro.

O modelo também introduz embedded rule groups: grupos de regras que você não precisa compartilhar entre políticas e que consomem capacidade sob demanda, sem pré-alocação. Isso evita o desperdício de reservar capacidade fixa para regras que só valem para uma política específica. Todas as regras da NGFW policy são stateful e avaliam o tráfego com contexto completo de conexão, o que a AWS descreve como tratamento de tráfego mais consistente e previsível.

Para IPS, você pode usar managed rule groups da própria AWS ou de parceiros do AWS Marketplace, que se atualizam automaticamente conforme novas ameaças surgem, ou criar grupos de regras IPS próprios. A AWS reforça que políticas existentes continuam operando sem alteração e que regras de IPS permanecem compatíveis com versões anteriores.

Onde está disponível

Segundo o anúncio, a política NGFW está disponível sem custo adicional em todas as AWS Regions comerciais e nas regiões AWS GovCloud (US). A fonte não cita explicitamente a região América do Sul (São Paulo), sa-east-1, mas ela se enquadra como região comercial, o que indica cobertura. Como o próprio anúncio recomenda, vale conferir a lista completa de regiões suportadas na página AWS Capabilities by Region antes de assumir disponibilidade em produção, já que o AWS Network Firewall em si nem sempre chega a todas as regiões no mesmo dia do recurso.

Quanto custa

A fonte é direta aqui: a política NGFW não tem custo adicional. Ou seja, se você já paga pelo AWS Network Firewall (cobrança por hora de endpoint de firewall e por GB processado, conforme o modelo padrão do serviço), adotar o novo modelo de política não muda sua fatura. O anúncio não detalha valores de hora ou de GB processado, então quem precisar do número exato deve consultar a página de preços do Network Firewall.

Como começar

O anúncio não traz comando de CLI nem passo a passo no console; ele aponta para a página do produto AWS Network Firewall e para a documentação como fontes de referência para configurar a NGFW policy. Na prática, o caminho natural é:

• Revisar as policies existentes no console do Network Firewall ou via infraestrutura como código (CloudFormation, CDK ou Terraform) antes de migrar, já que a migração não é automática;
• Planejar a separação de regras de firewall (deny-by-default, domínios aprovados) e regras de IPS (managed rule groups da AWS, do Marketplace ou customizados) em capacidades distintas;
• Mapear quais rule groups só valem para uma política específica e candidatá-los a embedded rule groups, evitando pré-alocação de capacidade.

O que muda para quem já usa

Para quem já opera Network Firewall em arquiteturas multi-conta com AWS Organizations, Transit Gateway ou inspeção centralizada de tráfego, o ganho mais direto é deixar de negociar capacidade entre firewall e IPS. Antes, aumentar o orçamento de regras de IPS (por exemplo, para cobrir mais assinaturas de um managed rule group de parceiro) podia empurrar o limite de regras de controle de acesso, obrigando trade-offs incômodos em ambientes de zero trust onde as duas camadas crescem juntas.

A AWS garante que políticas atuais continuam funcionando sem alteração, o que sinaliza uma migração opcional, não forçada. Isso dá tempo para times de arquitetura avaliarem o novo modelo em um ambiente de staging, testando o comportamento stateful com contexto completo de conexão antes de aplicar em VPCs de produção. Fica em aberto, porque o anúncio não detalha, qual é exatamente o teto de capacidade por camada na NGFW policy e se há diferença de limite entre regiões comerciais e GovCloud (US), pontos que só a documentação técnica deve esclarecer.

Fonte: AWS What's New