Quando usar ExpressRoute na migração para Azure?

A migração para Azure com ExpressRoute costuma entrar na pauta quando a empresa já decidiu ir para a nuvem, mas o time de TI trava numa pergunta prática: a VPN Site-to-Site que hoje conecta o datacenter à Microsoft dá conta do ambiente de produção? Para decisores em empresas de médio e grande porte — especialmente no setor financeiro, que lida com dados regulados e transações sensíveis — a resposta envolve latência, previsibilidade, custo recorrente e responsabilidade contratual, não apenas largura de banda.

Este conteúdo foi escrito para quem precisa decidir se, quando e como usar ExpressRoute, e não apenas entender o que ele é. O texto compara o circuito dedicado com a VPN Site-to-Site e com a VPN sobre ExpressRoute, mostra em que situações a VPN continua sendo a escolha economicamente racional, aponta sinais objetivos de que o tráfego já exige caminho dedicado e reúne os erros de dimensionamento e redundância que costumam aparecer tarde demais. Se a dúvida é mais ampla, vale começar por como funciona a migração para a nuvem Azure.

Ao final, você terá critérios para discutir topologia, SKU e custo total com o provedor de conectividade — e para justificar a decisão internamente sem prometer o que nenhum desenho de rede entrega sozinho.

O que o ExpressRoute resolve — e o que ele não resolve

O ExpressRoute é um serviço da Microsoft que cria uma conexão privada entre a infraestrutura on-premises e o Azure, sem passar pela internet pública. O tráfego trafega por um circuito dedicado fornecido por um parceiro de conectividade — como Equinix, Megatelecom, Lumen ou outros provedores homologados — e chega diretamente aos datacenters da Microsoft. Isso resolve três problemas centrais numa migração: latência imprevisível, exposição a ameaças da internet e falta de garantias de largura de banda para cargas críticas.

O que o ExpressRoute não resolve é igualmente importante. Ele não é um acelerador mágico de aplicações mal arquitetadas, não elimina a necessidade de dimensionar o gateway de rede virtual e não substitui controles de segurança como segmentação, firewalls e gestão de identidade. Se o gargalo estiver no banco de dados legado ou numa aplicação com chamadas síncronas excessivas, o circuito dedicado apenas transporta o problema mais rápido. Além disso, o ExpressRoute protege o caminho de rede, mas não criptografa os dados por padrão — para requisitos de confidencialidade ponta a ponta, o tráfego deve ser combinado com IPsec sobre o circuito ou com criptografia na camada de aplicação.

Para empresas que processam transações via Pix ou mantêm dados regulados, a diferença prática é relevante: o tráfego deixa de disputar rota com o tráfego público e passa a ter um caminho previsível e monitorável. Ainda assim, a Microsoft publica SLA de disponibilidade do circuito — que varia conforme a SKU e a topologia — mas nenhum SLA cobre falhas no roteador do cliente, no link do provedor fora do escopo Microsoft ou em configurações de BGP mal planejadas. A responsabilidade pelo desenho da rede continua sendo do time de TI.

ExpressRoute x VPN Site-to-Site x VPN sobre ExpressRoute: qual escolher na migração

A decisão entre ExpressRoute e VPN Site-to-Site não é binária — e muitas migrações bem-sucedidas usam as duas em fases diferentes. A VPN Site-to-Site é um túnel IPsec sobre a internet pública, provisionado em minutos, com custo de entrada baixo e limite de throughput atrelado ao gateway de VPN do Azure (que varia de 100 Mbps a 1,25 Gbps no SKU ativo-ativo, dependendo da geração). O ExpressRoute exige contratação de circuito com provedor, tempo de provisionamento que pode levar dias ou semanas e custo fixo mensal que começa na casa de centenas de dólares, mas entrega largura de banda de 50 Mbps a 100 Gbps com latência consistente.

Há ainda um terceiro caminho: VPN sobre ExpressRoute. Nesse modelo, o túnel IPsec roda por dentro do circuito dedicado, combinando a privacidade do caminho com a criptografia da VPN. É a configuração recomendada quando a organização precisa cumprir requisitos de confidencialidade que o ExpressRoute nativo não atende, como tráfego de dados de cartão ou informações protegidas por regulamentação setorial. O custo é o overhead de processamento do IPsec, que reduz o throughput útil do circuito e exige appliances com capacidade criptográfica adequada.

• VPN Site-to-Site: provisionamento imediato, custo variável baixo, ideal para piloto.
• ExpressRoute nativo: caminho privado, latência estável, sem criptografia por padrão.
• VPN sobre ExpressRoute: privacidade + criptografia, com custo de throughput.

Quando a VPN Site-to-Site ainda é a resposta certa

Para cargas tolerantes a variação de latência — backups incrementais, sincronização de arquivos, ambientes de desenvolvimento e homologação — a VPN Site-to-Site continua sendo a opção economicamente racional. O custo de um gateway de VPN no Azure fica na faixa de dezenas a poucas centenas de dólares mensais, contra um circuito ExpressRoute que pode multiplicar esse valor por cinco ou dez vezes dependendo da largura de banda e da região. Se a migração envolve transferências esporádicas ou janelas flexíveis, o investimento em circuito dedicado raramente se paga.

Outro cenário é a fase inicial de migração, quando o time ainda está validando arquitetura, testando conectividade e movendo cargas de baixo risco. Nesse estágio, a VPN permite começar em horas e evita compromisso contratual de longo prazo com provedor de conectividade. A recomendação prática é usar a VPN como primeiro estágio e migrar para ExpressRoute quando o volume de dados, a exigência de SLA ou a criticidade da carga justificarem o salto de custo — uma estratégia que reduz o risco financeiro do projeto.

Quando o tráfego exige circuito dedicado

O ExpressRoute se torna obrigatório quando a organização precisa de garantias contratuais de disponibilidade, latência previsível e isolamento de rede. Sistemas de pagamento instantâneo, como plataformas que processam Pix, não toleram o comportamento errático da internet pública: um pico de jitter de 40 ms pode gerar timeouts em cascata e recusas de transação. Nesses ambientes, o circuito dedicado entrega latência de ida e volta tipicamente entre 5 ms e 15 ms dentro da mesma região metropolitana, com variação mínima.

Também entram nessa categoria cargas como SAP S/4HANA, bancos de dados com replicação síncrona, VDI (Virtual Desktop Infrastructure) e VoIP corporativo. A replicação síncrona de SQL Server Always On, por exemplo, degrada visivelmente quando a latência ultrapassa 10-15 ms — algo comum em túneis VPN sobre longas distâncias. Para essas aplicações, a migração para Azure precisa considerar o ExpressRoute como parte do desenho de rede, não como um extra opcional.

Sinais de que sua migração precisa de ExpressRoute

Existem indicadores objetivos que apontam para a necessidade de circuito dedicado antes mesmo de iniciar a migração. Ignorá-los leva a retrabalho, janelas de migração estouradas e incidentes em produção. Os três sinais mais comuns envolvem volume de dados, sensibilidade de latência e obrigações de compliance — e cada um merece análise separada.

Volume de dados e janelas de transferência

Quando o volume total de dados a migrar ultrapassa algumas dezenas de terabytes e a janela de transferência é limitada, a VPN Site-to-Site se torna o gargalo. Um túnel VPN com throughput real de 200 Mbps transfere cerca de 2 TB por dia em condições ideais — na prática, menos, por causa de overhead de IPsec, retransmissões e compartilhamento do link com o tráfego corporativo. Migrar 50 TB nesse cenário pode levar mais de um mês. O mesmo volume num circuito ExpressRoute de 1 Gbps cai para menos de uma semana.

O cálculo deve considerar também o tráfego incremental pós-migração. Se a aplicação continuará sincronizando dados entre on-premises e Azure diariamente — como em cenários híbridos com banco de dados distribuído — o ExpressRoute se justifica não pela migração inicial, mas pelo custo operacional contínuo. Ferramentas como Azure Migrate e Data Box ajudam na transferência inicial, mas não resolvem o problema do tráfego permanente de produção.

Latência, jitter e cargas sensíveis (SAP, bancos, VDI, VoIP)

A latência é o critério técnico mais decisivo. Aplicações que fazem muitas chamadas de rede por transação — como SAP GUI, protocolos de banco de dados e sistemas de autenticação centralizada — amplificam o impacto de cada milissegundo adicional. Uma consulta que faz 50 round-trips entre aplicação e banco transforma 10 ms extras de latência em 500 ms de atraso percebido pelo usuário. Em VPN sobre internet, a latência varia conforme a rota, o congestionamento e a distância geográfica; no ExpressRoute, ela é estável e previsível.

O jitter — variação da latência ao longo do tempo — é ainda mais perigoso para tráfego em tempo real. Chamadas VoIP, videoconferência e VDI degradam com jitter acima de 20-30 ms, causando áudio robótico, telas que congelam e desconexões. O ExpressRoute reduz o jitter a valores típicos de 1-5 ms dentro da mesma região, porque o caminho não compete com o tráfego público. Para ambientes financeiros que dependem de comunicação em tempo real com parceiros ou câmaras de compensação, essa estabilidade é requisito de negócio.

Compliance, dados regulados e tráfego que não pode sair pela internet pública

Normas como a LGPD não proíbem explicitamente o uso de VPN sobre internet, mas exigem medidas de segurança proporcionais ao risco. Para dados sensíveis — informações financeiras, dados de saúde, segredos industriais — auditores e reguladores tendem a questionar qualquer tráfego que trafegue pela internet pública, mesmo criptografado. O ExpressRoute elimina essa exposição ao manter o tráfego em uma infraestrutura privada do provedor de conectividade, com acordos de nível de serviço específicos.

Setores como o financeiro, que operam sob supervisão do Banco Central e precisam demonstrar controle sobre a infraestrutura de pagamentos, frequentemente incluem o ExpressRoute como requisito de arquitetura. A ISO 27001 e frameworks correlatos tratam a segregação de rede como controle de segurança — e o circuito dedicado é evidência objetiva desse controle. Para organizações que precisam comprovar conformidade em auditoria, o custo do ExpressRoute é uma fração do custo de uma não conformidade apontada.

Topologias de conexão: provedor de conectividade, ExpressRoute Direct e ExpressRoute Global Reach

Existem três formas principais de estabelecer um circuito ExpressRoute, e a escolha afeta custo, prazo e flexibilidade. A mais comum é a contratação via provedor de conectividade: a empresa contrata um parceiro homologado pela Microsoft, que entrega o circuito físico e faz a interconexão com o Azure. O modelo é adequado para a maioria das organizações, pois o provedor cuida da infraestrutura física e oferece opções de largura de banda de 50 Mbps a 10 Gbps.

O ExpressRoute Direct é a conexão direta com os roteadores da Microsoft, sem intermediário, disponível em locais de peering estratégicos. Ele permite larguras de banda de 10 Gbps e 100 Gbps, com controle total sobre o enlace e suporte a múltiplos circuitos virtuais sobre a mesma porta física. É a opção para grandes datacenters, provedores de serviços e organizações com tráfego massivo. O custo da porta física é significativamente mais alto e exige presença física no local de peering ou contratação de transporte até ele.

O ExpressRoute Global Reach resolve um problema específico: conectar dois circuitos ExpressRoute em regiões diferentes, permitindo que redes on-premises em continentes distintos se comuniquem entre si através da rede da Microsoft, sem passar pela internet. É a topologia indicada para empresas com filiais no Brasil e na Europa, por exemplo, que precisam sincronizar bancos de dados ou replicar dados entre datacenters. O Global Reach é um recurso Premium e adiciona custo por circuito conectado.

• Provedor de conectividade: entrada mais simples, 50 Mbps a 10 Gbps.
• ExpressRoute Direct: porta própria de 10/100 Gbps, controle total.
• Global Reach: conecta circuitos entre regiões, recurso Premium.

SKUs, largura de banda e redundância: como dimensionar sem superprovisionar

Dimensionar um circuito ExpressRoute exige equilíbrio entre desempenho e custo. Superprovisionar largura de banda que não será usada é desperdício mensal; subdimensionar gera saturação, perda de pacotes e incidentes em produção. O ponto de partida é medir o tráfego real entre on-premises e Azure — não a estimativa otimista do projeto — e projetar crescimento com base em dados, não em suposições.

Local, Standard e Premium: o que muda no alcance e no preço

As SKUs do ExpressRoute definem o alcance geográfico e os recursos disponíveis. A SKU Local permite conexão apenas com datacenters Azure da mesma região metropolitana do local de peering — ideal para empresas com presença concentrada em São Paulo conectando-se ao Azure Brazil South. A SKU Standard expande o alcance para todas as regiões dentro do mesmo continente geopolítico, enquanto a Premium libera conectividade global, mais rotas BGP, maior número de VNets vinculadas e o Global Reach.

O preço varia substancialmente entre SKUs. A Local é a mais barata e não cobra tráfego de saída dentro da mesma região; a Standard e a Premium cobram valores por GB de saída que variam conforme a região. Para uma empresa que opera exclusivamente no Brasil, a SKU Local com um circuito em São Paulo costuma ser a escolha econômica correta. A Premium só se justifica quando há necessidade de alcançar regiões fora da América do Sul ou de usar Global Reach.

Gateway de rede virtual, FastPath e zone redundancy

O gateway de rede virtual é o componente do lado Azure que recebe o circuito ExpressRoute. Ele define o throughput máximo do túnel: os SKUs de gateway ExpressRoute vão de 1 Gbps a 10 Gbps, e o dimensionamento errado aqui anula qualquer largura de banda contratada no circuito. Um circuito de 10 Gbps conectado a um gateway de 1 Gbps entrega, no máximo, 1 Gbps — um erro clássico de dimensionamento que gera custo sem benefício.

O FastPath é um recurso que envia o tráfego diretamente para as VMs, contornando o processamento do gateway e reduzindo a latência e o consumo de CPU. Ele é essencial para cargas de alta performance e está disponível em gateways de SKU UltraPerformance e ErGw3AZ. Já a zone redundancy distribui o gateway entre zonas de disponibilidade, eliminando o ponto único de falha. Para ambientes financeiros que não podem tolerar indisponibilidade, o gateway com zone redundancy é requisito mínimo de desenho.

Quanto custa de verdade: circuito, porta, gateway e tráfego de saída

O custo do ExpressRoute é composto por quatro elementos que precisam ser somados: o circuito com o provedor, a porta de interconexão, o gateway de rede virtual e o tráfego de saída. Muitas organizações orçam apenas o circuito e são surpreendidas pela conta final. O circuito com provedor de conectividade no Brasil pode variar de algumas centenas a vários milhares de reais mensais, dependendo da largura de banda e do provedor — valores que precisam ser cotados caso a caso, pois não há tabela pública uniforme.

O gateway de rede virtual tem custo fixo por hora, independentemente do tráfego, e varia conforme o SKU. Um gateway de 1 Gbps custa menos de US$ 0,50 por hora; um UltraPerformance de 10 Gbps custa várias vezes mais. O tráfego de saída — dados que saem do Azure em direção ao on-premises — é cobrado por GB, com preços que variam por região. Na SKU Local, a saída dentro da mesma região metropolitana é gratuita; nas SKUs Standard e Premium, o custo por GB pode chegar a alguns centavos de dólar, o que se torna significativo em volumes de dezenas de terabytes mensais.

Para uma estimativa realista, considere um cenário hipotético: circuito de 1 Gbps com provedor em São Paulo, gateway ErGw1AZ com zone redundancy e 10 TB de saída mensal na SKU Local. O custo total pode ficar entre R$ 8 mil e R$ 15 mil mensais, dependendo do provedor e do contrato. A mesma configuração com SKU Premium e 30 TB de saída pode ultrapassar R$ 25 mil. Antes de contratar, vale usar a calculadora de preços do Azure e pedir cotação formal a pelo menos dois provedores homologados.

Roteamento e integração com a rede on-premises durante a migração

A integração do ExpressRoute com a rede existente é onde a maioria dos projetos encontra complexidade. O circuito não funciona sozinho: ele precisa de configuração de BGP, alinhamento de prefixos e planejamento de coexistência com a infraestrutura atual. Erros nessa fase geram loops de roteamento, rotas assimétricas e indisponibilidade — problemas que só aparecem quando o tráfego de produção começa a fluir.

BGP, ASNs e prefixos: o que alinhar com o provedor

O ExpressRoute usa BGP (Border Gateway Protocol) para trocar rotas entre a rede on-premises e o Azure. Cada lado precisa de um ASN (Autonomous System Number) único: a Microsoft usa ASNs públicos específicos (12076 para tráfego público e 65515 para tráfego privado), e a organização precisa usar um ASN privado ou público que não entre em conflito. O provedor de conectividade atua como intermediário e pode exigir configurações específicas de VLAN e de endereçamento de peering.

Os prefixos anunciados ao Azure precisam ser cuidadosamente planejados. Anunciar prefixos sobrepostos ou muito amplos — como 0.0.0.0/0 — pode desviar tráfego indevidamente e causar conflitos com outras conexões. A recomendação é anunciar apenas as sub-redes que realmente precisam alcançar o Azure, com máscaras específicas, e validar cada prefixo antes de ativar o circuito em produção. O alinhamento com o provedor deve incluir também o endereço IP do peering, a VLAN de interconexão e a chave de autorização do circuito.

Coexistência com VPN e migração gradual de sub-redes

Durante a migração, ExpressRoute e VPN Site-to-Site podem coexistir no mesmo gateway, permitindo que o tráfego seja movido gradualmente. O Azure suporta a configuração de ambos os tipos de conexão no mesmo gateway, com o BGP determinando as rotas preferenciais. A prática recomendada é manter a VPN como rota de backup e failover, enquanto o ExpressRoute assume o tráfego de produção progressivamente.

A migração gradual de sub-redes reduz o risco: em vez de cortar toda a rede de uma vez, o time move uma sub-rede por vez, valida o comportamento e só então avança para a próxima. Esse processo exige planejamento de métricas de rota no BGP — como AS path prepend e local preference — para garantir que o tráfego siga o caminho desejado em cada fase. A migração para Azure e Microsoft 365 se beneficia diretamente dessa abordagem, pois permite validar a conectividade antes de mover cargas críticas.

Erros que encarecem a migração com ExpressRoute

Os erros mais caros no uso do ExpressRoute não são técnicos — são de planejamento e de contratação. O primeiro é contratar largura de banda baseada em pico teórico, não em uso real. Muitos projetos dimensionam o circuito para suportar o pico de migração inicial e depois ficam pagando por capacidade ociosa durante meses. A alternativa é usar ferramentas de transferência offline, como Azure Data Box, para o volume inicial e dimensionar o circuito para o tráfego permanente.

O segundo erro é ignorar o custo do tráfego de saída. Em cargas híbridas com replicação contínua de banco de dados, o volume de saída pode atingir dezenas de terabytes por mês, e o custo por GB se torna o principal componente da conta. Monitorar o tráfego de saída desde o primeiro dia e configurar alertas de custo no Azure Cost Management evita surpresas. O terceiro erro é não planejar redundância: um único circuito sem caminho alternativo deixa a organização dependente de um único provedor e de um único ponto de falha.

O quarto erro é subestimar a complexidade de BGP e roteamento. Configurações incorretas de ASN, prefixos sobrepostos ou métricas de rota mal definidas causam indisponibilidades que são difíceis de diagnosticar e corrigir sob pressão. O quinto erro é não testar failover: muitas organizações configuram VPN como backup, mas nunca executam um teste real de falha do circuito. Quando o circuito cai em produção, o failover não funciona como esperado e o incidente se prolonga.

• Dimensionar pelo pico de migração, não pelo tráfego permanente.
• Ignorar o custo de saída de dados em cargas híbridas.
• Operar com circuito único, sem redundância nem failover testado.
• Anunciar prefixos amplos demais e gerar conflitos de rota.
• Não validar o caminho de backup antes de precisar dele.

Checklist de decisão antes de contratar o circuito

Antes de assinar contrato com um provedor de conectividade, o time de TI deve responder a um conjunto de perguntas que determinam se o ExpressRoute é necessário, qual SKU atende e como o circuito será integrado. O checklist abaixo organiza os critérios em blocos de decisão e serve como documento de governança para aprovação do investimento.

1. Volume e janela: quantos TB serão migrados e em quanto tempo? O cálculo justifica circuito dedicado ou VPN + Data Box resolve?
2. Latência crítica: há cargas SAP, banco de dados síncrono, VDI ou VoIP que exigem latência abaixo de 15 ms estáveis?
3. Compliance: o tráfego inclui dados regulados que não podem transitar pela internet pública? Há exigência de auditoria?
4. Região: a operação está concentrada em uma região metropolitana (SKU Local) ou precisa alcançar outras regiões (Standard/Premium)?
5. Largura de banda real: qual o throughput médio e de pico medido nos últimos 90 dias entre on-premises e Azure?
6. Gateway: o SKU de gateway escolhido suporta o throughput do circuito? FastPath e zone redundancy são necessários?
7. Redundância: haverá segundo circuito, VPN de backup ou ambos? O failover foi testado?
8. BGP e prefixos: ASNs, VLANs e prefixos foram alinhados com o provedor e validados em ambiente de teste?
9. Custo total: foram somados circuito, porta, gateway e tráfego de saída? A estimativa foi validada na calculadora do Azure?
10. Estratégia de migração: a coexistência com a VPN atual foi planejada em fases, com migração gradual de sub-redes?

O ExpressRoute é uma decisão de arquitetura de longo prazo, não um item de curto prazo numa migração. Contratá-lo cedo demais gera custo ocioso; contratá-lo tarde demais gera retrabalho e risco operacional. O momento certo é quando os dados mostram que a VPN deixou de atender — e quando o checklist acima tem respostas objetivas para cada item. Para ambientes que processam Pix, dados financeiros ou cargas de missão crítica, a análise de segurança da infraestrutura Azure deve caminhar junto com o desenho de rede, garantindo que o circuito dedicado esteja inserido numa estratégia de proteção mais ampla.