Azure Virtual WAN vs Hub-and-Spoke: A Decisão Empresarial de 2026

Para arquitetos de redes empresariais, o debate entre Azure Virtual WAN (vWAN) e uma topologia hub-and-spoke autogerenciada não é mais uma simples questão de infraestrutura gerenciada versus não gerenciada. À medida que olhamos para 2026, a decisão depende de uma compreensão diferenciada dos padrões de tráfego, da profundidade de recursos dos appliances de segurança necessários e do custo total de propriedade em escala. A promessa de controle quase infinito e programático sobre um 'global transit fabric' torna o vWAN o padrão estratégico para a maioria das grandes empresas, movendo a conversa de mera conectividade para redes inteligentes e baseadas em políticas.

O Clássico Hub-and-Spoke: Controle Máximo, Complexidade Máxima

O modelo tradicional de hub-and-spoke do Azure é a tradução direta do design de data centers on-premises. Uma Virtual Network (VNet) de hub central hospeda serviços compartilhados, sendo os mais críticos um par de Network Virtual Appliances (NVAs) para inspeção de tráfego e controle de roteamento. Os 'Spokes', que abrigam as cargas de trabalho das aplicações, são conectados ao hub via VNet peering. O controle é explícito e granular, principalmente através de User-Defined Routes (UDRs). Você cria uma tabela de rotas, aplica-a a uma sub-rede e define o próximo salto para prefixos específicos – tipicamente o internal load balancer que está à frente do seu par de NVAs.

Neste modelo, o NVA é rei. Seja um Palo Alto Networks VM-Series executando PAN-OS 11.2, um FortiGate-VM em FortiOS 7.6 ou um Cisco Catalyst 8000V, você mantém controle total sobre sua configuração. Você gerencia high availability (HA), escalabilidade (via VM Scale Sets) e políticas de roteamento intrincadas diretamente no appliance. Esta é a sua maior força e sua fraqueza mais significativa. O ônus operacional de gerenciar pares de HA, tabelas de rotas em dezenas ou centenas de spokes, e a infraestrutura de VM subjacente é substancial. Uma mudança na política de roteamento, como a introdução de um novo serviço no hub, pode exigir a atualização de UDRs em cada VNet de spoke – um processo frágil e propenso a erros, mesmo com práticas maduras de Infrastructure as Code (IaC) usando Terraform ou Bicep.

Virtual WAN: Azure como um Provedor Global de Trânsito

O Azure Virtual WAN abstrai a infraestrutura de rede subjacente em um serviço gerenciado pela plataforma. Em sua essência, o vWAN fornece uma arquitetura de rede de trânsito global que simplifica a conectividade 'any-to-any' entre filiais (VPN/SD-WAN), usuários remotos, data centers (ExpressRoute) e VNets. Você implanta um Virtual Hub em cada região Azure necessária, e este hub atua como o centro do seu universo para essa geografia. A conectividade não é baseada em peering, mas em “conexões” ao hub. O próprio hub contém roteadores gerenciados que propagam rotas automaticamente entre todas as entidades conectadas.

O diferenciador chave é este roteamento integrado. Quando você conecta uma VNet ao hub do vWAN, seu espaço de endereçamento é aprendido pelo roteador do hub. Quando você conecta um circuito ExpressRoute, seus prefixos anunciados são aprendidos. O roteador do hub então anuncia essas rotas aprendidas para todas as outras entidades conectadas com base na política. Isso elimina a necessidade de gerenciamento manual de UDRs para roteamento de trânsito. Adicionar uma nova VNet ou um novo escritório de filial não requer que você altere a configuração de qualquer spoke existente; o roteamento é atualizado dinamicamente. Esta é uma solução em nível de plataforma para o problema de escalabilidade que aflige os designs clássicos de hub-and-spoke.

Deep Dive em Secured Hubs: Azure Firewall Premium vs. NVA Integrado

O "Secured Virtual Hub" é onde a conversa sobre segurança começa. Este é um hub de vWAN com um appliance de segurança integrado. Você tem duas opções principais: Azure Firewall ou um NVA de terceiros do Azure Marketplace.

Azure Firewall Premium: O Nativo Capaz

Até 2026, o Azure Firewall Premium terá amadurecido para se tornar um NGFW-as-a-Service formidável. Ele já oferece recursos essenciais de prevenção de ameaças como IDPS baseado em assinaturas, inspeção TLS completa (um recurso notoriamente difícil de implementar na nuvem), filtragem de URL e filtragem por categoria web. Para inspeção de tráfego east-west entre spokes ou egress north-south, ele é muitas vezes suficiente. Sua principal vantagem é ser um verdadeiro serviço de plataforma. Você não gerencia as VMs subjacentes. Você define uma política, a associa ao hub, e o Azure lida com a escalabilidade e resiliência. O throughput é definido em implantações baseadas em SKU, começando em 20 Gbps e escalando para mais alto.

No entanto, ele não é um substituto direto para um NVA dedicado de primeira linha. Uma equipe de segurança acostumada às políticas granulares de App-ID de um PA-5440 ou aos advanced threat feeds de um FortiGate 1800F achará os recursos do Azure Firewall amplos, mas não tão profundos. Os conjuntos de assinaturas, embora robustos, podem não ser tão especializados, e a personalização de perfis de prevenção de ameaças é menos granular do que o disponível em um SO NVA dedicado como PAN-OS ou FortiOS.

NVA em vWAN: O Melhor dos Dois Mundos?

Para organizações que exigem sua marca específica de NGFW, o vWAN permite a implantação de NVAs diretamente no hub. Isso não é o mesmo que implantar um NVA em uma VNet de hub clássica. Quando você implanta um FortiGate ou Palo Alto Networks NVA em um hub vWAN, ele funciona como uma aplicação gerenciada. O Azure gerencia o ciclo de vida, o scale-out e a high availability do VMSS subjacente. Criticamente, o roteamento é tratado via BGP peering entre o NVA e o roteador do hub vWAN. Você não mais aplica UDRs para forçar o tráfego para o NVA; você usa vWAN Routing Intent and Policies para declarar quais fluxos de tráfego (Private, Internet) devem ser enviados ao NVA para inspeção primeiro. O NVA então inspeciona o tráfego e, se permitido, o roteia de volta para o roteador do hub para entrega subsequente. Isso mantém o roteamento centralizado e dinâmico do vWAN, permitindo uma inspeção de segurança best-in-class.

Análise de Dimensionamento e Custo: Uma História de Duas Topologias

Vamos modelar um cenário real para comparar custos. Considere uma empresa com presença em East US 2 e West Europe. Cada região tem um hub, 50 spoke VNets, um circuito ExpressRoute de 10 Gbps e 2.000 filiais SD-WAN conectando via VPN. Assuma 50TB de tráfego inter-spoke (VNet-to-VNet) por mês dentro de cada região.

Modelo de Custo Clássico Hub-Spoke (por região)

• Cluster NVA: Duas instâncias FortiGate-VM08 (para aproximadamente 10 Gbps de throughput de proteção contra ameaças) com licenciamento BYOL. O custo apenas das VMs é de aproximadamente $1,50/hr * 2 * 730 horas/mês = ~$2.190/mês. Adicione o licenciamento do software em cima disso.
• Azure Standard Load Balancer (Internal/External): ~$50/mês.
• Public IPs: ~$20/mês.
• VNet Peering (O vilão): Este é o custo crítico. O tráfego fluindo de Spoke A -> Hub -> Spoke B é cobrado pela entrada e saída no link de peering. Para 50TB de tráfego: 50 * 1024 GB = 51.200 GB. O custo é de $0,01 por GB. Assim, 51.200 GB * $0,01/GB * 2 (entrada/saída) = $1.024/mês. Este custo escala linearmente com o volume de tráfego.
• Overhead de Gerenciamento: Este custo oculto é significativo. As horas de engenharia necessárias para gerenciar UDRs, patching/upgrades de NVA e failover de HA são substanciais.

Modelo de Custo do Azure Virtual WAN (por região)

• Standard vWAN Hub: ~$1,25/hr * 730 horas = ~$912,50/mês.
• VNet Connections: 50 conexões * $0,05/hr * 730 horas = $1.825/mês.
• Scale Units: Para lidar com ~10 Gbps de tráfego VNet, você precisaria de 5 scale units (2 Gbps por unidade). Cada uma custa $0,25/hr. 5 * $0,25/hr * 730 horas = $912,50/mês.
• Processamento de Dados (VNet-to-VNet): O vWAN cobra pelo tráfego processado através do hub. Para nossos 55TB: 51.200 GB * $0,02/GB = $1.024/mês. Isso é comparável ao custo de peering, mas é mais previsível e inclui a infraestrutura de roteamento.
• Azure Firewall Premium: Uma implantação com capacidade de processamento de 10 Gbps e recursos premium custa ~$2.500/mês.

À primeira vista, os custos dos componentes do vWAN parecem mais altos. No entanto, o modelo vWAN elimina completamente as cobranças de peering VNet para tráfego de trânsito. Mais importante, ele reduz drasticamente o custo operacional de gerenciar a complexa teia de UDRs e NVAs autogerenciados. O Custo Total de Propriedade (TCO) em escala, especialmente em cenários multi-região, muitas vezes favorece o vWAN.

Roteamento Multi-região: A Vantagem Desleal do vWAN

É aqui que o vWAN realmente eclipsa o modelo clássico. Em uma configuração tradicional, conectar dois hubs regionais requer outro conjunto de NVAs para VPN hub-to-hub ou o uso de Global VNet Peering. O peering global é caro (~$0.035-$0.12/GB dependendo da região) e cria uma malha ponto-a-ponto que não escala. Com o vWAN, os hubs são conectados via a espinha dorsal global da Microsoft por padrão. Os roteadores de hub regionais trocam rotas, fornecendo conectividade inter-hub contínua. Você obtém uma rede global totalmente roteada gerenciada pela plataforma. Estender sua rede para uma nova região é tão simples quanto implantar um novo hub vWAN e conectá-lo; o roteamento global é atualizado automaticamente.

Falha Comum: A Mentalidade NVA de "Lift and Shift" no vWAN

Um erro frequente é tentar gerenciar um NVA dentro de um hub vWAN como se estivesse em uma VNet padrão. Você não pode, por exemplo, atribuir várias interfaces de rede ao NVA ou configurar HA manualmente. A plataforma lida com isso. Sua interação não é com a VM, mas com a sessão BGP que ela estabelece com o roteador do hub e as políticas de Routing Intent. Seu objetivo é influenciar as decisões de roteamento do hub vWAN anunciando rotas específicas do NVA, não conectar manualmente a rede com UDRs. Tratar o NVA como apenas um motor de políticas que recebe tráfego via política declarativa é o modelo mental correto.

Quando NÃO Usar Virtual WAN (Edição 2026)

Apesar de suas vantagens, o vWAN não é uma solução universal. Existem cenários específicos onde um hub-spoke clássico ou até mesmo uma topologia mais simples permanece superior.

• Implantações Pequenas e de Região Única: Se toda a sua pegada de nuvem consistir em menos de 10-15 VNets em uma única região com tráfego modesto, o vWAN é um exagero. O custo e a complexidade de uma VNet de hub simples com Azure Firewall Basic/Standard ou um pequeno par de NVAs FortiGate/Palo Alto serão significativamente menores.
• Roteamento Hyper-Customizado: O motor de roteamento do vWAN é poderoso, mas opinativo. Se sua arquitetura depende de comportamentos de roteamento complexos e não padronizados, como Policy-Based Routing (PBR) baseado em IP de origem ou métricas de camada de aplicação que não podem ser expressas através de BGP ou vWAN Routing Intent, você precisará do controle total de um NVA em uma VNet de hub clássica (potencialmente com Azure Route Server para facilitar a propagação BGP).
• Topologias NVA Não Suportadas: Se sua arquitetura de segurança exige um recurso NVA muito específico e não suportado – por exemplo, um protocolo de clustering proprietário de um fornecedor que requer adjacência de camada 2 ou virtualização multi-contexto que não se alinha com o modelo "NVA-as-an-appliance" no vWAN – você será forçado a uma arquitetura de hub DIY.

Conclusão: A Escolha Estratégica para Escala Empresarial

Até 2026, para qualquer organização que opere em escala significativa em várias regiões do Azure, a escolha é clara. A agilidade operacional, o roteamento global automatizado e a escalabilidade previsível do Azure Virtual WAN o tornam a base superior. Embora o modelo clássico de hub-and-spoke ofereça controle máximo, esse controle vem com o alto preço da complexidade e fragilidade operacional. A capacidade de inserir NGFW NVAs best-in-class no hub do vWAN mitiga a principal desvantagem histórica, combinando a escala nativa da plataforma com segurança especializada. O debate não é mais sobre qual oferece mais recursos, mas qual fornece a plataforma mais inteligente e escalável para uma rede empresarial global.

Para arquitetar sua rede Azure de próxima geração e avaliar o TCO preciso para seu ambiente, explore nossos serviços de consultoria especializada em techleague.io. Você também pode estar interessado em nossos deep dives sobre Azure Route Server para Integração Avançada de NVA ou Protegendo o ExpressRoute Private Peering de Ponta a Ponta.