Por que e como migrar para o AWS Network Firewall anexado ao Transit Gateway

O que mudou no AWS Network Firewall

O AWS Network Firewall passou a suportar conexão nativa ao AWS Transit Gateway. Para quem já usa o Transit Gateway para rotear tráfego de redes do Amazon Virtual Private Cloud (Amazon VPC) até uma VPC de inspeção centralizada, essa novidade representa uma simplificação arquitetural significativa.

No modelo tradicional, era necessário manter uma VPC dedicada exclusivamente para hospedar os endpoints do firewall, além de gerenciar todas as tabelas de roteamento e sub-redes associadas. Com a conexão nativa, o Network Firewall se anexa diretamente ao Transit Gateway — a AWS provisiona e gerencia a VPC subjacente de forma transparente, e o firewall passa a aparecer como um anexo de função de rede (network function attachment) no Transit Gateway.

Por que migrar para o modelo com conexão nativa

A AWS aponta dois motivos principais para considerar essa migração:

• Alocação flexível de custos: com a conexão nativa, é possível usar as políticas de medição do Transit Gateway para repassar os custos de tráfego para cada conta proprietária. Esse recurso de alocação flexível de custos para tráfego do Network Firewall via Transit Gateway está disponível somente no modelo de conexão nativa. No modelo anterior, era possível alocar apenas os encargos de processamento de dados do Transit Gateway, mas não os do próprio Network Firewall.
• Redução da complexidade arquitetural: a VPC de inspeção dedicada deixa de existir, junto com suas tabelas de roteamento e sub-redes. Menos recursos para gerenciar significa menos superfície de erro e menor overhead operacional.

O que preparar antes de começar

Pré-requisitos

Antes de criar o novo firewall com conexão nativa ao Transit Gateway, é necessário reunir as seguintes informações:

• ID do Transit Gateway: o identificador da instância do Transit Gateway ao qual o firewall será anexado.
• Configuração de logs: crie uma nova configuração de logs (por exemplo, novos grupos de log no Amazon CloudWatch) exclusiva para o novo firewall. Durante a migração, os dois firewalls estarão ativos simultaneamente, e manter os logs separados facilita o monitoramento e a resolução de problemas em cada um.
• Política do firewall: crie uma nova política para o novo firewall em vez de reutilizar a existente. Com políticas separadas, é possível ajustar as regras do novo ambiente sem afetar o firewall em produção enquanto ambos operam em paralelo.

Considerações importantes

• Criptografia no Transit Gateway: verifique se o suporte a criptografia do Transit Gateway está habilitado. Se a criptografia for obrigatória para a sua postura de segurança, saiba que a conexão nativa ao Network Firewall ainda não suporta esse recurso — nesse caso, será necessário manter a configuração atual.
• IPs Elásticos do NAT Gateway: se for necessário manter os mesmos IPs públicos (por exemplo, para listas de permissão de parceiros), planeje isso com antecedência. O processo de preservação dos IPs Elásticos é detalhado na seção Preservando os IPs Elásticos do NAT Gateway durante a migração.
• Janela de manutenção: planeje a migração para uma janela de manutenção dedicada. Pequenas interrupções de rede ocorrerão em etapas específicas, como na troca de associações de tabelas de roteamento do Transit Gateway e na substituição de NAT Gateways.

Como realizar a migração

A recomendação é manter a configuração existente do Network Firewall intacta enquanto o novo firewall com conexão nativa é configurado em paralelo. Essa abordagem minimiza o tempo de inatividade e permite validar a nova configuração antes de migrar o tráfego de produção.

O processo varia de acordo com a arquitetura atual. A AWS descreve dois cenários mais comuns. Para o passo a passo detalhado usando Terraform, AWS CloudFormation ou manualmente pelo AWS Management Console, consulte o repositório do guia de migração.

Arquitetura 1: VPC de inspeção separada da VPC de saída

Nesse cenário, existe uma VPC dedicada para os endpoints do firewall e outra VPC dedicada exclusivamente para os NAT Gateways responsáveis pelo tráfego de saída.

O processo de migração em alto nível para essa arquitetura é:

1. Implante uma nova VPC de saída com um NAT Gateway temporário, mantendo a implantação existente inalterada.
2. Crie o novo firewall com conexão nativa ao Transit Gateway.
3. Configure três novas tabelas de roteamento do Transit Gateway: uma tabela de inspeção (associada ao novo firewall), uma tabela de saída (associada à nova VPC de saída) e uma tabela temporária para spoke VPCs em migração.
4. Teste o novo firewall movendo uma única spoke VPC para o novo caminho. Verifique a conectividade e confirme que o firewall está inspecionando o tráfego verificando os logs de alerta em busca de detalhes da camada 7 (camada de aplicação). A presença de informações de camada 7 nos logs indica que o firewall está vendo as duas direções do fluxo de tráfego — o que confirma que não há roteamento assimétrico.
5. Migre as spoke VPCs restantes de forma incremental ou, quando houver confiança na nova implantação, atualize a rota padrão na tabela de roteamento de spokes existente para apontar para o novo anexo de função de rede do Network Firewall.
6. Opcionalmente, preserve os IPs Elásticos originais do NAT Gateway redirecionando o tráfego de volta para a VPC de saída existente (veja Preservando os IPs Elásticos do NAT Gateway durante a migração).
7. Descomissione os recursos antigos após verificar que o tráfego está fluindo corretamente. Quais VPCs serão removidas depende de ter preservado ou não os IPs Elásticos originais (veja Preservando os IPs Elásticos do NAT Gateway durante a migração).

Para o guia completo dessa migração, acesse: guia de migração via Terraform, guia via CloudFormation ou guia manual pelo console.

Arquitetura 2: VPC combinada de inspeção e saída

Nesse cenário, uma única VPC concentra tanto os endpoints do Network Firewall quanto os NAT Gateways responsáveis pelo tráfego de saída.

O processo de migração segue as mesmas etapas em alto nível da Arquitetura 1:

1. Implante uma nova VPC de saída dedicada com um NAT Gateway temporário.
2. Crie o novo firewall com conexão nativa ao Transit Gateway.
3. Configure três novas tabelas de roteamento do Transit Gateway: tabela de inspeção, tabela de saída e tabela temporária para spokes em migração.
4. Teste o novo firewall movendo uma única spoke VPC para o novo caminho e verifique a presença de detalhes de camada 7 nos logs de alerta.
5. Migre as spoke VPCs restantes de forma incremental ou em bloco.
6. Opcionalmente, preserve os IPs Elásticos originais transferindo-os para a nova VPC de saída.
7. Descomissione a antiga VPC combinada após confirmar que o tráfego está fluindo corretamente.

Para o guia completo dessa migração, acesse: guia de migração via Terraform, guia via CloudFormation ou guia manual pelo console.

Diferenças entre as duas arquiteturas

Ambas as arquiteturas implantam os mesmos novos recursos e utilizam a mesma abordagem de migração em fases. As diferenças estão na estrutura inicial de roteamento do Transit Gateway (a Arquitetura 1 possui três tabelas de roteamento distribuídas em duas VPCs; a Arquitetura 2 possui duas tabelas em uma única VPC) e nos recursos a serem removidos ao final (duas VPCs antigas em vez de uma). Ambas convergem para o mesmo estado final. Para uma comparação detalhada, consulte o repositório do guia de migração.

Boas práticas para minimizar riscos

Independentemente da arquitetura de origem, a AWS recomenda seguir estas práticas para reduzir riscos durante a migração:

• Teste antes de migrar: crie o novo firewall com conexão nativa em paralelo com a configuração existente. Use uma VPC de teste para validar a nova configuração. Verifique se os logs estão funcionando corretamente e se os logs de alerta do firewall mostram detalhes de tráfego de camada 7 — isso confirma a ausência de roteamento assimétrico. Teste cenários de tráfego permitido e bloqueado antes de migrar o ambiente de produção. O repositório do guia de migração inclui templates de CloudFormation e Terraform para ambas as arquiteturas iniciais, permitindo praticar a migração completa em uma conta de desenvolvimento ou teste.
• Migre em fases: comece com uma única VPC de carga de trabalho não crítica. Atualize apenas as rotas dessa VPC para usar o novo anexo do firewall. Monitore o comportamento das aplicações antes de prosseguir. Ao planejar a ordem de migração, migre ao mesmo tempo as spoke VPCs que possuem tráfego leste-oeste entre si. Durante a migração em fases, spokes em caminhos de firewall diferentes terão seu tráfego leste-oeste atravessando dois firewalls stateful — e como cada firewall rastreia o estado de conexão de forma independente, tráfego que entra por um firewall e retorna por outro aparece como não rastreado, podendo ser descartado.
• Mantenha o firewall antigo ativo: não descomissione a configuração anterior até que todo o tráfego tenha sido migrado.
• Prepare um plano de rollback: documente as configurações atuais das tabelas de roteamento antes de fazer qualquer alteração. Se surgirem problemas, reverter as mudanças nas tabelas de roteamento restaura a configuração anterior.

Preservando os IPs Elásticos do NAT Gateway

Um ponto crítico durante a migração é manter os endereços IP Elásticos dos NAT Gateways existentes. Muitas organizações têm esses IPs em listas de permissão de parceiros externos, serviços de terceiros ou regras de firewall. Alterá-los exigiria coordenação com múltiplos stakeholders e poderia impactar operações.

Durante a migração, como os dois ambientes precisam operar simultaneamente, serão criados NAT Gateways temporários com IPs Elásticos temporários na nova VPC de saída. Após confirmar que o novo firewall está estável e o tráfego de produção foi migrado com sucesso, é possível restaurar os IPs originais.

O processo varia conforme a arquitetura:

• Arquitetura 1 (VPCs separadas): a VPC de saída existente e seus NAT Gateways são independentes da VPC de inspeção que será descomissionada. É possível mantê-los reassociando o anexo do Transit Gateway da VPC de saída existente à nova tabela de roteamento de saída. Essa é uma mudança de roteamento no Transit Gateway que leva segundos, não requer exclusão ou criação de NAT Gateways e não aumenta em complexidade com o número de Zonas de Disponibilidade.
• Arquitetura 2 (VPC combinada): como a VPC antiga contém tanto os endpoints do firewall quanto os NAT Gateways, o caminho mais direto é descomissioná-la e transferir os IPs Elásticos para a nova VPC de saída. Para isso, exclui-se os NAT Gateways antigos para liberar os IPs e, em seguida, criam-se novos NAT Gateways na nova VPC de saída com os IPs originais. Esse processo requer uma breve janela de manutenção e deve ser repetido para cada Zona de Disponibilidade.

Para o procedimento detalhado, consulte as etapas de preservação de IPs Elásticos no repositório do guia de migração.

Conclusão

A conexão nativa do Network Firewall ao Transit Gateway representa uma evolução relevante para quem opera arquiteturas de inspeção centralizada na AWS. A eliminação da VPC de inspeção reduz a complexidade operacional, e a alocação flexível de custos via políticas de medição do Transit Gateway abre novas possibilidades para ambientes multi-conta.

A abordagem de migração em fases — rodando os dois firewalls em paralelo, validando com uma única spoke VPC e migrando o restante quando houver confiança — oferece um caminho seguro para a transição. Para o guia completo com Terraform, CloudFormation ou console, acesse o repositório do guia de migração, que inclui templates de arquitetura inicial para praticar a migração completa em ambiente de teste antes de tocar na produção.

Fonte

Why and how to migrate to a Transit Gateway-attached AWS Network Firewall (https://aws.amazon.com/blogs/security/why-and-how-to-migrate-to-a-transit-gateway-attached-aws-network-firewall/)