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 anonimizado, baseado em uma experiência real em ambiente regulado, 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 custo 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 sem reinventar segurança a cada entrega.

Em escala pequena, proteger cada aplicação localmente pode funcionar. Em escala maior, esse modelo cobra preço rápido:

  • 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 instalo um firewall?

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ó.

flowchart LR
  Problem["Ambiente crescendo\nmuitas VPCs, contas e fluxos"] --> Goal["Objetivo\ninspecao reutilizavel"]
  Goal --> Path["Caminho do trafego\nida e volta previsiveis"]
  Goal --> Policy["Politica\ncontrole consistente"]
  Goal --> Ops["Operacao\nlogs, saude, mudanca"]

  Path --> TGW["Transit Gateway\nhub de conectividade"]
  Path --> GWLB["Gateway Load Balancer\nservico de insercao"]
  Policy --> FW["VM-Series\ninspecao e decisao"]
  Ops --> Panorama["Panorama\ngestao central"]
  Ops --> Observability["Logs e metricas\nprova operacional"]

  classDef pain fill:#fff4ef,stroke:#ca4a3c,color:#10151c;
  classDef goal fill:#f7f9fb,stroke:#24304a,color:#10151c;
  classDef network fill:#e8f7f8,stroke:#2a7f95,color:#10151c;
  classDef security fill:#fff8e6,stroke:#d6a84f,color:#10151c;
  classDef ops fill:#eef3ff,stroke:#5f6b84,color:#10151c;
  class Problem pain;
  class Goal,Path,Policy,Ops goal;
  class TGW,GWLB network;
  class FW security;
  class Panorama,Observability ops;

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 inspeção, onde ficam Gateway Load Balancer, endpoints e firewalls Palo Alto VM-Series;
  • VPC de saída, onde o tráfego autorizado segue para NAT Gateway, Internet Gateway e internet.

Os Conceitos, Sem Pose

Transit Gateway

O Transit Gateway é o hub de rede. Em vez de conectar VPC com VPC em vários pares difíceis de manter, você conecta as VPCs ao Transit Gateway e controla o caminho com attachments e tabelas de rota.

O problema que ele resolve: organização de conectividade entre muitas redes.

Onde ele entra: no centro do caminho entre VPCs de aplicação, inspeção e saída.

O que ele não resolve: ele não corrige rota mal desenhada. Uma rota errada ainda pode mandar tráfego para o lugar errado, criar retorno assimétrico ou quebrar conectividade.

O trade-off: você reduz conexões ponto a ponto, mas coloca muita responsabilidade no desenho das tabelas de rota.

Gateway Load Balancer

O Gateway Load Balancer, ou GWLB, permite inserir appliances de rede no caminho sem transformar cada firewall em um destino manual de rota.

O problema que ele resolve: distribuir fluxos para firewalls virtuais saudáveis e manter uma camada de inspeção consumível por outras VPCs.

Onde ele entra: dentro da VPC de inspeção, junto dos endpoints usados pelas VPCs consumidoras.

O que ele não resolve: ele não decide política de segurança, não garante sozinho o caminho de retorno e não substitui observabilidade.

O trade-off: ele simplifica a inserção de appliances, mas exige cuidado com endpoints, zonas, health checks, encapsulamento GENEVE e simetria de tráfego.

Palo Alto VM-Series

O Palo Alto VM-Series é o firewall virtual. Ele recebe o tráfego encaminhado pelo GWLB, aplica política, registra logs e pode participar de funções como NAT e perfis de segurança, dependendo do desenho.

O problema que ele resolve: inspeção e decisão de segurança no caminho do tráfego.

Onde ele entra: atrás do GWLB, como appliance de inspeção.

O que ele não resolve: ele não nasce operacional sozinho. Precisa de interfaces corretas, bootstrap, licenciamento, política, integração com gestão, logs e validação.

O trade-off: você ganha inspeção avançada, mas passa a operar appliance stateful em um caminho crítico.

Panorama

Panorama é a camada de gestão central dos firewalls. Sem ele, cada firewall tende a virar uma configuração isolada. Isso até parece aceitável com uma instância, mas fica frágil quando há múltiplas zonas, alta disponibilidade e política padronizada.

O problema que ele resolve: governança de configuração, templates, device groups, objetos e políticas.

Onde ele entra: fora do caminho de dados, mas dentro do caminho operacional.

O que ele não resolve: ele não substitui processo de mudança, revisão, rollback e validação.

O trade-off: você reduz configuração artesanal, mas precisa tratar a gestão central como parte crítica da operação.

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.

flowchart LR
  subgraph App["VPCs de aplicacao"]
    Workloads["Workloads\nEC2 / EKS / Lambda / Bancos"]
    AppRoutes["Tabelas de rota"]
  end

  subgraph Network["Conectividade central"]
    TGW["Transit Gateway"]
  end

  subgraph Inspection["VPC de inspecao"]
    GWLBE["GWLB Endpoints"]
    GWLB["Gateway Load Balancer"]
    FW1["VM-Series\nFirewall A"]
    FW2["VM-Series\nFirewall B"]
  end

  subgraph Egress["VPC de saida"]
    NAT["NAT Gateway"]
    IGW["Internet Gateway"]
  end

  Internet((Internet))
  Panorama["Panorama\ngestao central"]
  Logs["Logs e eventos"]

  Workloads --> AppRoutes --> TGW --> GWLBE --> GWLB
  GWLB --> FW1 --> GWLB
  GWLB --> FW2 --> GWLB
  GWLB --> TGW --> NAT --> IGW --> Internet
  Panorama -. "templates e politicas" .-> FW1
  Panorama -. "templates e politicas" .-> FW2
  FW1 --> Logs
  FW2 --> Logs

  classDef app fill:#eef3ff,stroke:#5f6b84,color:#10151c;
  classDef net fill:#e8f7f8,stroke:#2a7f95,color:#10151c;
  classDef sec fill:#fff4ef,stroke:#ca4a3c,color:#10151c;
  classDef out fill:#fff8e6,stroke:#d6a84f,color:#10151c;
  classDef ops fill:#f7f9fb,stroke:#24304a,color:#10151c;
  class Workloads,AppRoutes app;
  class TGW,GWLBE,GWLB net;
  class FW1,FW2 sec;
  class NAT,IGW,Internet out;
  class Panorama,Logs ops;

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 inspeção. Lá, o tráfego entra por um Gateway Load Balancer Endpoint, passa pelo GWLB e chega a uma instância VM-Series.

O firewall avalia a sessão. Se a política permitir, o fluxo volta ao caminho de saída e segue para NAT Gateway e Internet Gateway.

sequenceDiagram
  participant App as Aplicacao
  participant RT as Rota da subnet
  participant TGW as Transit Gateway
  participant EP as GWLB Endpoint
  participant GWLB as Gateway Load Balancer
  participant FW as VM-Series
  participant NAT as NAT Gateway
  participant Net as Internet

  App->>RT: Envia trafego para fora
  RT->>TGW: Proximo salto e o Transit Gateway
  TGW->>EP: Encaminha para a VPC de inspecao
  EP->>GWLB: Entrega ao servico de inspecao
  GWLB->>FW: Mantem o fluxo em um firewall saudavel
  FW->>FW: Aplica politica, inspecao e logs
  FW->>GWLB: Devolve trafego permitido
  GWLB->>TGW: Retorna ao caminho de saida
  TGW->>NAT: Segue para egress
  NAT->>Net: Acessa o destino externo

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 tráfego de entrada exige o mesmo cuidado, só que com outra pergunta: antes de chegar à aplicação, por onde esse pacote precisa passar? 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.

flowchart TB
  D1{"Inspecao por VPC\nou centralizada?"}
  D1 -->|"por VPC"| A1["Menos dependencia central\nmais repeticao e variacao"]
  D1 -->|"centralizada"| A2["Mais padronizacao\nmais responsabilidade no centro"]

  D2{"Rota direta para NAT\nou caminho inspecionado?"}
  D2 -->|"direta"| B1["Caminho simples\nmenos controle comum"]
  D2 -->|"inspecionada"| B2["Controle consistente\nmais tabelas de rota"]

  D3{"Configuracao manual\nou Panorama + bootstrap?"}
  D3 -->|"manual"| C1["Comeco rapido\nrisco de deriva"]
  D3 -->|"centralizada"| C2["Mudanca governada\nmais disciplina operacional"]

  classDef question fill:#f7f9fb,stroke:#24304a,color:#10151c;
  classDef risk fill:#fff4ef,stroke:#ca4a3c,color:#10151c;
  classDef choice fill:#e8f7f8,stroke:#2a7f95,color:#10151c;
  class D1,D2,D3 question;
  class A1,B1,C1 risk;
  class A2,B2,C2 choice;

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?
flowchart LR
  Change["Mudanca aprovada\nrota ou politica"] --> Deploy["Aplicacao\nTerraform / Panorama"]
  Deploy --> Checks["Validacoes\nhealth, rota, target"]
  Checks --> Traffic["Trafego real\nfluxo representativo"]
  Traffic --> Logs["Logs\nfirewall, rede, metricas"]
  Logs --> Review["Revisao\npermitiu, bloqueou, voltou"]
  Review --> Decision{"Resultado"}
  Decision -->|"ok"| Document["Registrar evidencia"]
  Decision -->|"falha"| Rollback["Rollback\nrota ou politica"]

  classDef flow fill:#e8f7f8,stroke:#2a7f95,color:#10151c;
  classDef observe fill:#eef3ff,stroke:#5f6b84,color:#10151c;
  classDef decision fill:#fff8e6,stroke:#d6a84f,color:#10151c;
  classDef risk fill:#fff4ef,stroke:#ca4a3c,color:#10151c;
  class Change,Deploy,Checks,Traffic flow;
  class Logs,Review,Document observe;
  class Decision decision;
  class Rollback risk;

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 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 inspeção e VPC de saída?
  • As tabelas de rota deixam claro o caminho de ida e volta?
  • 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.

Referências Públicas

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.