AWS Cloud WAN vs Transit Gateway: A Comparação Honesta de 2026 para Engenheiros

AWS Cloud WAN não é meramente um "Transit Gateway v2". É uma mudança arquitetural fundamental de um modelo de roteamento imperativo, com escopo regional, para uma estrutura global, declarativa e orientada por políticas para a rede na nuvem. Embora o AWS Transit Gateway (TGW) continue sendo uma ferramenta poderosa e econômica para topologias hub-and-spoke regionais, o Cloud WAN é a resposta estratégica da AWS para a agonia operacional de gerenciar redes multi-região em larga escala. Para qualquer organização que gerencia mais do que alguns VPCs em vários continentes, entender as compensações entre esses dois serviços não é mais um exercício acadêmico – é uma decisão crítica de design com implicações duradouras para custo, agilidade e segurança em 2026 e além.

Primitivas Arquiteturais: Hub-and-Spoke vs. Malha Global

Um AWS Transit Gateway é um recurso regional. Ele funciona como um roteador hub-and-spoke clássico, conectando VPCs, VPNs e Direct Connect Gateways (DXGW) dentro de uma única região AWS. Seu modelo mental é familiar a qualquer engenheiro de rede: ele possui attachments e route tables. Você define imperativamente como o tráfego flui associando attachments a route tables específicas e criando rotas estáticas ou propagadas. Para construir uma rede global, você deve fazer o BGP peering manualmente entre TGWs em diferentes regiões, formando uma malha completa de conexões que você é responsável por gerenciar. Este processo, embora funcional, cria uma sobrecarga operacional significativa e não escala bem. Cada BGP peering é um ponto de falha, um fardo de configuração e um item de custo de transferência de dados separado.

O Cloud WAN abstrai essa complexidade. Sua primitiva central é a Core Network, um único objeto global que representa toda a espinha dorsal da sua rede. Dentro desta Core Network, você implanta Core Network Edges (CNEs) nas regiões AWS desejadas. Esses CNEs são os pontos de presença regionais para sua rede global. VPCs, VPNs e DXGWs se anexam ao seu CNE local. Crucialmente, o roteamento entre CNEs sobre o AWS global backbone é automático e gerenciado pela AWS. Você não configura BGP peering inter-região; você simplesmente declara quais partes da sua rede podem se comunicar, e o Cloud WAN lida com a lógica subjacente de pathing e roteamento. Ele transforma a rede de uma coleção de hubs discretos e conectados manualmente em uma única malha global lógica.

Roteamento e Segmentação: TGW Route Tables vs. Core Network Policy

Esta é a diferença mais crítica. Com o Transit Gateway, o roteamento é granular e imperativo. Você pode ter uma dúzia de route tables por TGW: uma para VPCs de produção, uma para desenvolvimento, uma para shared services, uma para a VPC de inspeção, outra para tráfego de egress, e assim por diante. Propagar rotas de 100 VPCs para as tabelas corretas e garantir roteamento simétrico através de um appliance de firewall stateful como um PA-5440 requer uma configuração meticulosa e propensa a erros. Um administrador deve entender as implicações de cada rota estática e configuração de propagação. Oferece controle máximo, mas ao custo de alta carga cognitiva.

O Cloud WAN substitui isso por uma Core Network Policy (CNP). A CNP é um único documento JSON que define a intenção da sua rede de forma declarativa. As duas principais construções dentro da política são Segments e Attachment Policies.

Core Network Segments

Um Segment é uma partição de rede lógica, análoga a uma instância VRF (Virtual Routing and Forwarding) em um roteador tradicional como um Catalyst 9500-48UXM. Segmentos comuns incluem production, development, shared_services e onprem. Por padrão, os segments são domínios de roteamento completamente isolados. Uma VPC no segment production não pode rotear para uma VPC no segment development, mesmo que estejam na mesma região. Isso fornece isolamento poderoso e de alto nível sem tocar em uma única route table.

Attachment Policies e Segment Actions

Uma Attachment Policy mapeia attachments para segments com base em tags. Por exemplo, você pode definir uma regra: "Qualquer attachment VPC com a tag network-segment: prod é automaticamente mapeado para o segment production." Isso é policy-as-code para onboarding de rede. Quando uma nova VPC de produção é criada com a tag correta, o Cloud WAN a coloca automaticamente no domínio de roteamento correto.

Para permitir a comunicação entre segments, você usa Segment Actions dentro da CNP. Por exemplo, para permitir que o segment production alcance o segment shared_services, você definiria uma ação create-route no segment production que aponta para o segment shared_services. Você também pode definir rotas blackhole ou rotas estáticas para attachments específicos, como um appliance de segurança para inspeção de tráfego. Este modelo declarativo — definindo *o que* deve ser conectado, não *como* — é a essência do poder do Cloud WAN.

Dimensionamento e Análise de Custos no Mundo Real (Preços de 2026)

Vamos modelar um cenário tangível: uma empresa com 50 VPCs em us-east-1 e 50 em eu-west-1. Eles têm um Direct Connect de 10 Gbps em cada região, conectando-se de volta aos seus data centers. O total de dados processados através da core network é de 20 TB por mês por região, com 10 TB desse tráfego fluindo entre as regiões dos EUA e da UE.

Modelo de Custo 1: Dual Transit Gateways com BGP Peering

• Horas de Instância TGW: 2 TGWs * $0.05/hr * 730 hrs/mês = $73.00
• Horas de Attachment: 102 attachments (100 VPCs + 2 DXGWs) * $0.05/attachment-hr * 730 hrs/mês = $3,723.00
• Processamento de Dados Regional: 30 TB (20 TB VPC->VPC intra-região + 10 TB a serem enviados inter-região) * 2 regiões * $0.02/GB = $1,228.80 (aprox., pois parte do tráfego é processada duas vezes)
• Transferência de Dados Inter-Região: Este é o custo principal. 10 TB de dados enviados através de BGP peering TGW de us-east-1 para eu-west-1 incorre em uma taxa de transferência. 10.240 GB * $0.02/GB = $204.80.
• Total Mensal Estimado: ~$5,230

Modelo de Custo 2: Cloud WAN Global

• Horas de Core Network Edge: 2 CNEs (1 por região) * $0.299/hr * 730 hrs/mês = $436.54
• Horas de Attachment: 102 attachments * $0.05/attachment-hr * 730 hrs/mês = $3,723.00
• Processamento de Dados Cloud WAN: 40 TB de dados totais processados * $0.03/GB = $1,228.80 (Nota: o Cloud WAN tem uma taxa de processamento de dados em camadas, usamos uma taxa combinada para este exemplo).
• Transferência de Dados Inter-Região: Este é um benefício chave. O Cloud WAN não possui uma cobrança separada de transferência de dados por "BGP peering inter-região". O tráfego é coberto pela taxa de processamento de dados padrão, pois flui sobre o AWS Global Backbone gerenciado pelo serviço.
• Total Mensal Estimado: ~$5,388

À primeira vista, os custos parecem semelhantes. No entanto, o modelo Cloud WAN simplifica o faturamento e elimina o custo punitivo de transferência de dados inter-região. À medida que o número de regiões cresce, o custo e a complexidade de um modelo de BGP peering TGW em malha completa aumentam de forma não linear, enquanto o modelo Cloud WAN escala de forma mais previsível. O pequeno prêmio de custo para o Cloud WAN oferece uma imensa simplicidade operacional e um modelo de política global e unificado.

Padrões de Segurança e Inspeção

Inserir um firewall, como um FortiGate 1800F ou uma Palo Alto Networks VM-Series rodando PAN-OS 11.2, é um requisito padrão. Com TGW, isso geralmente envolve uma "inspection VPC" dedicada. Você manipula as route tables para forçar o tráfego de uma VPC spoke para o TGW, depois para a ENI da inspection VPC, depois de volta para o TGW e finalmente para o seu destino. Isso é chamado de "hairpinning" e requer um gerenciamento cuidadoso de múltiplas route tables para garantir a simetria.

O Cloud WAN simplifica isso com o Appliance Mode para attachments de VPC. Quando habilitado no attachment da inspection VPC, o Cloud WAN garante automaticamente que o tráfego fluindo entre diferentes segments (ex.: prod-para-onprem) seja direcionado para a mesma Availability Zone na inspection VPC para ingresso e egresso. Dentro de sua Core Network Policy, você simplesmente define uma rota estática no seu segment production para 0.0.0.0/0 que aponta para o attachment da inspection VPC. Esta única mudança de política direciona o tráfego para inspeção sem a complexa manipulação de route tables exigida pelo TGW.

Armadilha Comum: Políticas de Segmento Excessivamente Permissivas

O poder declarativo da Core Network Policy é uma faca de dois gumes. Um erro comum é criar regras de compartilhamento amplas e permissivas no início de uma implantação. Por exemplo, um administrador de rede que tenta habilitar rapidamente a conectividade pode criar uma regra que compartilha todas as rotas de todos os segments com todos os outros segments. Essa ação efetivamente nivela a rede, anulando completamente os benefícios de isolamento da segmentação e recriando o problema de "uma grande rede plana" que os segments foram projetados para resolver. É o equivalente no Cloud WAN a colocar todos os seus attachments de VPC em uma única route table do TGW. A CNP deve ser tratada como uma peça crítica da infrastructure-as-code, sujeita a rigoroso controle de mudanças, linting e auditoria.

Quando NÃO Usar o Cloud WAN (O Ponto Forte do TGW)

Apesar de suas vantagens, o Cloud WAN não é um substituto universal para o TGW. O Transit Gateway mantém sua posição em vários cenários chave:

• Implantações de Região Única: Se toda a sua pegada de nuvem existe em uma única região AWS e você não tem planos de expansão, o Cloud WAN é um exagero. O modelo regional hub-and-spoke do TGW é um ajuste perfeito e mais econômico, pois você evita o custo mais alto por hora de um Core Network Edge.
• Sensibilidade Extrema a Custos: Para projetos de pequena escala ou proofs-of-concept com tráfego mínimo, o custo base de attachments e processamento do TGW é menor do que o ponto de entrada para um Cloud WAN multi-região. Se cada dólar é escrutinado e a simplicidade operacional é uma prioridade menor, o TGW prevalece.
• Controle Granular de BGP: Cenários de roteamento avançados que dependem da manipulação de atributos BGP como AS_PATH prepending ou local preference para influenciar o pathing entre múltiplas conexões on-premise (ex.: Direct Connects primário/backup) podem ser controlados mais diretamente no TGW. Embora o Cloud WAN suporte BGP, seu modelo de política abstrai alguns dos controles de baixo nível que um engenheiro de rede experiente pode querer ajustar em um dispositivo como um Juniper SRX5800 ou Cisco ASR.

O Veredito de 2026: Do Hub Regional para a Estrutura Global

O Transit Gateway democratizou as redes em nuvem, fornecendo o primeiro modelo hub-and-spoke escalável nativo da AWS. Continua sendo uma excelente e econômica escolha para arquiteturas regionais. No entanto, o Cloud WAN é a direção estratégica clara para qualquer empresa que opera em escala global. Ele troca o controle granular e imperativo do TGW por um modelo declarativo e orientado por políticas que simplifica dramaticamente o gerenciamento de conectividade multi-região, segmentação e inspeção de segurança. Ao abstrair a complexidade de roteamento subjacente em uma única Core Network Policy, o Cloud WAN permite que os engenheiros gerenciem a rede com base na intenção, não nos detalhes de implementação. Para organizações que constroem uma espinha dorsal de nuvem estratégica para a próxima década, a conversa está mudando de "Devo usar um Transit Gateway?" para "Em que ponto nossa escala justifica uma migração para o Cloud WAN?"

Pronto para arquitetar uma rede global que escala com o seu negócio? Os engenheiros especialistas da techleague.io são especializados em projetar e implementar soluções de rede AWS robustas, seguras e econômicas. Podemos ajudá-lo a navegar pelas complexidades da política do Cloud WAN, otimizar suas implantações de TGW e construir uma infraestrutura de nuvem pronta para o futuro. Explore nossas postagens relacionadas sobre Direct Connect SiteLink vs. DXGW para Conectividade On-Premise e nosso mergulho profundo na implantação de firewalls Palo Alto VM-Series na AWS.