Em ambientes corporativos na Azure, o VNet Peering é um recurso muito utilizado para conectar redes virtuais. Ele permite que recursos em VNets diferentes se comuniquem usando IP privado, trafegando pela backbone privada da Microsoft.

Mas nem sempre a necessidade é conectar uma VNet inteira com outra.

Em muitos cenários, uma aplicação precisa acessar apenas uma subnet de banco de dados. Um spoke precisa consumir somente uma subnet de DNS no hub. Um fornecedor precisa acessar apenas uma subnet de integração. Ou uma landing zone precisa expor apenas os serviços realmente necessários.

Quando o requisito é esse, conectar todo o address space das VNets pode ser mais amplo do que o necessário.

É aqui que entra o Subnet Peering.

Em vez de criar uma conectividade ampla:

vnet-app-prd  <──>  vnet-data-prd

Podemos criar uma conectividade mais específica:

snet-app  <──>  snet-database

A diferença parece pequena, mas muda bastante a abordagem de segurança, governança e troubleshooting.

O que é Subnet Peering

Subnet Peering permite conectar subnets específicas entre VNets, em vez de parear a VNet inteira. Segundo a documentação oficial, o recurso conecta duas redes virtuais vinculando subnets específicas, dando controle granular sobre quais subnets participam do relacionamento de peering.

Na prática, você deixa de dizer:

A VNet de aplicação pode falar com a VNet de dados.

E passa a dizer:

A subnet da aplicação pode falar com a subnet do banco.

Esse detalhe ajuda a aplicar o princípio de menor privilégio também na camada de rede.

Quando usar Subnet Peering

Subnet Peering faz sentido quando existe uma necessidade clara de granularidade.

Cenário	Exemplo
Aplicação acessando banco	`snet-app` → `snet-database`
Spoke consumindo serviço compartilhado	`snet-workload` → `snet-dns`
Integração com fornecedor	`snet-partner` → `snet-api-internal`
Private Endpoints centralizados	`snet-app` → `snet-private-endpoints`
Ambientes regulados	Subnets específicas por criticidade ou domínio

Não é um recurso para usar apenas porque existe. Ele deve resolver um problema real de exposição, governança ou segmentação.

Por que não controlar tudo apenas com firewall?

Firewall e peering resolvem problemas diferentes.

O peering define alcance de rede.
O firewall controla tráfego que passa por ele.

Se duas VNets estão pareadas e o tráfego segue diretamente pelo peering, uma regra no Azure Firewall não participa da decisão, a menos que exista uma rota direcionando esse tráfego para o firewall.

Em outras palavras:

Se o pacote não passa pelo firewall,
a regra do firewall não controla esse fluxo.

Um desenho mais saudável combina camadas:

Camada	Função
Subnet Peering	Define quais subnets participam da conectividade
NSG	Controla origem, destino, porta e protocolo
UDR	Força caminho por firewall/NVA quando necessário
Azure Firewall/NVA	Inspeciona o tráfego que passa por ele
Logs	Apoiam auditoria e troubleshooting

Subnet Peering não substitui firewall, NSG ou UDR. Ele reduz o escopo inicial da conectividade.

Como o roteamento entra nessa história

No Azure, cada subnet possui rotas efetivas. Mesmo sem route table customizada, o Azure cria rotas de sistema. Quando existe peering, rotas relacionadas ao relacionamento entre redes passam a participar do caminho.

Com Subnet Peering, o ponto principal é validar se o caminho foi criado apenas para as subnets selecionadas.

Por isso, em troubleshooting, não valide apenas se o peering está Connected.

Valide também:

Peering state
Peering sync status
Subnets selecionadas
Effective routes
NSG
UDR, se houver
Teste real de porta

Roteamento define caminho.
NSG define permissão.
Firewall inspeciona quando o tráfego passa por ele.

Laboratório prático

Objetivo

O objetivo do laboratório foi validar, na prática, que o Subnet Peering libera conectividade apenas entre as subnets selecionadas.

A arquitetura usada foi:

Arquietura de redes para o laboratório

vnet-app-prd
├── snet-web   10.50.1.0/24
├── snet-app   10.50.2.0/24
└── snet-admin 10.50.3.0/24

vnet-data-prd
├── snet-database 10.60.1.0/24
├── snet-backup   10.60.2.0/24
└── snet-admin    10.60.3.0/24

VMs usadas:

vm-web  → snet-web       → 10.50.1.10
vm-app  → snet-app       → 10.50.2.10
vm-db2  → snet-database  → 10.60.1.20

A vm-db2 foi usada como destino do teste na porta 22. As VMs não possuem IP público, então os testes validam comunicação privada entre subnets.

Baseline antes do Subnet Peering

Antes de criar o peering, a expectativa era simples:

vm-app → vm-db2 = bloqueado
vm-web → vm-db2 = bloqueado

Na vm-db2, validei que a porta 22 estava em escuta:

Resultado: OK
Conclusao: a vm-db2 esta pronta para receber os testes de conectividade.

Depois executei testes via Run Command na vm-app e na vm-web.

Resultado na vm-app:

Resultado: OK
Conclusao: a vm-app nao acessa a vm-db2 antes do Subnet Peering.

Resultado na vm-web:

Resultado: OK
Conclusao: a vm-web nao acessa a vm-db2 antes do Subnet Peering.

Esse baseline é importante porque comprova que a conectividade ainda não existia.

vm-db2 pronta para receber conexão.

vm-app bloqueada antes do peering.

vm-web bloqueada antes do peering.

Criação do Subnet Peering pelo portal

Para deixar o laboratório mais visual, a criação foi feita pelo portal do Azure.

Na tela de criação do peering, selecionei:

Peering type: Subnet
Remote virtual network: vnet-data-prd
Local subnet: snet-app
Remote subnet: snet-database

A configuração esperada era:

vnet-app-prd/snet-app
        ↕
vnet-data-prd/snet-database

Após a criação, o portal mostrou o peering como:

Peering state: Connected
Peering sync status: Fully Synchronized

A validação técnica confirmou:

peerCompleteVnets: false
localSubnetNames: snet-app
remoteSubnetNames: snet-database

Criação do Subnet Peering pelo portal do Azure, selecionando subnets específicas em vez de parear toda a VNet.

Criação do Subnet Peering pelo portal do Azure, selecionando subnets específicas em vez de parear toda a VNet.

Ponto de atenção: feature da subscription

Durante o laboratório, a primeira tentativa de criação retornou:

Erro ao criar subnet peering

A correção foi registrar a feature e atualizar o provider:

az feature register \
  --namespace Microsoft.Network \
  --name AllowMultiplePeeringLinksBetweenVnets

az provider register \
  --namespace Microsoft.Network

Depois disso, o Subnet Peering pôde ser criado normalmente. Esse tipo de validação é importante antes de testar em ambientes reais.

Teste após o Subnet Peering

Depois de criar o Subnet Peering entre snet-app e snet-database, executei novamente os testes.

Resultado na vm-app:

Resultado: OK
Conclusao: a vm-app acessa a vm-db2 apos o Subnet Peering.

Resultado na vm-web:

Resultado: OK
Conclusao: a vm-web continua sem acesso, pois nao faz parte do Subnet Peering.

Esse foi o principal resultado do laboratório.

Mesmo estando na mesma VNet da vm-app, a vm-web continuou bloqueada porque a snet-web não fazia parte do peering.

Origem	Destino	Resultado
`vm-app / snet-app`	`vm-db2 / snet-database`	Permitido
`vm-web / snet-web`	`vm-db2 / snet-database`	Bloqueado

Isso prova que o peering não abriu a VNet inteira.

Atualizando o peering: adicionando a snet-web

Como teste adicional, atualizei o mesmo Subnet Peering pelo portal e adicionei também a snet-web.

A configuração passou a ser:

vnet-app-prd/snet-app
vnet-app-prd/snet-web
        ↕
vnet-data-prd/snet-database

Um detalhe importante apareceu aqui: ao editar o peering pelo portal, é necessário manter as subnets anteriores selecionadas. Se você desmarcar snet-app e marcar apenas snet-web, o peering passa a considerar somente a nova seleção.

Depois de adicionar snet-web e sincronizar o peering, a vm-web passou a acessar a vm-db2.

Resultado:

A vm-web acessa a vm-db2 após ser adicionada ao Subnet Peering.

Resumo final:

Origem	Destino	Resultado
`vm-app / snet-app`	`vm-db2 / snet-database`	Permitido
`vm-web / snet-web`	`vm-db2 / snet-database`	Permitido

Esse teste reforça o conceito principal:

A conectividade muda conforme as subnets são adicionadas ou removidas do Subnet Peering.

Sincronização do peering

Durante a edição, o portal pode exibir mensagens como:

Isso indica que o peering está conectado, mas a alteração ainda precisa ser sincronizada entre os dois lados. A Microsoft recomenda sincronizar peerings quando há alteração de address space ou necessidade de atualização do relacionamento.

O estado esperado para concluir os testes é:

Se a comunicação não funcionar logo após uma alteração, valide primeiro a sincronização antes de investigar NSG, rota ou firewall.

Posso ter Subnet Peering e VNet Peering na mesma VNet?

Sim, desde que sejam relacionamentos com VNets diferentes.

Exemplo:

vnet-app-prd
├── Subnet Peering com vnet-data-prd
│   └── subnets específicas
│
└── VNet Peering tradicional com outra VNet
    └── VNet inteira

O que não deve ser assumido é criar vários peerings paralelos entre o mesmo par de VNets. Para alterar as subnets participantes, atualize o peering existente.

Cuidados antes de usar em produção

Antes de usar Subnet Peering em produção, valide:

Ponto	Recomendação
Feature	Confirme se a subscription está habilitada
Portal	Verifique se `Peering type = Subnet` está disponível
Subnets	Mantenha selecionadas todas as subnets necessárias
Sincronização	Aguarde `Fully Synchronized`
Segurança	Continue usando NSG
Roteamento	Valide effective routes
Firewall	Use UDR se o tráfego precisar passar por inspeção
Governança	Documente origem, destino, porta e justificativa
Automação	Em produção, prefira IaC ou pipeline controlado

Subnet Peering melhora a granularidade, mas também exige mais cuidado operacional.

Conclusão

Subnet Peering é útil quando a conectividade entre VNets precisa ser mais granular.

No laboratório, o comportamento ficou claro:

Antes do peering:
vm-app e vm-web não acessavam a vm-db2.

Após o Subnet Peering:
vm-app passou a acessar a vm-db2.
vm-web continuou bloqueada.

Após adicionar snet-web:
vm-web também passou a acessar a vm-db2.

Isso confirma que a conectividade é controlada pela lista de subnets participantes do peering, e não pela VNet inteira.

O principal aprendizado é simples:

Em cloud, conectividade não deve nascer ampla para ser corrigida depois.
Ela deve nascer mínima, documentada, validada e automatizada.

Subnet Peering não substitui NSG, UDR, firewall ou logs. Ele é mais uma camada para desenhar conectividade com menor exposição e melhor governança.