Tipo de conteúdo: Modelo de governança e operação com laboratório prático
Nível: Intermediário / Avançado
Tecnologias: Azure Virtual Network Manager, Azure Virtual Network, Azure Policy, Azure CLI, ARM REST API via az rest e GitHub
Laboratório executado em: 26/05/2026
Repositório: https://github.com/leomcoco/azure-virtual-network-manager-enterprise-lab
Tempo estimado de leitura: 9 minutos
Tempo estimado de laboratório: 1h30
Resumo prático
Criar uma VNet no Azure é simples. O problema aparece quando o ambiente cresce.
Em organizações com muitas subscriptions, múltiplas equipes e workloads críticos, a conectividade entre redes pode virar uma dívida operacional: peerings criados manualmente, regras inconsistentes, exceções pouco documentadas e baixa visibilidade sobre quem se comunica com quem.
O Azure Virtual Network Manager ajuda a tratar esse problema como uma prática de plataforma. Ele permite agrupar, configurar, implantar e gerenciar redes virtuais em escala, inclusive em cenários com múltiplas subscriptions e tenants.
Neste artigo, a proposta é demonstrar um modelo prático para governar conectividade e segurança de redes Azure usando Azure Virtual Network Manager, com um laboratório controlado e reproduzível.
Governança de rede em escala exige mais do que peerings manuais.
O problema: quando o peering manual vira dívida operacional
Em ambientes pequenos, criar peerings entre VNets manualmente pode funcionar.
Em escala enterprise, esse modelo começa a gerar inconsistência.
Alguns sinais aparecem rapidamente:
- spokes criados fora do padrão;
- peerings sem documentação clara;
- conectividade liberada além do necessário;
- dificuldade para identificar quais redes pertencem a cada domínio;
- regras locais tentando compensar ausência de governança central;
- baixa rastreabilidade sobre mudanças de conectividade.
O problema não é apenas técnico. É operacional.
Quando a conectividade depende de ações manuais, cada nova VNet pode virar uma exceção. E exceção acumulada vira risco.
Onde o Azure Virtual Network Manager entra
O Azure Virtual Network Manager atua como uma camada central para organizar e aplicar configurações de rede em escala.
Na prática, ele ajuda a responder três perguntas:
| Pergunta | Recurso do AVNM |
|---|---|
| Quais VNets fazem parte de um mesmo domínio? | Network groups |
| Como essas VNets devem se conectar? | Connectivity configurations |
| Quais regras centrais devem prevalecer? | Security admin rules |
O serviço também permite associação dinâmica de VNets a grupos de rede usando Azure Policy. Esse ponto é importante para ambientes em que novas redes são criadas por diferentes times e precisam entrar automaticamente no modelo correto de governança.
O desenho do laboratório
O laboratório simula um cenário simples, mas aplicável a uma arquitetura enterprise.
A topologia usada é:
- 1 Resource Group;
- 1 Azure Virtual Network Manager;
- 1 VNet Hub;
- 2 VNets Spoke;
- 1 Network Group para os spokes;
- 1 configuração de conectividade hub-spoke;
- 1 exemplo de associação dinâmica com Azure Policy;
- 1 evidência de validação;
- 1 repositório GitHub com scripts e documentação.
O laboratório representa um padrão mínimo para governar conectividade e segurança entre VNets.
Decisões de arquitetura
O laboratório foi desenhado para ser seguro, barato e fácil de reproduzir em uma subscription de estudo.
Não será usado Azure Firewall neste primeiro cenário. A decisão é intencional: o objetivo é demonstrar governança de conectividade e segurança com Azure Virtual Network Manager, não inspeção centralizada de tráfego.
As principais decisões são:
| Decisão | Motivo |
|---|---|
| Usar Azure CLI | Facilita reprodução no Cloud Shell e no ambiente local |
| Usar topologia hub-spoke | Representa um padrão comum em ambientes enterprise |
| Criar poucos recursos | Reduz custo e simplifica validação |
| Usar tags | Facilita organização, evidência e limpeza |
| Versionar os artefatos | Permite rastreabilidade e reaproveitamento pela comunidade |
Tags usadas no laboratório:
environment = lab
workload = avnm-demo
owner = community
costCenter = mct-lab
managedBy = cli
article = azure-virtual-network-managerImplementação do laboratório
A implantação começa com a criação do Resource Group, das VNets e do Azure Virtual Network Manager.
A base do laboratório foi criada com Azure CLI: Resource Group, VNets, Azure Virtual Network Manager, network group e membros estáticos.
Para as configurações do Azure Virtual Network Manager, como connectivity configuration e security admin configuration, usei ARM REST API via az rest. Essa abordagem deixou o laboratório mais previsível no Git Bash/Windows e reduziu problemas de parsing da extensão virtual-network-manager.
Na prática, o leitor consegue executar o laboratório com scripts Bash, mas as configurações críticas do AVNM são aplicadas diretamente no formato ARM suportado pela Microsoft.
Comandos principais:
az extension add --name virtual-network-manager --upgrade
az group create \
--name rg-avnm-lab \
--location eastusDepois disso, o laboratório cria:
vnet-hub-shared-001;vnet-spoke-app-001;vnet-spoke-data-001;avnm-lab-001;ng-spokes-lab.
Instância do Azure Virtual Network Manager criada para governar as redes do laboratório.
Network groups: a base da governança
Network groups são usados para agrupar VNets que recebem o mesmo padrão de conectividade ou segurança.
No laboratório, o grupo ng-spokes-lab representa as redes spoke:
ng-spokes-lab
├── vnet-spoke-app-001
└── vnet-spoke-data-001Esse agrupamento evita tratar cada VNet de forma isolada. O foco passa a ser o domínio de rede.
Em ambientes maiores, é possível criar grupos por ambiente, plataforma, criticidade, exposição, unidade de negócio ou padrão de conectividade.
Network group usado para organizar as redes spoke do laboratório.
Associação dinâmica com Azure Policy
A associação dinâmica é um dos recursos mais relevantes para escala.
Com Azure Policy, uma VNet pode ser adicionada automaticamente a um network group quando atende a determinados critérios. O efeito addToNetworkGroup é específico para essa finalidade no Azure Virtual Network Manager e funciona em policies no modo Microsoft.Network.Data.
Exemplo de critério:
Se a VNet tiver:
environment = lab
workload = avnm-demo
role = spoke
Então:
adicionar ao network group ng-spokes-labEsse modelo reduz dependência operacional e ajuda a manter consistência quando novas redes são criadas.
Associação dinâmica permite que novas VNets entrem no grupo correto
Conectividade hub-spoke governada
Com o grupo de spokes definido, a conectividade pode ser aplicada de forma centralizada.
O padrão usado no laboratório é hub-spoke:
Hub:
- vnet-hub-shared-001
Spokes:
- vnet-spoke-app-001
- vnet-spoke-data-001O Azure Virtual Network Manager suporta configurações de conectividade para topologias como mesh e hub-spoke, incluindo propriedades como grupos aplicados, hub, conectividade entre spokes e escopo regional/global.
Configuração hub-spoke aplicada pelo Azure Virtual Network Manager.
Security admin rules: controle central antes da exceção local
Security admin rules permitem aplicar regras globais de segurança sobre VNets gerenciadas pelo Azure Virtual Network Manager. Essas regras podem permitir, sempre permitir ou negar tráfego nos grupos de rede definidos.
O uso mais adequado é criar uma camada central para controles que precisam ser consistentes.
Exemplo de regra para o laboratório:
Nome: deny-rdp-inbound-to-spokes
Objetivo: bloquear tráfego RDP inbound para as VNets spokes do laboratório
Ação: Deny
Protocolo: TCP
Porta: 3389
Escopo: network group ng-spokes-labEsse tipo de controle não substitui NSG, Azure Firewall ou NVA. Ele cria uma camada administrativa acima das decisões locais.
Security admin rules ajudam a aplicar controles centrais antes das
Validação do laboratório
A validação deve confirmar três pontos:
- o Azure Virtual Network Manager foi criado;
- as VNets foram associadas ao network group;
- a configuração de conectividade foi aplicada.
Comandos principais:
az network manager list \
--resource-group rg-avnm-lab \
--output tableaz network vnet list \
--resource-group rg-avnm-lab \
--output tableaz network manager list-effective-connectivity-config \
--resource-group rg-avnm-lab \
--virtual-network-name vnet-spoke-app-001A validação efetiva da conectividade é importante porque a configuração precisa ser confirmada nas regiões de destino por meio do processo de commit do Azure Virtual Network Manager. A documentação oficial demonstra esse fluxo com az network manager post-commit.
Validação confirma que a configuração foi aplicada às VNets do laboratório.
Evidência adicional: repositório GitHub
Além dos prints do Azure, Além das evidências no Azure, o laboratório também foi publicado em um repositório público no GitHub.
Isso reforça a rastreabilidade do conteúdo, facilita a reprodução por outros profissionais e transforma o artigo em uma contribuição técnica reutilizável para a comunidade.
Esse print ajuda como evidência pública porque mostra que o laboratório foi documentado, versionado e compartilhado com a comunidade.
Repositório público com os artefatos técnicos usados no laboratório.
Artefatos do laboratório no GitHub
Os artefatos usados neste laboratório estão disponíveis em um repositório público no GitHub:
O repositório contém os scripts de preparação, implantação, associação dinâmica com Azure Policy, criação da baseline de Security Admin Rule, validação e limpeza dos recursos.
A criação dos recursos base foi feita com Azure CLI. Para as configurações do Azure Virtual Network Manager, como connectivity configuration e security admin configuration, o laboratório usa ARM REST API via az rest.
Essa decisão deixou a execução mais previsível em ambientes locais com Git Bash no Windows e reduziu problemas de parsing da extensão virtual-network-manager.
O objetivo do repositório é permitir que outros profissionais reproduzam o laboratório, revisem os comandos, adaptem o cenário e usem os artefatos como ponto de partida para estudos ou provas de conceito.
Quando usar Azure Virtual Network Manager
Use quando o ambiente tiver:
- muitas VNets;
- múltiplas subscriptions;
- times diferentes criando redes;
- necessidade de padronizar conectividade;
- topologias hub-spoke ou mesh;
- governança central de segurança;
- associação dinâmica com Azure Policy;
- landing zones em expansão.
Quando não usar
Evite quando:
- o ambiente tem poucas VNets;
- ainda não existe arquitetura de rede definida;
- o problema principal é inspeção de tráfego L7;
- a organização quer substituir firewall ou NSG por AVNM;
- não há processo de mudança, validação e rollback;
- as regras ainda não foram testadas em sandbox.
O AVNM ajuda a governar a rede. Ele não corrige uma arquitetura mal desenhada.
Riscos e limitações
Antes de usar em produção, é necessário revisar as limitações oficiais do serviço.
A Microsoft documenta limites específicos para security admin rules, incluindo quantidade máxima de regras e restrições relacionadas a determinados service tags.
Também existe uma consideração importante: somente uma security admin configuration pode ser implantada por região, embora múltiplas connectivity configurations possam existir em uma mesma região.
Cuidados recomendados:
- testar em sandbox antes de produção;
- começar com escopo reduzido;
- revisar impacto por ambiente;
- documentar exceções;
- validar dependências de rede;
- manter rollback definido;
- versionar mudanças;
- usar revisão por pull request.
Como adotar em ambiente enterprise
Um caminho seguro de adoção é:
- mapear VNets existentes;
- classificar por ambiente, domínio e criticidade;
- definir network groups;
- testar associação dinâmica;
- aplicar conectividade primeiro em sandbox;
- validar security admin rules com escopo restrito;
- versionar scripts e documentação;
- implantar por pipeline;
- registrar evidências;
- expandir por ondas.
A maturidade está em transformar conectividade de rede em processo governado.
Checklist prático
Antes de levar para produção, valide:
- padrão de conectividade aprovado;
- VNets classificadas;
- network groups definidos;
- policies de associação dinâmica testadas;
- security admin rules revisadas;
- processo de exceção definido;
- rollback documentado;
- artefatos versionados;
- implantação revisada por pull request;
- evidências armazenadas;
- impacto validado em sandbox.
Conclusão
O Azure Virtual Network Manager é mais útil quando o desafio deixa de ser criar redes e passa a ser governar conectividade e segurança em escala.
Ele não substitui arquitetura, landing zone, firewall, NSG ou processo de mudança. Mas ajuda a transformar padrões de rede em configuração centralizada, reutilizável e auditável.
O valor está na previsibilidade: menos peering manual, menos exceção invisível e mais controle operacional.
Para ambientes Azure enterprise, esse é um recurso que merece entrar na conversa de governança de redes, principalmente quando a organização já opera múltiplas subscriptions, múltiplos times e workloads críticos.
Além da explicação conceitual, o laboratório publicado no GitHub ajuda a transformar o conteúdo em algo reproduzível, validável e útil para outros profissionais da comunidade.
Referências oficiais
- Microsoft Learn — What is Azure Virtual Network Manager?
- Microsoft Learn — Connectivity configurations in Azure Virtual Network Manager
- Microsoft Learn — Configuring network groups with Azure Policy in Azure Virtual Network Manager
- Microsoft Learn — Security admin in Azure Virtual Network Manager
- Microsoft Learn — Limitations with Azure Virtual Network Manager
- Microsoft Learn — Quickstart: create a mesh network topology with Azure Virtual Network Manager using Azure CLIMicrosoft Learn — Microsoft.Network/networkManagers/connectivityConfigurations
- Microsoft Learn — Microsoft.Network/networkManagers/securityAdminConfigurations
- Microsoft Learn — Azure Policy definitions addToNetworkGroup effect
