Escolher entre VPN ou ExpressRoute para migrar para o Azure é uma daquelas decisões que parecem apenas técnicas, mas acabam definindo prazo de projeto, custo recorrente e o quanto a operação fica exposta a instabilidade. Quem lidera infraestrutura ou segurança em empresas de médio e grande porte costuma chegar a esse dilema no meio do cronograma, com cargas críticas já mapeadas e a pressão de colocar ambientes em produção sem comprometer conformidade nem desempenho.
O problema é que a comparação raramente se resolve por preço mensal. Volume de dados a transferir, perfil de tráfego contínuo, exigências regulatórias do setor e o tempo que cada opção leva para entrar em operação pesam tanto quanto a mensalidade — e é aí que muitos projetos travam ou estouram orçamento.
Este texto percorre os três modelos de conexão disponíveis no Azure, compara custo, largura de banda, latência e SLA, e apresenta critérios práticos de decisão por faixa de volume e cenário de conformidade. A ideia é dar base para uma escolha defensável diante do comitê, do time de segurança e da auditoria — e não apenas a opção mais barata na planilha.
VPN ou ExpressRoute: o que muda na prática ao migrar para o Azure
A decisão entre VPN e ExpressRoute define não apenas a velocidade da migração inicial, mas também a arquitetura de conectividade que permanecerá ativa depois que as cargas estiverem rodando no Azure. Um equívoco comum é tratar as duas opções como equivalentes separadas apenas pelo preço: na prática, elas operam em camadas distintas do modelo de rede, com implicações diferentes para latência, segurança, SLA e custo operacional. Para um decisor de TI que planeja mover ambientes críticos — inclusive sistemas financeiros e transações via Pix —, a escolha errada pode se traduzir em janelas de migração alongadas, custos imprevistos ou dependência de um caminho de conectividade sem redundância adequada.
O dimensionamento correto começa por entender que a VPN Site-to-Site trafega sobre a internet pública com criptografia IPsec, enquanto o ExpressRoute usa um circuito dedicado fornecido por um parceiro de conectividade, sem passar pela internet. Essa diferença estrutural afeta tudo o que vem depois: previsibilidade de latência, requisitos de conformidade, custo mensal e o tempo necessário para transferir dezenas de terabytes. Antes de escolher, é preciso mapear o volume de dados a migrar, o perfil de tráfego contínuo e o nível de exigência regulatória do setor.
Como funciona cada opção de conectividade
Os três modelos de conexão disponíveis no Azure atendem a momentos distintos da jornada de migração. Cada um tem um papel técnico específico, e confundi-los na fase de planejamento gera retrabalho em projeto e custo adicional em infraestrutura.
VPN Site-to-Site sobre a internet
A VPN Site-to-Site (S2S) estabelece um túnel IPsec entre o dispositivo de borda da empresa — normalmente um firewall ou roteador com suporte a IPsec — e o gateway de rede virtual do Azure. O tráfego viaja pela internet pública, protegido por criptografia. A configuração é relativamente rápida e não exige contrato com operadora de telecom, o que a torna a porta de entrada natural para projetos de migração que precisam começar em dias, não em semanas.
O desempenho, porém, está condicionado à qualidade do link de internet contratado e ao modelo do gateway virtual escolhido. O SKU do gateway define a capacidade agregada de throughput: um gateway de geração VpnGw1, por exemplo, suporta até 650 Mbps de throughput agregado, conforme documentação da Microsoft. Empresas que subdimensionam o SKU no início do projeto descobrem, no meio da migração, que o túnel é o gargalo — e não o link de internet.
A latência de uma VPN S2S em território brasileiro varia conforme a rota da internet entre a empresa e a região do Azure (geralmente Brazil South, em São Paulo). A internet não oferece SLA de latência ou jitter. Para cargas que toleram variação, isso é aceitável; para sistemas transacionais de missão crítica, a imprevisibilidade pode ser um problema.
ExpressRoute via circuito dedicado
O ExpressRoute cria uma conexão privada entre a infraestrutura local e o Azure por meio de um provedor de conectividade autorizado. O tráfego não passa pela internet pública: ele flui por um circuito dedicado, com latência menor e mais estável, além de largura de banda simétrica. Os modelos de conectividade incluem ponto a ponto Ethernet, roteamento em nuvem de MPLS ou conexão direta em pontos de presença do provedor.
A contratação envolve duas partes: o circuito do provedor de telecom e o gateway ExpressRoute no Azure. O circuito é tarifado pelo provedor, geralmente com planos de dados ilimitados ou medidos; o gateway do Azure tem custo por hora, variando conforme o SKU (Standard, High Performance ou Ultra Performance). A Microsoft garante SLA de disponibilidade de 99,95% para o gateway ExpressRoute quando configurado com redundância adequada — um contraste relevante com a VPN, que não possui SLA de disponibilidade de ponta a ponta por depender da internet.
O tempo de provisionamento é o principal custo de oportunidade: um circuito ExpressRoute pode levar de dias a semanas para ser ativado, dependendo do provedor. Em projetos com cronograma agressivo, a prática recomendada é iniciar a contratação do circuito em paralelo com a fase de inventário de cargas, para que ele esteja pronto quando a migração de grandes volumes começar.
VPN Point-to-Site e quando ela entra na migração
A VPN Point-to-Site (P2S) conecta um único dispositivo — o notebook de um engenheiro, o servidor de um administrador ou uma máquina de testes — diretamente à rede virtual do Azure por um túnel individual. Ela não é o caminho de migração de produção: sua função no contexto de migração é administrativa e de validação.
Durante a fase de preparação, times de infraestrutura usam P2S para acessar redes virtuais isoladas, validar regras de firewall, testar conectividade com serviços de plataforma e executar etapas de configuração antes de liberar o tráfego de produção. Depois da migração, a P2S permanece útil para acesso administrativo seguro a ambientes de contingência, especialmente em arquiteturas que exigem restrição de origem de conexão. O protocolo suporta OpenVPN, IKEv2 e SSTP, com limites de throughput por túnel bem inferiores aos da S2S, o que reforça seu papel de acesso pontual e não de transferência de massa de dados.
Comparativo direto: custo, largura de banda, latência e SLA
A comparação honesta entre VPN e ExpressRoute exige separar o custo inicial do custo recorrente, e a latência medida da latência contratada. Cada dimensão favorece uma opção em cenários diferentes.
Custo total de propriedade em 12, 24 e 36 meses
O custo de uma VPN S2S é dominado pelo gateway de rede virtual do Azure e pelo link de internet já existente na empresa. Se a empresa já possui firewall com capacidade IPsec e link de internet com folga, o investimento adicional tende a ser baixo.
O ExpressRoute tem um perfil de custo diferente. O circuito do provedor de telecom no Brasil varia conforme a largura de banda contratada (50 Mbps, 100 Mbps, 1 Gbps ou mais) e a cobertura do provedor. A esse valor soma-se o gateway ExpressRoute no Azure, cujo custo depende do SKU escolhido.
A decisão, portanto, não deve ser tomada apenas pelo preço mensal: é preciso calcular o custo total do projeto de migração, incluindo o tempo de transferência e o risco de interrupção. Em alguns casos, alugar um circuito ExpressRoute por 90 dias para acelerar a migração inicial e depois desativá-lo é mais econômico do que manter uma VPN lenta por 12 meses.
Largura de banda, latência e previsibilidade de jitter
A largura de banda da VPN é limitada pelo SKU do gateway e pelo link de internet. Mesmo com um link de 1 Gbps, um gateway VpnGw1 limita o túnel a 650 Mbps. Além disso, a VPN sobre internet está sujeita a congestionamento de rota, perda de pacotes e variação de latência (jitter), especialmente em horários de pico. Para transferências longas e contínuas, a perda de pacotes força retransmissões TCP que derrubam o throughput efetivo bem abaixo do nominal.
O ExpressRoute oferece largura de banda simétrica e contratada, dependendo da localização da empresa e do provedor. O jitter é drasticamente menor porque o tráfego não disputa rota com o restante da internet. Para cargas transacionais — como processamento de pagamentos instantâneos ou replicação síncrona de banco de dados —, essa previsibilidade é um requisito de arquitetura, não um luxo.
SLA, redundância e impacto em janelas de migração
O SLA é um dos pontos mais objetivos da comparação. A Microsoft oferece 99,95% de disponibilidade para o gateway ExpressRoute quando dois circuitos ativos ou um circuito com duas conexões redundantes são configurados. Para VPN S2S, não há SLA de ponta a ponta: a Microsoft garante a disponibilidade do gateway, mas a internet entre a empresa e o Azure não é coberta por nenhum acordo de nível de serviço.
O impacto prático aparece nas janelas de migração. Uma transferência de 10 TB a 200 Mbps efetivos leva aproximadamente 111 horas, ou cerca de 4,6 dias. Se a VPN sofre degradação e o throughput cai para 60 Mbps, o mesmo volume leva 15 dias. O ExpressRoute, com largura contratada e estável, permite planejar a janela com precisão e reduzir o risco de estourar o cronograma. Em projetos com data-limite regulatória ou janela de manutenção definida, essa diferença pode custar mais do que a mensalidade do circuito.
Qual escolher conforme o volume de dados a migrar
O volume de dados é o critério mais prático para a primeira triagem. Ele define o tempo de transferência, o custo total do projeto e a viabilidade de cada opção dentro do cronograma.
Migrações pequenas e médias (até 10 TB)
Para volumes de até 10 TB, a VPN Site-to-Site costuma ser suficiente, desde que o gateway seja dimensionado corretamente e o link de internet tenha folga. Uma carga de 5 TB a 150 Mbps efetivos transfere em cerca de 74 horas — factível em um fim de semana estendido. Nesse cenário, o custo de provisionar um ExpressRoute dificilmente se justifica, a menos que haja requisito de conformidade ou necessidade de continuidade de tráfego em produção.
Vale lembrar que migrações pequenas não significam apenas volume total baixo: significam também baixa taxa de mudança. Se a empresa tem 8 TB de dados estáticos e um delta diário pequeno, a VPN resolve a transferência inicial e o tráfego contínuo. O erro comum é subestimar o delta: bancos de dados transacionais com alta taxa de escrita podem gerar centenas de gigabytes por dia, transformando uma migração "pequena" em um fluxo contínuo que sobrecarrega a VPN.
Migrações grandes e contínuas (acima de 10 TB)
Acima de 10 TB, o tempo de transferência por VPN começa a se tornar proibitivo. A 100 Mbps efetivos, 20 TB levam cerca de 18 dias de transferência ininterrupta — sem margem para falhas, retransmissões ou janelas de manutenção. O ExpressRoute, com largura contratada de 500 Mbps ou 1 Gbps, reduz esse tempo para 3,5 a 7 dias, tornando o projeto viável dentro de uma janela de migração realista.
Para migrações contínuas — cenários de sincronização incremental, replicação de banco de dados ou fábrica de dados híbrida —, o ExpressRoute também se justifica pela estabilidade. A replicação contínua exige latência baixa e consistente; a VPN sobre internet pode introduzir atrasos que quebram a sincronização ou geram filas de replicação. Nesses casos, o custo do circuito é diluído pela redução de retrabalho e pelo menor risco de inconsistência de dados.
Cargas com requisitos de conformidade e dados sensíveis
Empresas do setor financeiro, de saúde ou que processam dados pessoais sensíveis frequentemente têm obrigações contratuais ou regulatórias que exigem tráfego fora da internet pública. Normas internas de segurança, exigências de adquirentes, padrões como PCI DSS e políticas de gestão de risco podem determinar que dados de produção jamais transitem pela internet, mesmo criptografados.
Nesses cenários, o ExpressRoute deixa de ser uma escolha de desempenho e passa a ser um requisito de conformidade. A VPN IPsec oferece criptografia forte, mas o tráfego ainda trafega por infraestrutura compartilhada. Para dados de transações via Pix, informações de clientes ou propriedade intelectual, a segregação física do circuito dedicado é frequentemente o padrão mínimo aceito por auditoria. A recomendação, nesses casos, é envolver a área de compliance na decisão de conectividade desde o início do projeto.
Usando VPN e ExpressRoute juntos: coexistência e failover
A arquitetura mais robusta não precisa escolher uma opção apenas: VPN e ExpressRoute podem coexistir no mesmo gateway, com papéis distintos de caminho principal e contingência. Essa configuração é suportada nativamente no Azure e resolve o principal ponto fraco de cada tecnologia isoladamente.
ExpressRoute como caminho principal e VPN como backup
No modelo de coexistência, o ExpressRoute funciona como caminho primário de tráfego de produção, aproveitando baixa latência e largura contratada. A VPN Site-to-Site permanece configurada como rota de contingência, ativada automaticamente em caso de falha do circuito dedicado.
Essa arquitetura é especialmente relevante para ambientes que não podem ficar sem conectividade com o Azure — caso de sistemas de pagamento, ERPs em nuvem ou ambientes híbridos com replicação contínua. A redundância não elimina risco, mas reduz drasticamente o tempo de indisponibilidade em cenários de falha de circuito, que podem levar horas para serem corrigidos pelo provedor de telecom.
Roteamento de trânsito entre ExpressRoute e VPN do Azure
O comportamento de roteamento na coexistência segue o protocolo BGP. O ExpressRoute e a VPN anunciam as mesmas redes locais ao Azure, e a preferência de rota é definida pelo comprimento do caminho AS (AS Path). O ExpressRoute, por padrão, recebe preferência sobre a VPN. Quando o circuito cai, as rotas anunciadas via ExpressRoute são retiradas, e o tráfego passa a fluir pela VPN sem intervenção manual — desde que o BGP esteja configurado corretamente em ambos os lados.
Um detalhe operacional importante: o gateway de rede virtual do Azure precisa estar no SKU correto para suportar coexistência. Os SKUs Basic não suportam ExpressRoute; os SKUs VpnGw1 a VpnGw5 suportam coexistência com ExpressRoute, mas a capacidade de throughput da VPN é compartilhada. Em arquiteturas críticas, o dimensionamento do gateway deve considerar o pior cenário: o tráfego total que passará pela VPN durante uma falha do ExpressRoute.
Quando a coexistência não compensa o custo
A coexistência adiciona custo e complexidade. Para empresas com orçamento limitado, manter um circuito ExpressRoute e um gateway com capacidade de failover pode duplicar o investimento em conectividade sem retorno proporcional. Se a carga tolera algumas horas de indisponibilidade — por exemplo, sistemas internos de backoffice —, o ExpressRoute sozinho, com um processo de contingência manual documentado, pode ser suficiente.
A regra prática é avaliar o custo da indisponibilidade. Se uma hora sem conexão com o Azure custa mais do que a mensalidade da VPN de backup, a coexistência se paga. Se o impacto é baixo e o time consegue operar em modo degradado por algumas horas, o investimento em redundância pode ser adiado. A decisão deve ser documentada em análise de impacto de negócio, não tomada por intuição.
Erros comuns ao dimensionar a conectividade antes da migração
O primeiro erro recorrente é calcular a largura de banda necessária pela média de tráfego, ignorando os picos. Migrações geram tráfego em rajadas: a transferência inicial de dados, a sincronização de bancos e a replicação de snapshots acontecem em momentos concentrados. Dimensionar o gateway pela média resulta em filas, timeouts e cronogramas estourados.
O segundo erro é subdimensionar o SKU do gateway de rede virtual. Muitos projetos começam com o SKU mais barato para "depois escalar", sem considerar que a troca de SKU exige interrupção do gateway e reconfiguração de túneis. Em migração de produção, essa interrupção pode custar horas de janela. O correto é dimensionar o SKU pelo pico esperado da migração, não pelo tráfego médio de produção.
O terceiro erro é ignorar a sub-rede do gateway (GatewaySubnet). Ela precisa ter tamanho mínimo de /27, e em arquiteturas com coexistência de VPN e ExpressRoute, recomenda-se /26 ou maior para acomodar expansões futuras. Sub-redes pequenas demais impedem a adição de conexões e forçam recriação do gateway — retrabalho caro em pleno projeto de migração.
Outros erros comuns incluem:
- Não validar a capacidade IPsec do firewall local antes de provisionar a VPN
- Contratar o circuito ExpressRoute sem confirmar a cobertura do provedor no endereço da empresa
- Ignorar o custo de saída de dados do Azure em arquiteturas híbridas contínuas
- Não testar o failover da coexistência antes de colocá-lo em produção
- Deixar a equipe de segurança fora da decisão de conectividade em ambientes regulados
- Dimensionar o link com base na largura nominal, sem considerar overhead de criptografia e perda de pacotes
Checklist de decisão: roteiro para escolher sua opção
O roteiro abaixo organiza a decisão em etapas sequenciais. Cada etapa elimina opções e reduz o espaço de escolha com base em critérios objetivos, evitando decisões por preferência pessoal ou por hábito técnico.
- Inventarie o volume total de dados a migrar, incluindo bancos, arquivos e snapshots
- Estime a taxa de mudança diária (delta) das cargas que permanecerão híbridas
- Defina a janela de migração aceitável em dias ou horas
- Calcule o throughput efetivo necessário para cumprir a janela
- Verifique requisitos de conformidade que vedem tráfego pela internet pública
- Compare o custo de VPN e ExpressRoute em 12, 24 e 36 meses
- Consulte provedores de ExpressRoute para confirmar cobertura e prazo de ativação
- Decida se a arquitetura exige coexistência com failover automático
- Dimensionar o SKU do gateway e a sub-rede GatewaySubnet pelo pico, não pela média
- Documente a decisão com análise de custo, risco e conformidade para auditoria
Empresas que seguem esse roteiro chegam à decisão com dados concretos sobre volume, prazo e custo. O resultado costuma ser uma combinação equilibrada: VPN para começar rápido e custar pouco nas fases iniciais, ExpressRoute para os volumes grandes e as cargas sensíveis, e coexistência nos ambientes que não toleram indisponibilidade.
Para ambientes híbridos que permanecerão ativos após a migração, a escolha de conectividade afeta também a estratégia de proteção de dados. A definição de onde ficam armazenados os backups e como eles trafegam entre local e nuvem está diretamente ligada ao desenho de rede adotado — vale consultar ambientes híbridos para alinhar as duas decisões. Da mesma forma, cargas sensíveis migradas por ExpressRoute exigem políticas de dados sensíveis coerentes com o nível de segregação da rede.
Perguntas frequentes sobre VPN e ExpressRoute na migração para Azure
VPN Site-to-Site é segura para migrar dados de produção?
A VPN Site-to-Site usa criptografia IPsec com algoritmos como AES-256, considerados adequados para tráfego de produção na maioria dos cenários. A limitação não está na criptografia, mas na rota: o tráfego passa pela internet pública, sujeito a congestionamento e sem SLA. Para dados com exigência regulatória de segregação de rede, a VPN pode não atender aos requisitos de auditoria, mesmo sendo criptografada.
Quanto tempo leva para provisionar um circuito ExpressRoute no Brasil?
O prazo varia conforme o provedor e a localização da empresa. A contratação deve ser iniciada no começo do projeto, em paralelo com o inventário de cargas.
Posso usar a mesma conexão ExpressRoute para vários ambientes do Azure?
Sim. O ExpressRoute se conecta ao Microsoft Enterprise Edge (MSEE) e pode ser roteado para múltiplas redes virtuais na mesma região ou em regiões diferentes, dentro dos limites de emparelhamento do circuito. O emparelhamento privado permite acessar redes virtuais; o emparelhamento da Microsoft permite acessar serviços de PaaS e Microsoft 365, com restrições específicas por região e SKU de gateway.
O que acontece com a migração se a VPN cair no meio da transferência?
A transferência é interrompida e precisa ser retomada. Ferramentas como AzCopy e Azure Migrate possuem mecanismos de retomada e verificação de integridade, mas cada interrupção adiciona tempo ao projeto. Em transferências longas por VPN, interrupções são esperadas e devem ser consideradas no cálculo da janela — mais um argumento para usar ExpressRoute em volumes acima de 10 TB.
ExpressRoute garante que os dados não serão interceptados?
Nenhuma tecnologia pode oferecer garantia absoluta contra interceptação ou vazamento. O ExpressRoute reduz a superfície de exposição ao manter o tráfego fora da internet pública, mas a segurança depende também de controles complementares: criptografia de aplicação, segmentação de rede, monitoramento de tráfego e políticas de acesso. Para dados sensíveis, a recomendação é aplicar criptografia ponta a ponta mesmo sobre o circuito dedicado, como camada adicional de defesa.
Vale a pena manter o ExpressRoute depois que a migração termina?
Depende do perfil de tráfego contínuo. Se a empresa mantém cargas híbridas com replicação, sincronização ou acesso constante ao Azure, o ExpressRoute continua se pagando pela estabilidade e pelo SLA. Se a migração foi pontual e as cargas passaram a rodar integralmente na nuvem, o circuito pode ser desativado, mantendo-se a VPN apenas para acesso administrativo e contingência. A decisão deve ser revisada a cada ciclo de planejamento de capacidade.
Para ambientes que dependem de disponibilidade contínua, a conectividade é apenas uma camada da estratégia de continuidade. A definição de recuperação de desastres e a validação de testes de restore precisam estar alinhadas com o desenho de rede escolhido, garantindo que o plano de contingência funcione de ponta a ponta — e não apenas no papel.
