AWS TGW vs Azure vWAN vs GCP NCC: Guerras de Backbone Multi-Cloud 2026

Escolher um backbone de rede multi-cloud em 2026 é menos sobre lealdade à marca e mais sobre adequação arquitetônica e TCO. AWS Transit Gateway (TGW), Azure Virtual WAN (vWAN) e Google Cloud Network Connectivity Center (NCC) oferecem recursos hub-and-spoke e mesh-like, mas suas arquiteturas subjacentes, modelos de preços e pontos de integração diferem substancialmente. Esta análise foca nas capacidades técnicas brutas e implicações econômicas para grandes empresas.

Filosofias Arquitetônicas e Limites de Escala

AWS TGW, particularmente quando ampliado pelo Cloud WAN para conectividade mesh global, oferece uma abordagem fundamentalmente orientada a objetos. Cada TGW é uma construção regional, suportando até 5000 attachments (VPC/VPN/Direct Connect Gateway). O Cloud WAN orquestra múltiplos TGWs em uma rede global, gerenciando políticas de roteamento e segmentação entre regiões e contas. Os limites de escala padrão do TGW são críticos: 5000 rotas por tabela de rotas, 100 TGW attachments e 20 TGW route tables por TGW são gargalos comuns para implantações muito grandes. O inter-region peering entre TGWs depende das capacidades de VPC peering inter-regional, agora amplamente substituídas pelo Transit Gateway Inter-Region Peering, oferecendo maior largura de banda e menor latência do que VPNs tradicionais.

Azure Virtual WAN é um serviço gerenciado pela Microsoft que atua como um hub para vários tipos de conectividade (VPN, ExpressRoute, VNet peering). Ele emprega uma arquitetura global e gerenciada centralmente. Hubs Standard suportam até 2000 conexões VNet. Cada ExpressRoute Gateway dentro de um hub vWAN pode suportar até 10 Gbps e VPN Gateways até 10 Gbps (dependendo da scale unit). Um diferenciador chave é o conceito de um 'Secure Hub' integrado com o Azure Firewall Manager, permitindo a aplicação centralizada de políticas de segurança (IDP/IPS, filtragem de URL) para todo o tráfego que transita pelo hub, incluindo VNet-to-VNet e on-premises-to-VNet. O routing intent do Azure permite controle granular sobre os fluxos de tráfego de entrada e saída dentro do hub, um recurso que geralmente requer manipulação de BGP community or complex route table associations na AWS.

GCP Network Connectivity Center (NCC) é conceitualmente similar a um fabric global, focado em conectar sites on-premises, VPCs e até outros provedores de nuvem (via Cross-Cloud Interconnect). Os hubs NCC gerenciam centralmente os spokes (VPC networks, VPN tunnels, Partner Interconnect, Cross-Cloud Interconnect) globalmente. Ao contrário do TGW ou vWAN, o NCC se apresenta como uma única entidade global, simplificando a implantação multi-região. Ele suporta até 1000 spokes por hub. O design enfatiza a simplicidade para conectar diversas workloads e localizações a uma rede unificada. O Cross-Cloud Interconnect, uma oferta relativamente nova, conecta diretamente o GCP com a AWS, oferecendo latência e throughput previsíveis, uma capacidade não disponível nativamente na mesma medida entre AWS e o backbone nativo do Azure sem um circuito direto ou overlay de fornecedor.

Roteamento, Segmentação e Integração BGP

AWS TGW depende fortemente de route tables anexadas a VPCs e Direct Connect Gateways específicos. A segmentação é alcançada atribuindo attachments a diferentes TGW route tables e configurando regras de propagação e associação. O roteamento entre contas é gerenciado via TGW Resource Share. BGP é fundamental para attachments de VPN e DX Gateway, com o TGW anunciando suas rotas e aprendendo rotas de seus roteadores on-premises. Cada TGW pode funcionar como um dynamic routing peer. O Cloud WAN estende isso com propagação automática de rotas e policy-based routing entre regiões definidas em uma global network policy. O roteamento entre TGW route tables arbitrárias requer static routes explícitas ou policy-based routing dentro do Cloud WAN.

Os hubs do Azure vWAN expõem routing tables que podem ser associadas a várias conexões. O Routing Intent e as Routing Policies permitem que os administradores ditem como o tráfego flui, por exemplo, forçando o tráfego direcionado à Internet através do firewall de um Secure Hub ou roteando o tráfego VNet-to-VNet diretamente. BGP é amplamente utilizado para conexões ExpressRoute e VPN Gateway no hub vWAN. Circuitos ExpressRoute geralmente fazem peering com o Microsoft enterprise edge (MSEE), que então injeta rotas no hub vWAN. Para ambientes híbridos, o vWAN simplifica a agregação e anúncio de rotas, reduzindo significativamente a complexidade do BGP vista com modelos tradicionais hub-and-spoke do Azure usando UDRs.

GCP NCC usa uma capacidade de roteamento global similar à rede geral do Google Cloud. Spokes anexados a um hub NCC trocam rotas automaticamente. Cada spoke recebe uma route table e as rotas são propagadas. BGP é empregado para attachments de VPN e Interconnect. Para o Cross-Cloud Interconnect, as sessões BGP são estabelecidas diretamente com o provedor de nuvem parceiro (por exemplo, AWS Direct Connect Gateway) no local do interconnect, permitindo a troca de rotas entre ambientes de nuvem. A força do NCC reside no seu anúncio e aprendizado de rotas globais unificados, eliminando a necessidade de configuração explícita de roteamento inter-regional ou setups complexos de routing transitivo geralmente exigidos para outras conectividades multi-região.

Throughput, Latência e Desempenho Inter-Região

O throughput máximo do AWS TGW por attachment é tipicamente de 50 Gbps, com uma agregação de até 100 Gbps por TGW em múltiplos attachments para tráfego inter-VPC. O Inter-Region TGW Peering oferece largura de banda significativamente maior do que VPN, muitas vezes excedendo 5 Gbps por conexão de peer, mas pode escalar até 50 Gbps dependendo da demanda e capacidade regional, com latência comparável ao VPC peering puro entre regiões. Para on-premises, conexões Direct Connect de até 100 Gbps podem terminar em um Direct Connect Gateway, que então se anexa a um TGW. O desempenho é excelente, desde que o TGW não seja sobrecarregado pelo volume de VPCs e rotas.

A capacidade de throughput do hub Azure vWAN é dinâmica; os gateways VPN escalam até 10 Gbps e os gateways ExpressRoute até 20 Gbps (vários ExpressRoutes podem terminar). O throughput agregado do hub vWAN entre VNets é frequentemente citado em torno de 100 Gbps para grandes hubs. O tráfego VNet-to-VNet inter-regional através do vWAN aproveita o backbone global da Microsoft, entregando conectividade de alta velocidade e baixa latência dentro da rede Azure. Secure Hubs com Azure Firewall podem introduzir latência dependendo do SKU do firewall e da carga de inspeção. O desempenho entre regiões é geralmente forte devido à rede global da Microsoft altamente otimizada.

GCP NCC aproveita a rede privada global de alto desempenho do Google. O tráfego VPC-to-VPC e a conectividade on-premises (VPN/Interconnect) se beneficiam do backbone de baixa latência e alta largura de banda do Google. O Cross-Cloud Interconnect pode atingir até 10 Gbps por link para a AWS, com múltiplos links para maior capacidade. A latência entre as regiões do Google Cloud é consistentemente uma das mais baixas da indústria, o que se traduz diretamente nas características de desempenho do NCC. Esta é uma vantagem significativa para aplicações sensíveis à latência que abrangem várias regiões de nuvem ou requerem comunicação multi-cloud contínua.

Integração de Appliances SD-WAN e Serviços de Segurança

A integração de SD-WAN no AWS TGW tipicamente envolve o estabelecimento de IPsec VPNs de dispositivos SD-WAN de branch ou appliances virtuais (por exemplo, FortiGate-VM, Palo Alto Networks VM-Series, Cisco Catalyst 8000V) em spokes diretamente para o TGW. O AWS Network Manager fornece um painel centralizado para monitorar redes globais, incluindo TGWs, Cloud WAN e sites on-premises conectados via VPN ou Direct Connect. Embora não hospede recursos de segurança nativamente, o TGW pode direcionar o tráfego para 'inspection VPCs' contendo firewalls virtuais para aplicação centralizada de políticas de segurança. Isso requer manipulação explícita de rotas e muitas vezes envolve configurações de firewall ECMP ou Active/Standby, como Transit Gateway VPN ECMP para roteamento simétrico.

Azure vWAN oferece capacidades SD-WAN integradas. Muitos fornecedores líderes de SD-WAN (por exemplo, Fortinet, Versa, VMware, Cisco Viptela) integraram suas soluções com o vWAN, simplificando a conectividade de filiais. Um appliance virtual gerenciado pode ser implantado diretamente em um hub vWAN, simplificando a implantação e reduzindo a sobrecarga operacional em comparação com uma VNet separada. A funcionalidade Secure Hub com Azure Firewall Manager (empregar FortiGate-VM ou Palo Alto VM-Series em vez de Azure Firewall também é possível, mas requer uma VNet separada) é um grande diferencial para segurança centralizada forçada. Esta integração direta otimiza o processo de direcionar todo o tráfego de branch, VNet e internet através de um ponto de inspeção de segurança comum.

A história de integração do GCP NCC com SD-WAN está evoluindo. Por enquanto, ela segue em grande parte o modelo VPN-to-spoke, onde os appliances SD-WAN estabelecem IPsec VPNs para um VPN gateway em um spoke VPC, que então é anexado ao NCC. Embora grandes fornecedores como Fortinet e Palo Alto ofereçam appliances virtuais robustos para GCP, o NCC não possui (ainda) a mesma integração profunda que o Secure Hub do vWAN ou o suporte nativo a SD-WAN. No entanto, o NCC facilita a conexão de implantações SD-WAN on-premises aos serviços do Google Cloud e outros ambientes de nuvem através de seus vários tipos de spoke, centralizando o gerenciamento dessas conexões sem ditar a solução SD-WAN em si. A próxima integração Private Service Connect com o NCC promete uma maior simplificação para acessar SaaS e serviços de parceiros.

Modelos de Custo: Egress e Attachments

Recurso	AWS Transit Gateway (TGW)	Azure Virtual WAN (vWAN)	GCP Network Connectivity Center (NCC)
Custo Horário por Hub	US$ 0,05/hora por TGW + US$ 0,05/hora por conexão de inter-region peering	Hub Padrão: US$ 0,25/hora. Secure Hub: US$ 0,35/hora + custos do Azure Firewall.	US$ 0,025/hora por unity de hub (regional, 1000 spokes)
Custo por Attachment	US$ 0,05/GB processado inbound/outbound (taxa de dados processados)	Sem cobrança direta por attachment. Taxas de VPN/ExpressRoute gateway se aplicam.	Hora da Unidade Spoke: US$ 0,0025/hora por spoke. Dados processados: US$ 0,02/GB para todos os dados que transitam pelo NCC.
Transferência de Dados Inter-Region	US$ 0,02/GB - US$ 0,09/GB (dependendo das regiões)	Varia por par de regiões, tipicamente US$ 0,02/GB - US$ 0,08/GB	US$ 0,02/GB - US$ 0,12/GB (varia entre regiões, específico para Cross-Cloud)
Exemplo: 50 VPCs/VNets/Spokes (aprox)	~50 VPCs * US$ 0,05/GB (dados processados) + TGW horário. Total ~0,05 * 24 * 30 = US$ 36/mês (somente TGW). Dados a 100TB/mês: 100 * 1024 * 0,05 = US$ 5120.	Hub Padrão ~0,25 * 24 * 30 = US$ 180/mês. Sem taxas diretas de spoke. Dados via ExpressRoute/VPN.	Unidade de Hub NCC ~0,025 * 24 * 30 = US$ 18/mês. 50 Unidades de Spoke ~50 * 0,0025 * 24 * 30 = US$ 90/mês. Dados a 100TB/mês: 100 * 1024 * 0,02 = US$ 2048.
Exemplo: 500 VPCs/VNets/Spokes (aprox)	~500 VPCs * US$ 0,05/GB (dados processados) + TGW horário. Múltiplos TGWs provavelmente necessários em grandes regiões devido aos limites. Dados a 500TB/mês: 500 * 1024 * 0,05 = US$ 25600.	Hub Padrão ~0,25 * 24 * 30 = US$ 180/mês. Routing Intent pode adicionar taxas. Taxas de dados.	Unidade de Hub NCC ~0,025 * 24 * 30 = US$ 18/mês. 500 Unidades de Spoke ~500 * 0,0025 * 24 * 30 = US$ 900/mês. Dados a 500TB/mês: 500 * 1024 * 0,02 = US$ 10240.

Os modelos de custo são significativamente diferentes. O AWS TGW cobra por GB de dados 'processados' (inbound ou outbound para qualquer attachment). Isso significa que o tráfego east-west dentro de um TGW incorre em uma cobrança. O Azure vWAN cobra principalmente por hora pelo próprio hub e por quaisquer ExpressRoute ou VPN Gateways implantados nele. As taxas de egress de dados se aplicam ao tráfego que sai do Azure para a Internet, mas o tráfego VNet-to-VNet dentro de um hub vWAN não incorre em cobranças adicionais por GB para o próprio serviço vWAN (as taxas padrão de VNet peering ainda se aplicam se não estiver usando o vWAN para VNet para VNet). O GCP NCC cobra uma taxa horária baixa pela unidade do hub e uma taxa horária por 'spoke unit'. Assim como o TGW, ele cobra pelos dados processados (em trânsito) através do NCC. No entanto, para dados intra-NCC, o GCP cobra uma taxa por GB mais baixa em comparação com a taxa fixa de US$ 0,05/GB do TGW, o que pode ser significativo em escala.

Para um cenário com 500 VPCs/VNets/Spokes e 500TB/mês de tráfego interno agregado, a AWS poderia rapidamente se tornar a mais cara devido à sua taxa de processamento de dados de US$ 0,05/GB. Os US$ 0,02/GB de dados processados no NCC do GCP são mais competitivos. O modelo do Azure, que em grande parte abstrai as cobranças de dados VNet-to-VNet internas ao hub, pode ser altamente atraente para organizações com enormes fluxos de dados internos. No entanto, isso é amplamente verdadeiro para o tráfego que permanece dentro do escopo regional do hub vWAN. O tráfego multi-região do Azure vWAN incorrerá em taxas de transferência de dados inter-regionais, semelhantes à AWS e ao GCP.

Observability e Troubleshooting

A AWS fornece métricas do CloudWatch para TGW (por exemplo, BytesIn/Out, Packet Drop). Os Flow Logs para attachments do TGW permitem visibilidade granular do tráfego, permitindo a integração com serviços como VPC Flow Logs para S3, CloudWatch Logs ou SIEMs de terceiros. O AWS Network Manager oferece uma visão topológica e status de conectividade para TGW e conexões associadas. A solução de problemas de roteamento geralmente envolve a inspeção de tabelas de rotas do TGW, configurações de propagação e associações de attachment, juntamente com o status da sessão BGP para VPN/DX.

O Azure vWAN oferece monitoramento abrangente através do Azure Monitor, fornecendo métricas para utilização do hub, throughput do gateway e status da conexão VPN/ExpressRoute. Componentes do Network Watcher, como NSG Flow Logs (para Secure Hubs) e connection monitor, ajudam a visualizar padrões de tráfego e diagnosticar problemas de conectividade. A natureza global do console de gerenciamento do vWAN simplifica a solução de problemas inter-regionais, fornecendo um painel único para todas as conexões e rotas do hub. Os logs do Azure Firewall dentro de um Secure Hub oferecem inspeção profunda do tráfego e registro de eventos de segurança.

O GCP NCC também se integra ao Cloud Monitoring para métricas e ao Cloud Logging para logs de auditoria e fluxo. Os VPC Flow Logs para spokes fornecem registros detalhados de tráfego. O Google Cloud Network Intelligence Center fornece visualizações de topologia, monitoramento de desempenho e insights sobre a saúde da rede em spokes anexados. Dado o forte foco do GCP em observability, a solução de problemas do NCC geralmente aproveita as ferramentas familiares do Cloud Console e a suíte Stackdriver. O monitoramento de sessão BGP para Interconnects é robusto, fornecendo status detalhado e rotas anunciadas.

Snippets de Configuração e Exemplo do Mundo Real

Attachment do AWS TGW a uma VPC com propagação de rotas:

resource "aws_ec2_transit_gateway_vpc_attachment" "example" {
  vpc_id                        = aws_vpc.example.id
  transit_gateway_id            = aws_ec2_transit_gateway.example.id
  subnet_ids                    = [
    aws_subnet.example_az1.id,
    aws_subnet.example_az2.id,
  ]
  tags = {
    Name = "Example-VPC-Attachment"
  }
}

resource "aws_ec2_transit_gateway_route_table_association" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

Este snippet Terraform demonstra como anexar uma VPC a um AWS TGW e, em seguida, associar e propagar suas rotas para uma TGW route table específica, o que é fundamental para segmentação e conectividade. Para implantações em larga escala, as políticas do Cloud WAN gerenciam essas associações e propagações dinamicamente em múltiplos TGWs.

Veredito

AWS TGW (com Cloud WAN) se destaca quando:

• Você é uma organização nativa da AWS com mais de 90% de sua infraestrutura na AWS.
• Você exige controle refinado sobre a propagação e associação de rotas em um ambiente AWS multi-account e multi-região complexo.
• Você precisa integrar Direct Connects existentes e um grande número de VPNs, especialmente com requisitos específicos de BGP community.
• Seu fluxo de dados east-west interno é moderado, já que a cobrança de US$ 0,05/GB de processamento de dados pode escalar rapidamente em grandes volumes.

Azure Virtual WAN se destaca quando:

• Você tem um ambiente híbrido centric da Microsoft, aproveitando pesadamente o ExpressRoute e os serviços do Azure.
• A aplicação centralizada de segurança via Secure Hubs e Azure Firewall Manager é um requisito crítico para conformidade regulatória e gerenciamento simplificado.
• Você está implantando um overlay SD-WAN global e prefere integração e gerenciamento profundos com o backbone da nuvem.
• Seu tráfego VNet-to-VNet dentro de uma região é extremamente alto, pois o preço baseado em hub pode ser mais previsível do que o processamento por GB para esse tipo de tráfego.

GCP Network Connectivity Center (NCC) se destaca quando:

• Você está liderando com o GCP para a maior parte de sua pegada na nuvem, mas também precisa de conectividade eficiente e de alto desempenho com a AWS ou outras nuvens via Cross-Cloud Interconnect.
• A simplicidade no gerenciamento de redes globais é uma prioridade máxima, oferecendo uma única construção global em vez de TGWs regionais ou peerings inter-regionais explícitos.
• Sua organização valoriza o backbone global altamente otimizado do Google para conectividade de baixa latência e alta largura de banda entre regiões.
• A eficiência de custos para altos volumes de transferência de dados internos é crucial, dada a menor cobrança de processamento de dados do NCC (US$ 0,02/GB) em comparação com o AWS TGW para tráfego interno.

Leitura relacionada

• AWS Network Firewall vs Palo Alto VM-Series 2025
• Estratégias do Azure ExpressRoute para Empresas Globais 2025
• GCP Cloud VPN vs Interconnect: Análise Aprofundada de Desempenho
• Integração Multi-Cloud do Fortinet SD-WAN