Inspeção centralizada na AWS com GWLB e Palo Alto VM-Series

Era um dia como qualquer outro, um call, um projeto, era uma daquelas conversas em que o diagrama parecia simples demais para o tamanho do problema.

Na tela, algumas VPCs, um Transit Gateway, uma VPC de inspeção e uma saída para a internet. No papel, tudo passava pelo firewall. Na prática, cada pergunta abria outra: qual tabela de rota decide esse caminho? O retorno passa pelo mesmo lugar? O firewall enxerga a sessão inteira? Como a operação prova que um pacote foi permitido, bloqueado ou simplesmente nunca chegou?

Esse é o tipo de problema que aparece quando um ambiente AWS deixa de ser pequeno. A primeira aplicação nasce dentro de uma VPC. Alguém ajusta security groups. Depois vem outra conta. Mais uma VPC. Um WAF em um ponto, um NAT Gateway em outro, um firewall virtual em um ambiente específico. Em pouco tempo, o desenho deixa de parecer arquitetura e começa a parecer uma coleção de exceções.

O problema normalmente não é falta de ferramenta. É falta de um caminho claro para o tráfego.

Este artigo é um estudo baseado em uma experiência real, com nomes e contexto preservados, sobre como desenhar uma camada central de inspeção na AWS usando Palo Alto VM-Series, Gateway Load Balancer, Transit Gateway e Panorama. A intenção não é vender produto nem repetir documentação de fabricante. É mostrar raciocínio de arquitetura: o que cada peça resolve, onde ela entra, o que ela não resolve e qual benefício técnico ela traz.

O Problema

O ambiente cresceu em várias frentes ao mesmo tempo: contas separadas por função, VPCs com maturidades diferentes, aplicações novas convivendo com sistemas críticos e times precisando publicar serviços a todo momento sem reinventar segurança a cada entrega.

Em escala pequena, proteger cada aplicação localmente pode funcionar. Em escala maior, esse modelo não se sustenta:

• regras parecidas, mas não iguais, espalhadas em lugares diferentes;
• dificuldade de explicar por onde um tráfego passa;
• pouca padronização entre ambientes;
• mudança manual em pontos sensíveis;
• troubleshooting que depende mais de memória do que de evidência;
• risco de cada time resolver segurança de uma forma própria.

A pergunta deixou de ser:

Onde eu inspeciono o tráfego?

E virou:

Como criar um caminho de inspeção reutilizável, que várias VPCs consigam consumir, sem colocar um firewall manualmente dentro de cada ambiente?

Essa troca muda tudo. Quando a pergunta é sobre firewall, a resposta tende a ser uma instância. Quando a pergunta é sobre caminho de inspeção, a resposta vira arquitetura de rede.

O Mapa Mental da Solução

Antes de falar de serviço, eu gosto de separar o desenho em responsabilidades. Isso reduz ruído e evita aquela reunião em que rota, política, NAT, observabilidade e licenciamento viram uma discussão só.

O desenho final ficou dividido em quatro blocos:

• VPCs de aplicação, onde vivem workloads como EC2, EKS, Lambda e bancos;
• Transit Gateway, funcionando como ponto central de conectividade;
• VPC de saída, onde os Gateway Load Balancer Endpoints recebem o tráfego e o NAT Gateway e o Internet Gateway publicam a saída autorizada;
• VPC de segurança, onde ficam o Gateway Load Balancer e os firewalls Palo Alto VM-Series em alta disponibilidade ativo/passivo — com Panorama e GlobalProtect fora do caminho de dados.

As Peças, na Ordem em que o Pacote as Encontra

Em vez de apresentar cada serviço como um verbete de documentação, vou seguir o caminho que um pacote de saída percorre — e apresentar cada peça no momento em que ela entra em cena. O fluxo de entrada tem uma peça a mais, o ALB, e ganha uma seção própria mais adiante.

Transit Gateway — a malha viária

O pacote sai da aplicação, e a primeira parada é ele. Pense no Transit Gateway como a rodoviária da sua rede na AWS. Sem ele, conectar VPCs entre si vira um emaranhado de peerings ponto a ponto — cada par é uma conexão para criar, documentar e manter. Com ele, cada VPC se conecta uma única vez ao hub, e quem decide o caminho são os attachments e as tabelas de rota.

No nosso desenho, é ele que fica no centro de tudo, ligando as VPCs de aplicação, a VPC de saída e a VPC de segurança. Mas é honesto dizer o que ele não faz: o Transit Gateway não corrige rota mal desenhada. Uma rota errada continua mandando tráfego para o lugar errado, criando retorno assimétrico ou quebrando conectividade — só que agora de forma centralizada.

Um detalhe de implementação que vale ouro: cada attachment do TGW vive em uma subnet dedicada — a tgw-subnet, um /28 por zona de disponibilidade, sem nenhum workload dentro. É a best practice da própria AWS, e o ganho é triplo: o attachment ganha tabela de rota própria, os IPs das subnets de aplicação ficam preservados, e o desenho deixa explícito por onde o tráfego entra e sai da VPC.

E aqui entra uma economia que pouca gente faz de propósito: barrar tráfego proibido antes de ele chegar ao TGW. Todo GB que atravessa o Transit Gateway é processado e cobrado — não faz sentido pagar para descobrir no hub que aquele destino nem era permitido. A ordem do filtro barato é esta: primeiro a tabela de rota (rota que não existe não gera pacote — é o bloqueio de custo zero); depois a NACL outbound da subnet do workload, que avalia por destino e derruba o pacote ainda na porta de saída. Uma pegadinha da documentação: a NACL da própria tgw-subnet tem avaliação invertida (o tráfego do workload para o TGW é avaliado pelas regras inbound dela, por IP de origem) — por isso a AWS recomenda mantê-la aberta e concentrar o filtro nas subnets de workload. E NACL é stateless: toda regra precisa da irmã de retorno, ou o bloqueio vira mistério de troubleshooting.

O acordo é este: você troca dezenas de conexões ponto a ponto por um único hub e, em troca, assume que o desenho das tabelas de rota passa a ser uma das partes mais importantes — e mais sensíveis — da arquitetura.

GWLB Endpoint — a porta de entrada da inspeção

O pacote chega à VPC de saída e encontra a primeira peça da camada de inspeção: o Gateway Load Balancer Endpoint. Ele é da família dos endpoints de PrivateLink — uma interface de rede que mora em uma subnet dedicada e serve de porta para um serviço que vive em outra VPC. No nosso caso, esse serviço é o GWLB da VPC de segurança.

A mecânica é simples e poderosa: a tabela de rota manda o tráfego para o endpoint; o endpoint entrega ao GWLB do outro lado; e, quando a inspeção termina, o tráfego permitido volta por esse mesmo endpoint para continuar o caminho. Esse “mesmo endpoint na ida e na volta” não é um detalhe de implementação — é o que preserva a simetria que um firewall stateful exige para enxergar a sessão inteira.

No desenho, existe um endpoint por zona de disponibilidade, e eles atendem tanto o fluxo de saída quanto o de entrada. É por isso que, nos diagramas, o endpoint aparece sempre como a fronteira entre “quem consome a inspeção” e “quem inspeciona”.

Gateway Load Balancer — o distribuidor

O Gateway Load Balancer, ou GWLB, resolve um problema antigo de quem já tentou colocar firewall no caminho do tráfego: como inserir o appliance sem transformar cada instância em um destino manual de rota. Ele mora na VPC de segurança, recebe o tráfego pelos GWLB Endpoints que vivem nas VPCs consumidoras, encapsula os pacotes em GENEVE e distribui os fluxos entre os firewalls saudáveis — mantendo cada sessão presa ao mesmo appliance. O GENEVE aqui não é detalhe exótico: é o túnel que carrega o pacote original intacto até o firewall, e é por ele que o tráfego inspecionado retorna.

Na prática, ele transforma a inspeção em um serviço de rede: as VPCs consomem por endpoint, sem precisar saber quantos firewalls existem atrás. O que ele não faz: decidir política de segurança, garantir sozinho o caminho de retorno ou substituir observabilidade.

A inserção fica simples, mas a conta chega em outros pontos — endpoints nas zonas certas, health checks bem configurados e, acima de tudo, simetria de tráfego.

Palo Alto VM-Series — o juiz

O Palo Alto VM-Series é onde a decisão de segurança acontece. Posicionado atrás do GWLB, é ele que recebe o tráfego, enxerga a sessão, aplica a política, registra os logs e, dependendo do desenho, ainda participa de NAT e perfis de segurança.

O detalhe que a documentação de fabricante não enfatiza: ele não nasce operacional. Entre subir a VM e ter um firewall de verdade existe um caminho inteiro — interfaces corretas, bootstrap, licenciamento, política, integração com a gestão e validação. Pular etapas aqui é plantar problema para colher depois.

Em troca da inspeção avançada, você passa a operar um appliance stateful em um caminho crítico — e appliance stateful exige respeito: sessão, simetria e failover viram assunto de arquitetura, não de configuração.

Panorama — o maestro, fora do palco

O Panorama é a resposta para uma pergunta que aparece já no segundo firewall: quem garante que os dois estão configurados do mesmo jeito? Ele centraliza templates, device groups, objetos e políticas — a configuração deixa de ser artesanal e passa a ser governada.

Ele vive fora do caminho de dados (nenhum pacote de aplicação passa por ele), mas bem no centro do caminho operacional: toda mudança de política nasce, é revisada e é distribuída por ele. O que ele não substitui é processo — mudança, revisão, rollback e validação continuam sendo disciplina do time.

O ganho é padronização; o preço é que a gestão central vira parte crítica da operação. Se o Panorama é a fonte da verdade, cuidar dele é cuidar de todos os firewalls de uma vez.

A Arquitetura

O diagrama abaixo é simplificado de propósito. Uma implementação real inclui múltiplas zonas, tabelas de rota separadas, endpoints por zona, instâncias redundantes, logs, automação e rotina de mudança. Para entender o desenho, o essencial é o fluxo: a aplicação não sai direto para a internet; ela passa por uma camada de inspeção.

O ponto mais importante desse desenho não é a quantidade de caixas. É a separação de responsabilidades. Aplicação roda aplicação. Rede centraliza caminho. Inspeção aplica decisão. Saída publica tráfego autorizado. Operação prova o que aconteceu.

O Caminho do Tráfego

Vamos caminhar por um exemplo simples: uma aplicação em uma VPC precisa acessar um serviço externo.

Sem inspeção central, a rota poderia mandar esse tráfego direto para um NAT Gateway. Com inspeção central, o caminho muda. A subnet da aplicação aponta para o Transit Gateway. O Transit Gateway encaminha o fluxo para a VPC de saída. Lá, o tráfego entra por um Gateway Load Balancer Endpoint, que o entrega ao GWLB na VPC de segurança, e chega a uma instância VM-Series.

O firewall avalia a sessão. Se a política permitir, o fluxo retorna pelo mesmo endpoint e segue para NAT Gateway e Internet Gateway.

Esse caminho parece longo, mas ele resolve um problema real: a aplicação não precisa conhecer os firewalls. Ela precisa de rotas corretas. A camada de inspeção passa a ser um serviço de rede consumido pelas VPCs.

O Fluxo de Entrada

O tráfego de entrada exige o mesmo cuidado, só que com outra pergunta: antes de chegar à aplicação, por onde esse pacote precisa passar?

Aqui entra uma peça nova — o ALB público que publica a aplicação — e uma sutileza que quase ninguém conta: quem intercepta o tráfego que chega não é a subnet, é a edge route table associada ao Internet Gateway. O pacote chega da internet destinado ao ALB; o IGW consulta essa tabela; a rota o desvia primeiro para o GWLB Endpoint; o endpoint entrega ao GWLB, que encapsula em GENEVE e envia à VM-Series. Aprovado, o tráfego retorna pelo túnel GENEVE ao GWLB, volta pelo mesmo endpoint e só então alcança o ALB — que finalmente distribui para a aplicação.

A resposta da aplicação refaz o caminho inverso e passa pela mesma inspeção. Em desenhos com firewall stateful, ida e volta precisam fazer sentido: se o pacote entra por um caminho e volta por outro, a sessão pode quebrar ou escapar da inspeção esperada.

Por isso, rota não é detalhe. Rota é parte da segurança.

Decisões Tomadas

Nem toda decisão foi sobre tecnologia. Algumas foram sobre manter o desenho operável.

A decisão principal foi centralizar a função de segurança em uma VPC dedicada. Isso não torna o desenho automaticamente melhor. Torna o desenho mais reutilizável. O preço é que o centro vira crítico.

Também ficou claro que Panorama e bootstrap não eram “extras”. Em firewall virtual, a VM subir não significa que a solução está pronta. O valor aparece quando política, rota, observabilidade e operação se conectam.

Dificuldades Reais

Os problemas mais importantes raramente aparecem no primeiro diagrama.

Ida e Volta

O primeiro risco é retorno assimétrico. Se a ida passa por um firewall e a volta aparece por outro caminho, a sessão pode falhar ou ficar invisível para a política esperada. Em arquitetura com appliance stateful, simetria precisa ser desenhada, não assumida.

Zonas e Falha

Redundância no desenho não garante redundância na operação. Endpoints, subnets, appliances, rotas e health checks precisam respeitar o mesmo modelo. Do contrário, uma falha localizada pode virar interrupção maior do que deveria.

Observabilidade Tarde Demais

Sem logs úteis, você descobre que algo falhou, mas não descobre por quê. O ideal é planejar consultas, logs, métricas, health checks e trilha de mudança antes da primeira crise.

Automação que Só Cria Recurso

Terraform ajuda a criar VPCs, subnets, route tables, endpoints, load balancers, target groups, instâncias e artefatos de bootstrap. Mas automação de infraestrutura não é só subir recurso. O cuidado é manter coerência entre código, bootstrap publicado e estado real dos firewalls.

Operação e Observabilidade

Um desenho desse tipo precisa responder perguntas operacionais simples:

• o firewall está saudável?
• o GWLB está encaminhando para targets corretos?
• a rota da subnet aponta para o caminho esperado?
• a política aplicada é a mesma aprovada no processo?
• existe log para tráfego permitido e bloqueado?
• alguém consegue seguir uma sessão do workload até o destino?

Essa é a parte menos glamourosa e mais importante. Arquitetura que não dá para operar vira desenho bonito e incidente difícil.

Trade-Offs

Centralizar inspeção não é obrigatório para todo ambiente. Para uma conta pequena, pode ser excesso. Para um ambiente com muitas VPCs e times, começa a fazer sentido.

Os ganhos são claros:

• política de segurança mais consistente;
• menos firewalls espalhados;
• operação centralizada;
• melhor visibilidade dos fluxos;
• reutilização da camada de inspeção por várias VPCs.

Mas existe custo técnico:

• mais dependência do caminho central;
• mais cuidado com tabelas de rota;
• mais atenção a falhas por zona;
• mais necessidade de observabilidade;
• mais disciplina para mudança de política;
• mais componentes para versionar e validar.

Esse é o trade-off central: menos repetição nas pontas, mais responsabilidade no centro.

O que Eu Faria Diferente

Eu começaria menor.

Antes de discutir todas as VPCs, escolheria um fluxo representativo: uma aplicação saindo para a internet por um caminho controlado. Validaria rota, inspeção, log, falha de firewall e retorno. Só depois ampliaria para outros fluxos.

Também separaria melhor as conversas. Uma reunião para caminho de tráfego. Outra para política de segurança. Outra para operação e logs. Quando tudo é discutido junto, decisões importantes viram detalhe.

Por fim, eu trataria o diagrama como ferramenta de validação, não como peça de apresentação. Um bom diagrama precisa responder perguntas difíceis: quem envia, quem recebe, onde inspeciona, onde registra log, como volta e o que acontece quando falha.

Checklist Prático

Antes de implementar um desenho parecido, eu revisaria pelo menos estas perguntas:

• Quais VPCs realmente precisam consumir a inspeção central?
• Quais fluxos são de saída, entrada e comunicação entre VPCs?
• Existe separação clara entre VPC de aplicação, VPC de segurança e VPC de saída?
• As tabelas de rota deixam claro o caminho de ida e volta?
• Cada attachment do TGW tem sua tgw-subnet dedicada (/28 por AZ), com tabela de rota própria?
• O tráfego proibido morre na origem (rota inexistente ou NACL outbound do workload) antes de gastar o TGW?
• Os endpoints do GWLB estão nas subnets e zonas corretas?
• O desenho tolera falha de uma instância de firewall?
• O desenho tolera falha de uma zona?
• A operação sabe validar logs, NAT, política e health checks?
• Panorama será a fonte de gestão dos firewalls?
• Bootstrap, configuração e código estão alinhados?
• Existe plano de rollback para mudança de política ou rota?

Aprendizados

O principal aprendizado é que inspeção centralizada não é um produto. É um acordo entre rede, segurança, automação e operação.

O Transit Gateway organiza conectividade, mas não corrige rota ruim. O GWLB facilita inserir appliances, mas não decide política. O VM-Series inspeciona tráfego, mas precisa nascer e operar direito. O Panorama centraliza gestão, mas não substitui processo.

Quando essas peças são desenhadas juntas, a arquitetura fica poderosa. Quando são tratadas separadamente, o ambiente ganha complexidade sem ganhar clareza.

Para mim, a pergunta que resume esse tipo de desenho é simples:

Se um pacote sair de uma aplicação agora, todo mundo consegue explicar por onde ele passa, quem decide se ele pode seguir e onde essa decisão fica registrada?

Se a resposta for sim, a arquitetura está no caminho certo.

Agradecimento

Este desenho não nasceu sozinho. O Pedro Nunes esteve do outro lado em cada etapa — dos bootstraps dos firewalls às tabelas de rota que insistiam em não fazer sentido de madrugada. Metade do que está documentado aqui nós aprendemos juntos, errando e corrigindo em ambiente real.

Valeu, irmão: ninguém solta a mão de ninguém. 🤝

Referências Públicas

• AWS Gateway Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html
• AWS Transit Gateway: https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
• Palo Alto VM-Series on AWS: https://docs.paloaltonetworks.com/vm-series/deployment/public-cloud/set-up-the-vm-series-firewall-on-aws
• Terraform AWS Provider: https://registry.terraform.io/providers/hashicorp/aws/latest/docs

Próximos Passos

Este post abre uma trilha que dá para aprofundar em partes menores:

• como desenhar tabelas de rota para inspeção centralizada;
• como validar simetria de tráfego em ambientes com appliances stateful;
• como organizar bootstrap de firewalls virtuais sem perder rastreabilidade;
• como montar uma checklist de observabilidade para mudanças de rede;
• como usar IA para revisar diagramas, rotas e runbooks sem expor dados sensíveis.