Nem toda conectividade híbrida precisa de ExpressRoute. Nem toda produção crítica deveria depender só de VPN. O ponto não é escolher o serviço “mais forte”, e sim o desenho certo para o nível de criticidade do ambiente. A orientação oficial da Microsoft trata ExpressRoute e VPN como opções arquiteturais a serem aplicadas conforme necessidade de previsibilidade, resiliência, desempenho e custo.
O erro mais comum nessa discussão
Muita comparação entre ExpressRoute e VPN S2S começa do jeito errado: “um é privado, o outro usa internet”. Isso é verdade, mas é superficial demais para um ambiente enterprise.
A pergunta útil não é apenas por onde o tráfego passa. A pergunta útil é esta: qual modelo de conectividade entrega o nível de disponibilidade, previsibilidade e custo que o negócio realmente precisa? Em muitos cenários, VPN S2S é suficiente. Em outros, ExpressRoute passa a ser justificável. E, em uma parte importante dos ambientes mais maduros, a melhor resposta é a coexistência entre os dois. A Microsoft documenta explicitamente esse cenário como suportado e vantajoso.
O que o ExpressRoute entrega na prática
O ExpressRoute cria conectividade privada entre o ambiente local e a rede da Microsoft. Segundo a documentação oficial, essas conexões não passam pela internet pública e oferecem mais confiabilidade, velocidades mais altas e latências menores e mais consistentes do que conexões típicas baseadas em internet.
Na prática, o valor do ExpressRoute não está apenas no fato de ser privado. O ganho real aparece quando a conectividade híbrida deixa de ser periférica e passa a ser parte da plataforma. Nesses cenários, previsibilidade de rede pesa mais do que custo inicial.
Outro ponto importante é que o gateway de ExpressRoute suporta FastPath, recurso que permite que o tráfego vindo do ambiente on-premises ignore o virtual network gateway no caminho de dados, melhorando o desempenho em cenários compatíveis.
Mas existe uma nuance que melhora muito a qualidade da decisão arquitetural: ExpressRoute sozinho não garante resiliência fim a fim. A própria Microsoft recomenda desenhar a conectividade completa com foco em resiliência, incluindo gateways com redundância de zona quando possível e arquitetura local sem pontos únicos de falha.
ExpressRoute tende a fazer mais sentido quando a conectividade híbrida vira parte estrutural da plataforma, e não apenas um caminho de acesso ao Azure.
O que a VPN S2S entrega na prática
A VPN Site-to-Site no Azure usa IPsec/IKE para transportar tráfego criptografado entre o ambiente on-premises e a rede virtual do Azure pela internet pública. A documentação oficial também destaca que é possível criar múltiplas conexões no mesmo gateway e que todos os túneis compartilham a banda disponível daquele gateway.
Esse detalhe é importante porque muda a conversa. A VPN S2S não deve ser tratada como uma solução “menor” por definição. Em muitos cenários, ela é a escolha correta quando o objetivo é segurança, rapidez de implantação e menor custo estrutural, sem a necessidade de justificar um circuito privado dedicado. O próprio Cloud Adoption Framework posiciona a VPN como alternativa apropriada quando ExpressRoute não está disponível, não é custo-efetivo ou não é tecnicamente necessário.
Em outras palavras: VPN S2S não é apenas contingência. Em muitos ambientes, ela é produção.
VPN S2S pode ser a escolha certa quando o objetivo é conectar com segurança, rapidez e custo mais controlado.
HA: onde a decisão enterprise realmente acontece
Se a conectividade híbrida é importante para o negócio, a análise de alta disponibilidade precisa ir além do nome do serviço.
No Azure VPN Gateway, cada gateway é composto por duas instâncias em configuração active-standby por padrão. Em caso de manutenção planejada ou indisponibilidade da instância ativa, a instância de standby assume automaticamente. A Microsoft informa que, em manutenção planejada, a conectividade normalmente é restaurada em cerca de 10 a 15 segundos. O serviço também suporta cenários active-active e pode operar com redundância de zona em SKUs compatíveis.
Na documentação de confiabilidade, a Microsoft informa que gateways compatíveis podem ser automaticamente zone redundant. No caso do ExpressRoute gateway, as VMs do gateway são distribuídas em pelo menos três Availability Zones. No VPN Gateway, a distribuição ocorre entre múltiplas zonas. A recomendação explícita para workloads de produção é preferir redundância de zona quando possível.
No caso do ExpressRoute, o ponto central é outro: o gateway Azure é apenas uma parte da história. A confiabilidade total depende do desenho ponta a ponta, incluindo circuito, roteamento, peering location e arquitetura local. Por isso, em ambientes críticos, “ter ExpressRoute” não basta. O que importa é como a conectividade foi desenhada para falhar sem derrubar a operação.
Latência: compare previsibilidade, não só milissegundos
Quando esse tema aparece em discussões técnicas, muita gente tenta resumir tudo a um teste de ping. Para ambiente enterprise, isso é uma análise fraca.
O argumento mais sólido a favor do ExpressRoute não é prometer um RTT milagroso. O argumento mais sólido é que ele tende a oferecer caminho mais previsível, menor variabilidade e uma base mais estável para workloads sensíveis à oscilação de rede. A Microsoft descreve ExpressRoute como uma opção com maior confiabilidade, maiores velocidades e latências menores e mais consistentes do que conexões típicas sobre internet.
Na VPN S2S, a latência pode ser perfeitamente adequada para muitos cenários, mas a variabilidade tende a ser maior porque o transporte depende da internet pública e da capacidade efetiva do gateway escolhido. Isso não torna a VPN inadequada. Apenas define melhor o tipo de workload para o qual ela é mais confortável.
Custos: a análise certa é TCO, não só a linha do gateway
Outro erro comum é comparar apenas o valor mais visível no portal.
No VPN Gateway, a cobrança depende do gateway provisionado, e os SKUs variam em throughput, quantidade de túneis e opções com redundância de zona. A página oficial mostra, por exemplo, SKUs como VpnGw1 com benchmark de 650 Mbps, VpnGw2 com 1 Gbps, VpnGw3 com 1,25 Gbps e SKUs AZ com capacidades maiores, como VpnGw3AZ com 2,5 Gbps e VpnGw4AZ com 5 Gbps.
No ExpressRoute, a lógica de custo é mais estrutural. A página oficial mostra planos com metered data e unlimited data, cobrança de porta, possibilidade de taxas por saída de dados em alguns modelos e a necessidade de gateway virtual para acessar redes virtuais com private peering. Em outras palavras, a conta do ExpressRoute não deve ser avaliada só como “um recurso Azure”, mas como parte de uma solução de conectividade enterprise mais ampla.
Por isso, a comparação madura não é “VPN custa menos, logo é melhor”. A comparação madura é esta: quanto custa operar uma conectividade mais barata quando ela não entrega o nível de previsibilidade ou resiliência que o workload exige?
O custo de entrada é só uma parte da decisão. Em conectividade híbrida, previsibilidade e impacto operacional pesam tanto quanto preço.
O padrão mais maduro: ExpressRoute e VPN coexistindo
Em muitos cenários, a melhor resposta não é ExpressRoute ou VPN. É ExpressRoute com VPN S2S coexistente.
A Microsoft documenta explicitamente a coexistência entre as duas conexões e destaca dois benefícios principais: usar a VPN como caminho de failover seguro para o ExpressRoute e conectar sites que não estão ligados ao circuito privado. Isso é importante porque mostra que coexistência não é gambiarra. É padrão suportado.
Aqui existe uma nuance técnica que vale ouro para o leitor mais apurado: esse failover via VPN se aplica apenas às redes ligadas ao Azure private peering. A própria documentação afirma que não existe solução de failover baseada em VPN para serviços acessíveis via Microsoft peering. Ela também orienta configurar a rede local para preferir ExpressRoute, normalmente com maior local preference para as rotas recebidas por esse caminho. Além disso, quando os dois caminhos apresentam a mesma rota, o Azure ainda usa a regra de longest prefix match para selecionar o destino.
Em muitos ambientes enterprise, o desenho mais maduro é ExpressRoute como caminho principal e VPN S2S como backup ou extensão.
Quando usar cada um
Use VPN S2S quando o objetivo for conectar com segurança, rapidez e menor custo de entrada, e quando o workload tolerar maior variabilidade de rede. Isso costuma funcionar muito bem para filiais menores, contingência, integrações pontuais e cenários em que ExpressRoute não é técnica ou economicamente necessário.
Use ExpressRoute quando a conectividade híbrida for parte central da plataforma, com maior volume de tráfego, maior exigência de previsibilidade e necessidade de uma base privada mais robusta.
Use ExpressRoute + VPN S2S quando a meta for maturidade arquitetural: circuito privado para o core, VPN como failover ou extensão para borda. Esse costuma ser o desenho mais pragmático para equilibrar robustez, evolução gradual e custo.
Conclusão
A melhor pergunta não é “qual tecnologia é melhor?”. A melhor pergunta é:
qual desenho entrega o nível de disponibilidade, previsibilidade e custo que o meu ambiente realmente precisa?
Se a resposta for simplicidade com segurança e implantação rápida, a VPN S2S pode ser suficiente. Se a resposta for conectividade híbrida crítica e previsível, ExpressRoute tende a ser o caminho natural. E, se a resposta for arquitetura enterprise madura de verdade, a coexistência entre os dois normalmente é o desenho mais inteligente.
Referências oficiais
- Microsoft Learn — Configure ExpressRoute and S2S VPN coexisting connections
- Microsoft Learn — About Azure VPN Gateway
- Microsoft Learn — Confiabilidade nos Gateways de Rede Virtual do Azure
- Microsoft Learn — Sobre os gateways de rede virtual do ExpressRoute
- Microsoft Learn — Perguntas frequentes do ExpressRoute
- Microsoft Learn — Projetar e arquitetar o Azure ExpressRoute para resiliência
- Microsoft Learn — Conectividade com outros provedores de nuvem
- Microsoft Learn — Conectar uma rede local ao Azure usando ExpressRoute com failover por VPN
- Azure Pricing — Preços do ExpressRoute
- Azure Pricing — Preços do VPN Gateway
Quer aprofundar a discussão?
Se você está desenhando conectividade e segurança de rede no Azure, estes artigos complementam bem este tema:
