Migração de MSEE Hairpin para AVNM Mesh: conectividade VNet-to-VNet em larga escala no Azure

Migração de MSEE Hairpin para AVNM Mesh: conectividade VNet-to-VNet em larga escala no Azure

TL;DR: O roteamento hairpin via MSEE para tráfego east-west entre VNets não é escalável nem confiável a longo prazo. A alternativa é o mesh do Azure Virtual Network Manager (AVNM), que oferece conectividade direta dentro do datacenter, elimina a dependência do MSEE, suporta até 5.000 VNets e 20.000 Private Endpoints (com HSPE), e permite migração incremental sem downtime planejado. A conclusão principal: MSEE não é a ferramenta certa para tráfego east-west; AVNM mesh reduz complexidade operacional e melhora a latência.

Introdução

Um padrão comum em implantações Azure de grande porte é rotear o tráfego VNet-to-VNet através dos roteadores Microsoft Enterprise Edge (MSEE). Isso acontece quando VNets spoke em uma topologia hub-and-spoke se comunicam entre si fazendo hairpin através do circuito ExpressRoute: o tráfego sai do datacenter Azure, atravessa o MSEE e reentra no datacenter para alcançar a VNet de destino.

Esse padrão funciona, mas não foi projetado como modelo de conectividade de longo prazo para tráfego east-west. Com a conectividade mesh do Azure Virtual Network Manager (AVNM) e as recentes melhorias de escala — incluindo high-scale mesh de até 5.000 VNets e High-Scale Private Endpoints (HSPE) de até 20.000 Private Endpoints em VNets conectadas — as empresas podem migrar para um modelo de roteamento direto dentro do datacenter, eliminando a dependência do MSEE para tráfego VNet-to-VNet.

Este artigo explica por que a migração é vantajosa, quais são os novos limites de escala, como habilitar os recursos necessários e como executar a migração com o mínimo de disrupção.

Para quem é esta migração?

Esta migração é mais relevante se você tem 50 ou mais VNets spoke se comunicando east-west através de roteamento hairpin via ExpressRoute, está se aproximando dos limites de VNet peering, quer reduzir a utilização do ExpressRoute com tráfego interno ou precisa de um modelo de conectividade gerenciado centralmente mais simples. Mesmo que a maioria dos fluxos east-west continue passando por um firewall no hub para inspeção, você ainda pode simplificar o gerenciamento de conectividade para os fluxos que podem ir direto.

Por que o roteamento hairpin via MSEE para VNet-to-VNet não é recomendado?

Quando VNets spoke se comunicam através do MSEE, o tráfego segue um caminho subótimo:

Spoke A → Hub VNet → ExpressRoute Gateway → MSEE → ExpressRoute Gateway → Hub VNet → Spoke B

• Ponto único de falha. O MSEE se torna uma dependência compartilhada para tráfego east-west. Uma interrupção ou restrição de capacidade no MSEE pode afetar todos os pares de VNets na topologia.
• Caminho de maior latência. O tráfego não precisa mais sair do datacenter e retornar para a comunicação spoke-to-spoke. O mesh direto mantém o tráfego east-west em um caminho dentro do datacenter, que geralmente tem latência menor do que o hairpin via MSEE.
• Restrições de banda. Os circuitos MSEE têm largura de banda finita. Roteá-los através do tráfego east-west compete com o tráfego north-south on-premises e pode saturar o circuito.
• Risco operacional em escala. Grandes implantações colocam carga significativa na infraestrutura MSEE, criando preocupações de escalabilidade, confiabilidade e operacionais para ambientes com milhares de VNets.

Por que o peering manual não era uma alternativa prática?

A alternativa óbvia — criar peerings VNet diretos entre cada par de spokes — resolve a dependência do MSEE, mas introduz sua própria complexidade operacional:

• Crescimento combinatório. Conectar N spokes requer N × (N - 1) / 2 relações de peering. Para 100 spokes, são 4.950 peerings. Para 1.000 spokes, são quase 500.000.
• Sobrecarga de gerenciamento. Cada peering deve ser provisionado, monitorado e mantido individualmente. Isso aumenta deriva, auditoria e sobrecarga operacional.

Como o mesh AVNM resolve isso?

O mesh AVNM fornece conectividade baseada em grupos. Você define um conjunto de VNets como um grupo de rede, aplica uma configuração de conectividade mesh, e o AVNM estabelece conectividade bidirecional entre todos os membros.

O tráfego entre VNets em mesh permanece dentro do datacenter Azure: sem travessia MSEE, sem salto no hub e sem gerenciamento manual de peering.

• Defina uma vez, conecte todos. Uma única configuração de mesh conecta cada VNet do grupo a todas as outras.
• Gerenciamento centralizado. Adicione ou remova VNets do grupo; o AVNM reconcilia a conectividade automaticamente.
• Caminhos diretos spoke-to-spoke. O tráfego flui diretamente entre as VNets, ignorando tanto o hub quanto o MSEE.
• Membros dinâmicos. Use Azure Policy para inscrever automaticamente novas VNets com base em tags ou condições do resource group.

Como migrar topologias de grande escala?

O high-scale mesh permite migrar topologias maiores — até 5.000 VNets e 20.000 Private Endpoints em um mesh.

Escala — Standard Mesh vs. High-Scale Mesh

Dimensão	Standard Mesh	High-Scale Mesh
VNets por mesh	Até 250 (limite flexível, pode solicitar aumento)	Até 5.000
Private Endpoints por mesh	Até 2.000	Até 20.000 (com HSPE habilitado)
Private Endpoints por VNet	Até 1.000	Até 5.000 (com HSPE habilitado)

Habilitando High-Scale Private Endpoints (HSPE)

À medida que a abrangência do mesh cresce, também cresce o número de Private Endpoints implantados nas VNets conectadas. Os limites padrão da plataforma — 1.000 Private Endpoints por VNet e 2.000 em todas as VNets conectadas e mesh — podem ser atingidos rapidamente em ambientes grandes. Habilitar o HSPE eleva esses limites para 5.000 e 20.000, respectivamente.

Para migrações de mesh em larga escala, habilite o HSPE proativamente se o ambiente for crescer em direção aos limites padrão de Private Endpoint, seguindo as etapas abaixo.

Etapa 1 — Preparar cada VNet

1. Certifique-se de que as Private Endpoint Network Policies estejam definidas como Enabled ou RouteTableEnabled em todas as subnets que contêm Private Endpoints. Isso é um pré-requisito.
2. Defina a propriedade de nível de VNet PrivateEndpointVNetPolicies como Basic. Isso ativa o HSPE na VNet.

Etapa 2 — Habilitar HSPE na configuração de mesh

Na configuração de conectividade mesh do AVNM, habilite a opção para high-scale private endpoints. O AVNM valida que todas as VNets no mesh estão com HSPE habilitado. Se alguma VNet estiver sem a configuração, a implantação é bloqueada com um erro claro.

Etapa 3 — Implantar

Implante a configuração de conectividade. O AVNM aplica o HSPE em todo o mesh.

Mudanças de comportamento ao habilitar HSPE

• Breve reset de conexão. Habilitar ou desabilitar o HSPE aciona um reset único de aproximadamente 1 segundo nas conexões Private Endpoint existentes na VNet. Planeje isso durante uma janela de manutenção.
• Monitoramento Per-PE Bytes In/Out não está mais disponível. O HSPE trata cada IP de Private Endpoint como qualquer outro IP na VNet, o que remove os contadores de tráfego por PE. Se você depende de métricas por PE, avalie alternativas antes de habilitar.
• Mudança na faturação de tráfego PE on-premises. O tráfego PE originado on-premises aparece como uma fatura agregada na VNet do gateway, não no recurso Private Endpoint individual. O valor total da fatura não muda.

Como evitar downtime?

• Mesh coexiste com peerings existentes. O AVNM não exclui peerings criados manualmente, a menos que explicitamente configurado para isso.
• Tráfego muda automaticamente. Uma vez que o mesh é implantado, o tráfego spoke-to-spoke é roteado diretamente. O caminho hairpin MSEE permanece disponível se o mesh for removido.
• Nenhuma reconfiguração dos componentes do hub. Firewalls, gateways e NVAs no hub continuam funcionando. O tráfego north-south on-premises ainda flui através do gateway do hub.
• Rollback é simples enquanto o caminho legado permanece. Mantenha o caminho hairpin MSEE ativo durante a validação para que as VNets afetadas possam voltar atrás removendo-as do grupo de rede ou undeploy da configuração de mesh.

Segurança e inspeção de tráfego east-west

Uma preocupação comum é se a conectividade mesh direta ignora firewalls do hub ou network virtual appliances. A resposta depende de como a inspeção é aplicada hoje.

• Mesh fornece conectividade, não política de roteamento. Se as subnets spoke têm UDRs que direcionam o tráfego através de um NVA ou firewall do hub, essas UDRs continuam valendo e podem manter os fluxos inspecionados no caminho do firewall.
• Security Admin Rules fornecem segmentação centralizada. Para fluxos que não exigem inspeção de firewall, as Security Admin Rules do AVNM podem aplicar políticas de allow ou deny em nível de rede entre grupos de rede.
• Use ambos onde apropriado. O mesh pode fornecer conectividade direta para fluxos aprovados enquanto as Security Admin Rules impõem limites de segmentação onde necessário.

Recomendação: Antes de migrar, faça um inventário de quais fluxos spoke-to-spoke atualmente atravessam o firewall. Decida por fluxo se deve manter a inspeção mantendo UDRs no lugar ou permitir um caminho mesh direto removendo a UDR para aquele par de fluxos.

Ordem e processo de migração

A migração do roteamento hairpin MSEE para o mesh AVNM é projetada para ser não disruptiva. A conectividade mesh se sobrepõe aos peerings existentes e assume precedência de roteamento para tráfego east-west. Você não precisa derrubar a topologia hub-and-spoke existente primeiro.

Etapas recomendadas

1. Projete a topologia mesh. Agrupe VNets por região em grupos de mesh. Se você espera mais de 250 VNets por mesh, registre a feature flag AllowHighScaleConnectedGroup antecipadamente.
2. Crie um Network Manager e defina Network Groups. Certifique-se de que o escopo do AVNM cubra todas as assinaturas relevantes. Use associação estática para migração inicial ou membros dinâmicos via Azure Policy para inscrição contínua.
3. Habilite HSPE em cada VNet do mesh. Siga as etapas de habilitação do HSPE se você precisar de mais de 2.000 PEs em um mesh. Agende a mudança durante uma janela de manutenção para considerar o breve reset de conexão.
4. Crie a configuração de conectividade mesh no AVNM. Selecione os grupos de rede, habilite a topologia mesh, habilite high-scale private endpoints e habilite global mesh se for necessária conectividade entre regiões.
5. Implante incrementalmente. Comece com uma região piloto ou ambiente não crítico. Valide rotas efetivas, conectividade spoke-to-spoke, conectividade spoke-to-hub-to-on-premises, alcance de Private Endpoint e padrões esperados de VNet flow logs antes de expandir para regiões de produção.

Comportamento das rotas durante e após a migração

Durante a migração, mesh e MSEE podem coexistir. VNets conectadas ao mesh recebem rotas diretas para destinos mesh, enquanto as rotas existentes do gateway ExpressRoute continuam servindo destinos on-premises. UDRs ainda substituem rotas de sistema, portanto, padrões de forced-tunneling e inspeção de firewall permanecem em vigor quando UDRs estão presentes.

• Destinos mesh. O tráfego entre VNets conectadas ao mesh vai diretamente, em vez de hairpin via MSEE, quando nenhuma UDR substitui a rota.
• Destinos on-premises. O ExpressRoute continua fornecendo conectividade north-south para redes on-premises.
• Gateway transit. Os spokes podem continuar alcançando on-premises através do gateway do hub quando o design usa gateway transit.

Considerações de Infrastructure-as-Code

Se os peerings VNet são gerenciados via Terraform, Bicep ou ARM templates, trate o mesh AVNM como a nova fonte da verdade somente após validação.

1. Implante o mesh primeiro. O mesh AVNM pode coexistir com peerings existentes, portanto, não remova recursos de peering do IaC antes de validar o caminho mesh.
2. Valide o caminho de tráfego. Use rotas efetivas, Connection Monitor e flow logs para confirmar que o tráfego está usando o mesh onde esperado.
3. Proteja contra deriva. Revise o estado do pipeline e as configurações de ciclo de vida antes de descomissionar peerings antigos, especialmente em ambientes onde várias equipes gerenciam recursos de rede.
4. Codifique o AVNM. Gerencie o Network Manager, grupos de rede, configuração e implantação através de IaC para que o mesh se torne o modelo de conectividade governado.

Resolução DNS no mesh

A conectividade mesh não altera o comportamento de resolução DNS por si só. Se as VNets spoke já estão vinculadas a zonas DNS privadas hospedadas ou gerenciadas através do hub, esses links continuam determinando a resolução de nomes. Se os spokes usam servidores DNS personalizados no hub, verifique se quaisquer alterações de UDR feitas durante a migração não alteram inadvertidamente o caminho do tráfego DNS.

Exemplo de migração — Duas topologias hub-and-spoke em um único mesh

Este exemplo mostra como uma empresa pode migrar dois ambientes hub-and-spoke regionais para um mesh AVNM gerenciado centralmente, preservando o caminho MSEE existente durante a validação.

Estado atual — Duas topologias hub-and-spoke com hairpin MSEE

A Contoso Corp opera um grande ambiente Azure na região East US com duas topologias hub-and-spoke:

	Topologia A	Topologia B
Hub VNet	Hub-A	Hub-B
Spoke VNets	500	500
ExpressRoute Gateway	ER-GW-A em Hub-A	ER-GW-B em Hub-B
Circuito ExpressRoute	Circuito compartilhado, conectado a ambos os gateways	Mesmo circuito compartilhado
Média de Private Endpoints por spoke	~8 (4.000 total)	~12 (6.000 total)
Total de Private Endpoints	10.000 em ambas as topologias

Como o tráfego flui hoje:

• Spoke-to-spoke dentro da Topologia A: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-A → Hub-A → Spoke-A-02
• Spoke-to-spoke entre topologias: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-B → Hub-B → Spoke-B-01

Cada pacote spoke-to-spoke — seja dentro da mesma topologia ou entre topologias — sai do datacenter, atravessa o MSEE e reentra. Com 1.000 spokes gerando tráfego east-west, o MSEE se torna um ponto único de falha compartilhado e adiciona latência a cada fluxo.

Estado alvo — Um único mesh AVNM com 1.000 VNets

O objetivo da Contoso é consolidar todas as 1.000 VNets spoke em um único mesh AVNM, removendo o MSEE do caminho de tráfego east-west.

• Tráfego spoke-to-spoke, qualquer par: Spoke-A-01 → diretamente → Spoke-B-01. O tráfego permanece no datacenter e usa o caminho mesh direto.
• Papel do MSEE: O MSEE carrega tráfego north-south on-premises. A carga east-west é removida do caminho hairpin ExpressRoute.

Execução da migração

Fase 0 — Pré-trabalho

• Registre o recurso. Como o mesh contém 1.000 VNets, acima do limite padrão de 250, a Contoso registra o feature flag AllowHighScaleConnectedGroup na assinatura. Isso permite suporte a high-scale mesh para até 5.000 VNets.
• Inventário de Private Endpoints. Com 10.000 Private Endpoints em 1.000 VNets, a Contoso excede o limite padrão de mesh de 2.000 Private Endpoints. O HSPE deve ser habilitado.

Fase 1 — Habilitar HSPE em todas as 1.000 VNets spoke

• Lote 1: Habilitar HSPE em todas as 500 VNets spoke da Topologia A durante a janela de manutenção seguindo as instruções.
• Lote 2: Aplicar a mesma configuração às 500 VNets spoke da Topologia B.
• Impacto esperado: Cada VNet pode sofrer um breve reset de conexão para conexões Private Endpoint existentes quando o HSPE é habilitado. Agende a mudança durante uma janela de manutenção.

Fase 2 — Criar o mesh AVNM

1. Crie um Network Manager com escopo para o management group que contém todas as 1.000 VNets spoke.
2. Defina um único grupo de rede chamado eastus-mesh-all-spokes com associação dinâmica usando Azure Policy e tags.
3. Crie uma configuração de conectividade mesh. Defina a topologia como Mesh, grupo de rede como eastus-mesh-all-spokes, high-scale private endpoints como Enabled e global mesh como Not needed porque todas as VNets estão na mesma região.
4. Salve a configuração como rascunho e não implante ainda.

Fase 3 — Implantação incremental

Wave 1 — Piloto: A Contoso implanta a configuração mesh em 50 VNets dev/test, usando um grupo de rede temporário ou marcando apenas essas VNets inicialmente. A validação inclui rotas efetivas mostrando ConnectedGroup como tipo de next-hop para prefixos spoke meshed, conectividade spoke-to-spoke através do caminho mesh direto, alcance de Private Endpoint entre spokes meshed, conectividade on-premises inalterada através do hub e MSEE, e VNet flow logs confirmando fluxos spoke-to-spoke diretos esperados.

Wave 2 — VNets de produção com tráfego leve: Após um piloto bem-sucedido, a Contoso marca as VNets de produção com tráfego leve. O grupo de rede dinâmico as captura automaticamente. A Contoso reimplanta a configuração de conectividade, executa a mesma lista de verificação de validação e monitora o tráfego para confirmar que o tráfego east-west dessas VNets está se afastando do caminho hairpin ExpressRoute.

Wave 3 — Todas as VNets de produção restantes: A Contoso marca todos os spokes restantes e reimplanta a configuração. Neste ponto, todas as 1.000 VNets estão no mesh.

Migração sem downtime: Durante as Waves 2 e 3, o roteamento hairpin MSEE existente permanece funcional. As VNets que ainda não estão no mesh continuam a se comunicar através do MSEE. As VNets já no mesh se comunicam diretamente. Isso evita uma lacuna de conectividade planejada durante a migração.

Fase 4 — Validação pós-migração

Após a implantação, confirme que o mesh está ativo e que o tráfego está seguindo o caminho esperado antes de descomissionar a rota legada.

1. Rotas efetivas. Verifique se as subnets spoke mostram rotas diretas para prefixos de VNet peer em vez de roteamento através do gateway ou MSEE.
2. Connection Monitor. Acompanhe fluxos spoke-to-spoke representativos e compare latência e alcance antes e depois da migração.
3. VNet flow logs. Confirme se o tráfego east-west corresponde ao caminho mesh esperado e não está mais passando pelo gateway ExpressRoute.
4. Topologia do Network Watcher. Visualize o modelo de conectividade resultante e identifique quaisquer VNets não inscritas no grupo de rede alvo.

Se o tráfego ainda estiver fazendo hairpin após a implantação do mesh, verifique se há UDRs substituindo rotas de sistema, spokes faltando no grupo de rede, implantação não confirmada na região alvo ou pipelines IaC recriando peerings legados.

Rollback

• Rollback rápido enquanto o MSEE permanece. Remova as VNets afetadas do grupo de rede ou undeploy a configuração de conectividade mesh. O AVNM remove apenas a conectividade que criou, e o tráfego pode cair de volta para o caminho hairpin MSEE existente.
• Rollback após descomissionamento de caminhos legados. Se peerings antigos ou dependências de rota já foram removidos, o rollback pode exigir reprovisionamento desses recursos e deve ser tratado como uma janela de alteração mais longa.
• Recomendação. Mantenha o caminho hairpin MSEE disponível por pelo menos duas semanas após a implantação do mesh, monitore os padrões de tráfego e só então remova o caminho legado.

Sumário Antes e Depois

Métrica	Antes (MSEE Hairpin)	Depois (AVNM HSPE Mesh)
Latência spoke-to-spoke na mesma região	Mais alta devido ao caminho hairpin MSEE	Caminho direto de menor latência dentro do datacenter; a latência real depende da carga de trabalho, região e condições de rede
Caminho de tráfego east-west	Spoke → Hub → MSEE → Hub → Spoke	Spoke → Spoke diretamente através do Mesh
Dependência do MSEE para east-west	Sim, dependência compartilhada	Sem dependência do MSEE para tráfego east-west
Peerings manuais necessários	0 quando usa hairpin, mas 499.500 se construído manualmente para 1.000 spokes	0 peerings manuais spoke-to-spoke; AVNM gerencia conectividade
Private Endpoints suportados	2.000 por mesh sob limites padrão	20.000 por mesh com HSPE
Complexidade de rollback	Não se aplica ao modelo hairpin atual	Remover VNets do grupo de rede ou undeploy da configuração de conectividade
Downtime da migração	Não se aplica	Projetado para nenhum downtime planejado quando implantado incrementalmente e validado cuidadosamente

Considerações finais

Migrar para o mesh AVNM não requer derrubar sua rede existente. O gateway do hub, firewalls e NVAs continuam funcionando como hoje. O que muda é que o tráfego east-west spoke-to-spoke deixa de sair do datacenter desnecessariamente.

• MSEE não é a ferramenta certa para a malha east-west. Remover o tráfego interno do circuito ExpressRoute é uma melhoria de confiabilidade e capacidade.
• AVNM mesh substitui complexidade combinatória por intenção baseada em grupos. O modelo operacional escala com o número de grupos, não com o número de VNets.
• High-scale mesh e HSPE removem o teto — até 5.000 VNets e 20.000 Private Endpoints por mesh.
• A migração é incremental e reversível. O mesh coexiste com caminhos existentes, e você pode validar onda por onda antes de descomissionar a rota legada.

Comece com um mesh piloto em um ambiente não crítico, valide a mudança de tráfego e expanda a partir daí.

Recursos

• Connectivity configurations in Azure Virtual Network Manager
• Increase Private Endpoint virtual network limits
• Create a mesh topology with Azure Virtual Network Manager
• Security admin rules in Azure Virtual Network Manager
• Create a mesh network topology with Azure Virtual Network Manager using Terraform

---

Artigo originalmente publicado por Jay-Li em Azure Updates - Latest from Azure Charts.

Perguntas Frequentes

• O que é HSPE e quando devo habilitá-lo?
  HSPE (High-Scale Private Endpoints) é um recurso do AVNM que eleva os limites de Private Endpoints por VNet de 1.000 para 5.000 e por mesh de 2.000 para 20.000. Deve ser habilitado proativamente se sua topologia se aproximar ou ultrapassar os limites padrão, especialmente em ambientes com muitos spokes e Private Endpoints.

• A migração para mesh AVNM causa downtime?
  A migração é projetada para não ter downtime planejado, desde que feita incrementalmente. O mesh coexiste com peerings existentes e o caminho hairpin via MSEE permanece disponível como fallback. A única interrupção prevista é um reset de conexão de cerca de 1 segundo ao habilitar o HSPE em cada VNet, que deve ser agendado em janela de manutenção.

• Como a mesh impacta a inspeção de tráfego via firewall?
  Mesh fornece conectividade, não política de roteamento. Se você possui UDRs que direcionam tráfego para um NVA ou firewall, eles continuam valendo. As Security Admin Rules do AVNM podem complementar a segmentação. Recomenda-se inventariar quais fluxos spoke-to-spoke devem continuar passando pelo firewall e decidir por fluxo se mantém a inspeção ou permite caminho direto.

• Quais são os limites de escala do mesh padrão vs high-scale?
  O mesh padrão suporta até 250 VNets e 2.000 Private Endpoints por mesh, enquanto o high-scale mesh sobe para 5.000 VNets e 20.000 Private Endpoints (com HSPE). O limite de Private Endpoints por VNet também sobe de 1.000 para 5.000. Para topologias acima de 250 VNets, é necessário registrar a feature flag AllowHighScaleConnectedGroup.

• É possível reverter a migração após implementar o mesh?
  Sim, enquanto o caminho hairpin via MSEE for mantido. Basta remover as VNets do grupo de rede ou undeploy a configuração de mesh para que o tráfego volte a usar o roteamento hairpin. A recomendação é manter o caminho legado por pelo menos duas semanas após o deployment para monitorar e validar antes de descomissioná-lo.