Fundamentação Teórica: Create and configure virtual network peering

1. Intuição Inicial

No módulo anterior, aprendemos que VNets são completamente isoladas entre si por padrão. Uma VM em vnet-producao e uma VM em vnet-desenvolvimento não podem se comunicar, assim como dois edifícios separados não têm corredor de conexão.

O VNet Peering é esse corredor: uma conexão direta entre duas VNets que permite que recursos em cada uma se comuniquem como se estivessem na mesma rede. Não há hardware adicional, não há criptografia (o tráfego já percorre a rede backbone privada da Microsoft), não há gateway, e a latência é a mesma que dentro de uma única VNet.

A analogia mais precisa é uma passarela entre dois edifícios corporativos: os edifícios continuam sendo estruturas independentes, com suas próprias regras internas, mas as pessoas podem circular entre eles de forma direta e rápida, sem sair para a rua.

2. Contexto

O VNet Peering resolve um dos problemas mais comuns em ambientes Azure de médio e grande porte: como conectar múltiplas VNets de forma eficiente. Ele é a base de duas arquiteturas amplamente utilizadas:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

As alternativas ao VNet Peering para conectar VNets são VPN Gateway (mais caro, mais lento, via internet ou túnel criptografado) ou ExpressRoute (para conexões dedicadas com on-premises). O peering é sempre a primeira escolha quando a necessidade é conectar duas VNets Azure, pela simplicidade e pelo desempenho.

3. Construção dos Conceitos

3.1 O que é um Peering: Natureza Bidirecional com Duas Entidades

Este é o conceito mais importante e mais frequentemente confundido sobre VNet Peering: um peering não é um único objeto; são sempre dois objetos separados.

Quando você conecta VNet-A e VNet-B, você cria:

Um peering de VNet-A em direção a VNet-B (configurado no lado da VNet-A)
Um peering de VNet-B em direção a VNet-A (configurado no lado da VNet-B)

Ambos precisam existir e estar no estado Connected para que a comunicação funcione. Se apenas um lado for criado, o estado fica Initiated (iniciado), e o tráfego não flui.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 Tipos de Peering

Tipo	Descrição	Latência
Local VNet Peering	VNets na mesma região Azure	Igual a dentro de uma única VNet
Global VNet Peering	VNets em regiões diferentes	Ligeiramente maior, usa backbone global da Microsoft

O Global VNet Peering permite conectar, por exemplo, uma VNet em Brazil South com uma VNet em East US. O tráfego percorre a rede privada da Microsoft, não a internet pública.

Restrição do Global Peering: alguns recursos não suportam tráfego via Global VNet Peering. O mais importante é o Azure Load Balancer Standard (tier Basic): VMs em uma VNet não podem ser alcançadas por recursos em uma VNet peered em região diferente usando o IP do Load Balancer. O acesso direto por IP da VM funciona normalmente.

3.3 As Configurações de Peering

Cada lado do peering tem configurações independentes. As mais importantes são:

Configuração	No lado	O que controla
Allow virtual network access	Ambos	Se os recursos da VNet de destino são acessíveis. Se desabilitado, o tráfego não flui mesmo com o peering conectado.
Allow forwarded traffic	Ambos	Se tráfego que foi encaminhado por um NVA (appliance de rede virtual) pode usar este peering. Crucial para hub-spoke.
Allow gateway transit	Lado que tem o gateway	Permite que a outra VNet use o gateway desta VNet (VPN ou ExpressRoute). Habilita conectividade on-premises via hub.
Use remote gateways	Lado que NÃO tem o gateway	Habilita o uso do gateway da outra VNet. Deve ser habilitado em conjunto com "Allow gateway transit" no outro lado.

A combinação de Allow gateway transit + Use remote gateways é o que permite que VNets spoke em uma arquitetura hub-spoke acessem a rede on-premises através do VPN Gateway que fica no hub.

3.4 Não Transitividade: O Conceito Fundamental

O VNet Peering é não transitivo. Isso significa que se A está conectado a B, e B está conectado a C, isso não implica que A pode se comunicar com C.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Para que A se comunique com C, é necessário:

Opção 1: Criar um peering direto entre A e C
Opção 2: Usar um NVA (Network Virtual Appliance, como um Azure Firewall) na VNet-B para encaminhar o tráfego, com User Defined Routes (UDRs) configuradas e "Allow forwarded traffic" habilitado nos peerings

A não transitividade é o motivo pelo qual a arquitetura hub-spoke requer configuração especial: o hub precisa ter um NVA ou firewall para rotear o tráfego entre spokes, e os peerings precisam ter "Allow forwarded traffic" habilitado.

4. Visão Estrutural

Peering Ponto a Ponto

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Arquitetura Hub-Spoke com Peering e Gateway Transit

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Nessa topologia:

Spoke1 acessa on-premises via gateway no Hub (graças a gateway transit)
Spoke2 acessa on-premises via gateway no Hub (mesmo mecanismo)
Tráfego entre Spoke1 e Spoke2 passa pelo Firewall no Hub (por UDRs, não por peering direto)
O Hub centraliza todos os serviços compartilhados

5. Funcionamento na Prática

Como o Tráfego Flui em um Peering

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Quando um peering é criado, o Azure automaticamente adiciona rotas de peering nas tabelas de rota efetivas das NICs em ambas as VNets. Essas rotas têm o prefixo da VNet remota e o next hop do tipo VNetPeering. Você pode ver essas rotas verificando as "Effective Routes" de qualquer NIC via Network Watcher.

Comportamentos Importantes e Não Óbvios

O peering não impede NSGs de bloquear o tráfego: criar um peering entre duas VNets não abre automaticamente todos os fluxos de tráfego. NSGs associados a subnets ou NICs nas VNets ainda se aplicam. Um NSG que bloqueia tráfego de 10.2.0.0/16 continuará bloqueando mesmo após o peering ser criado.

Mudanças de espaço de endereço exigem ação nos peerings: se você adicionar um novo bloco CIDR a uma VNet que já tem peerings, é necessário sincronizar os peerings para que as novas rotas sejam propagadas. No portal, há um botão "Sync" na configuração do peering. Sem a sincronização, VNets peered não conseguem alcançar os novos endereços.

Peering entre assinaturas diferentes: é completamente suportado, mas requer que o usuário que cria o peering tenha permissão nas duas VNets. O papel mínimo necessário é Network Contributor (ou um papel customizado com Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write) em ambas as VNets.

Custo do peering: diferentemente da criação da VNet em si, o VNet Peering tem custo baseado em volume de tráfego transferido. Local peering (mesma região) e global peering (entre regiões) têm preços diferentes, sendo o global mais caro. Planeje isso no dimensionamento de custos.

Não é possível usar espaços de endereço sobrepostos: se VNet-A tem 10.0.0.0/16 e VNet-B também tem 10.0.0.0/16, o peering falha. Os espaços devem ser completamente distintos e não sobrepostos.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: criação pontual de peering, visualização de status, diagnóstico.

Caminho: Virtual Networks > [selecionar VNet] > Peerings > Add

O formulário de criação de peering no portal tem uma conveniência importante: ao criar um peering de VNet-A para VNet-B, o portal oferece a opção de criar o peering reverso (VNet-B para VNet-A) ao mesmo tempo, desde que o usuário tenha permissão nas duas VNets. Isso evita o erro de criar apenas um lado.

Campos da criação:

Peering link name (lado local): nome do peering na VNet de origem
Peering link name (lado remoto): nome do peering na VNet de destino
Virtual network: a VNet de destino (suporta busca por nome, assinatura diferente, tenant diferente)
Traffic forwarded from remote virtual network: "Allow forwarded traffic"
Virtual network gateway or Route Server: "Allow gateway transit" ou "Use remote gateways"

6.2 Azure CLI

Criar peering em ambos os lados (operação recomendada: criar os dois em sequência):

# Peering de VNet-A para VNet-B
az network vnet peering create \
  --name peering-producao-to-dev \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --remote-vnet /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-dev \
  --allow-vnet-access true \
  --allow-forwarded-traffic true

# Peering de VNet-B para VNet-A
az network vnet peering create \
  --name peering-dev-to-producao \
  --vnet-name vnet-dev \
  --resource-group rg-networking \
  --remote-vnet /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-producao \
  --allow-vnet-access true \
  --allow-forwarded-traffic true

Criar peering entre VNets em assinaturas diferentes:

# Obter IDs completos das VNets
VNET_PROD_ID=$(az network vnet show \
  --name vnet-producao \
  --resource-group rg-networking \
  --subscription <sub-producao-id> \
  --query id -o tsv)

VNET_DEV_ID=$(az network vnet show \
  --name vnet-dev \
  --resource-group rg-dev \
  --subscription <sub-dev-id> \
  --query id -o tsv)

# Peering de Prod para Dev (executar com contexto da assinatura de Prod)
az network vnet peering create \
  --name peering-prod-to-dev \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --subscription <sub-producao-id> \
  --remote-vnet $VNET_DEV_ID \
  --allow-vnet-access true

# Peering de Dev para Prod (executar com contexto da assinatura de Dev)
az network vnet peering create \
  --name peering-dev-to-prod \
  --vnet-name vnet-dev \
  --resource-group rg-dev \
  --subscription <sub-dev-id> \
  --remote-vnet $VNET_PROD_ID \
  --allow-vnet-access true

Verificar status dos peerings:

az network vnet peering list \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --query "[].{Nome:name, Estado:peeringState, RemoteVNet:remoteVirtualNetwork.id}" \
  --output table

Sincronizar peering após mudança de espaço de endereço:

az network vnet peering sync \
  --name peering-producao-to-dev \
  --vnet-name vnet-producao \
  --resource-group rg-networking

Criar peering com gateway transit (lado do Hub):

az network vnet peering create \
  --name peering-hub-to-spoke1 \
  --vnet-name vnet-hub \
  --resource-group rg-hub \
  --remote-vnet <spoke1-vnet-id> \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --allow-gateway-transit true

Criar peering com use remote gateways (lado do Spoke):

az network vnet peering create \
  --name peering-spoke1-to-hub \
  --vnet-name vnet-spoke1 \
  --resource-group rg-spoke1 \
  --remote-vnet <hub-vnet-id> \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --use-remote-gateways true

Pré-requisito: --use-remote-gateways só funciona se o gateway no Hub já estiver provisionado e --allow-gateway-transit true estiver configurado no peering do lado do Hub.

6.3 PowerShell

# Obter referências às VNets
$vnetProd = Get-AzVirtualNetwork -Name "vnet-producao" -ResourceGroupName "rg-networking"
$vnetDev = Get-AzVirtualNetwork -Name "vnet-dev" -ResourceGroupName "rg-networking"

# Criar peering de Prod para Dev
Add-AzVirtualNetworkPeering `
  -Name "peering-producao-to-dev" `
  -VirtualNetwork $vnetProd `
  -RemoteVirtualNetworkId $vnetDev.Id `
  -AllowForwardedTraffic `
  -AllowVirtualNetworkAccess

# Criar peering de Dev para Prod
Add-AzVirtualNetworkPeering `
  -Name "peering-dev-to-producao" `
  -VirtualNetwork $vnetDev `
  -RemoteVirtualNetworkId $vnetProd.Id `
  -AllowForwardedTraffic `
  -AllowVirtualNetworkAccess

# Verificar status
Get-AzVirtualNetworkPeering `
  -VirtualNetworkName "vnet-producao" `
  -ResourceGroupName "rg-networking" |
  Select-Object Name, PeeringState, RemoteVirtualNetwork

6.4 Bicep

// Peering de VNet-A para VNet-B
resource peeringAtoB 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
  name: '${vnetA.name}/peering-a-to-b'
  properties: {
    remoteVirtualNetwork: {
      id: vnetB.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
  }
}

// Peering de VNet-B para VNet-A
resource peeringBtoA 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
  name: '${vnetB.name}/peering-b-to-a'
  properties: {
    remoteVirtualNetwork: {
      id: vnetA.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
  }
  dependsOn: [peeringAtoB]
}

O dependsOn garante que o primeiro peering seja criado antes do segundo, evitando condições de corrida.

7. Controle e Segurança

NSGs Ainda Se Aplicam com Peering

A criação de um peering não altera o comportamento dos NSGs. Um NSG que bloqueia tráfego de 10.2.0.0/16 continua bloqueando mesmo com o peering ativo. Isso é positivo do ponto de vista de segurança: o peering conecta as redes, mas os controles de tráfego (NSGs, Azure Firewall, UDRs) determinam o que pode fluir.

Prática recomendada: ao criar peerings, revise os NSGs em ambas as VNets para garantir que as regras necessárias estejam configuradas. NSGs que usam "VirtualNetwork" como source/destination incluem automaticamente VNets peered, o que pode ser mais permissivo do que o esperado.

Permissões Necessárias para Criar Peerings

Operação	Permissão necessária	Papel que inclui
Criar peering em VNet-A	`Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write` na VNet-A	Network Contributor, Owner
Criar peering em VNet-B (lado reverso)	`Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write` na VNet-B	Network Contributor na VNet-B
Criar peering entre assinaturas	Permissões nas duas VNets em suas respectivas assinaturas	Network Contributor em ambas

Para peering entre tenants diferentes, é necessário atribuir permissão explícita ao principal do outro tenant antes de criar o peering.

Rastreando Tráfego entre VNets Peered

O Network Watcher Flow Logs pode ser habilitado em cada VNet para registrar tráfego que flui pelas NICs. Para rastrear especificamente o tráfego via peering, as rotas efetivas de uma NIC mostrarão entradas com NextHopType: VNetPeering.

8. Tomada de Decisão

VNet Peering vs. outras opções de conectividade VNet

Situação	Melhor opção	Motivo
Duas VNets na mesma região Azure	VNet Peering local	Menor latência, custo baseado em tráfego, simples de configurar
Duas VNets em regiões diferentes	Global VNet Peering	Mesmo modelo, usa backbone privado Microsoft
VNet Azure e rede on-premises	VPN Gateway ou ExpressRoute	Peering não conecta ao on-premises; precisa de gateway
Muitas VNets precisam de conectividade centralizada	Hub-spoke com peerings	Escala bem, centraliza serviços
Precisão de alta segurança e inspeção entre VNets	Hub-spoke com Azure Firewall no hub	Peering + UDRs + Firewall para inspeção de tráfego
Conectividade transitiva entre dezenas de VNets	Azure Virtual WAN	Resolve transitividade nativamente, gerenciado pela Microsoft

Quando usar "Allow forwarded traffic"?

Situação	Habilitar?	Motivo
Peering direto sem NVA no caminho	Não necessário	Tráfego vai diretamente entre as VNets
Arquitetura hub-spoke com Firewall/NVA no hub	Obrigatório	O NVA encaminha tráfego entre spokes; sem isso, o tráfego encaminhado é descartado
Spoke precisa sair para internet via NVA no hub	Obrigatório	Mesmo princípio: o tráfego de saída é encaminhado pelo NVA

9. Boas Práticas

Crie ambos os lados do peering na mesma operação ou pipeline: a janela entre criar um lado e o outro é um período onde o tráfego ainda não flui. Em pipelines de Infrastructure as Code, crie os dois recursos no mesmo template para garantir atomicidade.

Use nomes de peering descritivos e padronizados: um padrão como peering-[vnet-origem]-to-[vnet-destino] (ex: peering-hub-to-producao) torna imediatamente claro qual a direção e as VNets envolvidas. Em ambientes com dezenas de peerings, nomes ambíguos tornam a manutenção muito mais difícil.

Documente a topologia de peering: em ambientes complexos, mantenha um diagrama atualizado de quais VNets estão conectadas entre si, via que tipo de peering (local ou global) e quais configurações especiais (gateway transit, etc.) estão ativas. Ferramentas como o Network Watcher Topology podem gerar essa visão automaticamente.

Planeje espaços de endereço sem sobreposição para todas as VNets futuras: o maior obstáculo ao peering é a sobreposição de endereços. Em empresas em crescimento, definir desde o início um plano de IPAM que aloca blocos únicos para cada VNet (produção, dev, staging, hub, e cada região) evita retrabalho futuro.

Para hub-spoke: habilite "Allow forwarded traffic" nos peerings de spoke desde a criação: mesmo que você não tenha um Firewall/NVA no hub agora, habilitar essa opção no começo evita ter que modificar os peerings depois, quando adicionar o Firewall e descobrir que o tráfego encaminhado está sendo descartado.

10. Erros Comuns

Criar apenas um lado do peering e confundir o estado "Initiated" com "Connected"

O peering fica no estado Initiated quando apenas um lado foi criado. Recursos nas duas VNets não conseguem se comunicar. O administrador verifica o peering no lado A, vê o estado e pensa que algo está errado com a rede, passa horas diagnosticando, quando a solução é simplesmente criar o peering no lado B. O portal facilita isso ao oferecer a criação simultânea dos dois lados.

Adicionar espaço de endereço à VNet sem sincronizar os peerings

A empresa adiciona um segundo bloco CIDR (10.1.0.0/16) à VNet de produção que já tem peering. VMs nos novos endereços (10.1.x.x) não conseguem se comunicar com VMs na VNet peered. As rotas de peering não foram atualizadas automaticamente. A solução é sincronizar o peering (botão "Sync" no portal ou az network vnet peering sync na CLI).

Assumir que peering é transitivo

A equipe de desenvolvimento cria VNet-Dev peered com VNet-Hub, e a equipe de dados cria VNet-Data também peered com VNet-Hub. Esperam que Dev e Data se comuniquem via Hub. Não funcionam porque peering não é transitivo. Para conectar Dev e Data, é necessário um peering direto entre elas, ou um Firewall no Hub com UDRs encaminhando o tráfego.

Habilitar "Use remote gateways" quando o gateway no hub ainda não existe

Você cria o peering do spoke para o hub com --use-remote-gateways true, mas o VPN Gateway no hub ainda não foi provisionado (gateways levam 30-45 minutos para provisionar). O peering falha com erro. O correto é habilitar essa opção apenas após o gateway estar completamente provisionado e operacional.

Não atualizar NSGs ao criar peerings

Peering criado entre VNet-Frontend e VNet-Database. Administradores assumem que agora as VMs de frontend acessam o banco de dados. Mas o NSG na subnet do banco de dados permite apenas tráfego de 10.0.2.0/24 (backend), não de 10.0.1.0/24 (frontend via peering). O peering existe, mas o NSG bloqueia. Sempre revise NSGs em ambas as VNets ao criar peerings.

11. Operação e Manutenção

Monitorar Status de Todos os Peerings de uma Assinatura

# Listar todos os peerings em todas as VNets de uma assinatura
$vnets = Get-AzVirtualNetwork
foreach ($vnet in $vnets) {
    $peerings = Get-AzVirtualNetworkPeering `
      -VirtualNetworkName $vnet.Name `
      -ResourceGroupName $vnet.ResourceGroupName

    foreach ($peering in $peerings) {
        [PSCustomObject]@{
            VNet = $vnet.Name
            PeeringName = $peering.Name
            Status = $peering.PeeringState
            RemoteVNet = $peering.RemoteVirtualNetwork.Id.Split('/')[-1]
            ForwardedTraffic = $peering.AllowForwardedTraffic
            GatewayTransit = $peering.AllowGatewayTransit
            UseRemoteGateways = $peering.UseRemoteGateways
        }
    }
} | Format-Table -AutoSize

Verificar Rotas Efetivas para Confirmar Peering Ativo

# Verificar rotas efetivas de uma NIC específica
az network nic show-effective-route-table \
  --name nic-vm-frontend \
  --resource-group rg-producao \
  --output table

Entradas com nextHopType: VNetPeering confirmam que o peering está ativo e as rotas foram propagadas.

Diagnóstico de Conectividade via Network Watcher

# Testar conectividade entre duas VMs (requer Network Watcher habilitado)
az network watcher test-connectivity \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-frontend \
  --dest-resource /subscriptions/<sub-id>/resourceGroups/rg-dev/providers/Microsoft.Compute/virtualMachines/vm-dev \
  --protocol TCP \
  --dest-port 80

O resultado mostra se a conexão foi bem-sucedida, e em caso de falha, onde no caminho o bloqueio ocorreu (NSG, rota, etc.).

Limites Importantes

Item	Limite padrão
Peerings por VNet	500
VNets em cadeia para Gateway Transit	1 (não é possível encadear: Spoke1-Hub1-Hub2-OnPrem)
Custo de transferência via peering	Cobrado por GB transferido (varia por região e direção)
Largura de banda do peering	Limitada pela largura de banda da NIC das VMs, não pelo peering

O limite de 500 peerings por VNet raramente é atingido em arquiteturas hub-spoke tradicionais, mas em ambientes enterprise muito grandes com Azure Virtual WAN pode ser relevante.

12. Integração e Automação

VNet Peering em Pipelines de Infraestrutura

Em pipelines CI/CD de infraestrutura (Azure DevOps, GitHub Actions), a criação de peerings deve fazer parte do processo de provisionamento de novas VNets. Um novo ambiente (ex: nova região de produção) deve automaticamente criar:

A nova VNet
Os peerings para o Hub
Os peerings reversos do Hub para a nova VNet
As UDRs necessárias para o roteamento

Exemplo de Terraform para criar peerings bidirecionais:

# Peering do Hub para o Spoke
resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  name                      = "peering-hub-to-${var.spoke_name}"
  resource_group_name       = var.hub_rg
  virtual_network_name      = var.hub_vnet_name
  remote_virtual_network_id = azurerm_virtual_network.spoke.id

  allow_forwarded_traffic      = true
  allow_gateway_transit        = true
  allow_virtual_network_access = true
}

# Peering do Spoke para o Hub
resource "azurerm_virtual_network_peering" "spoke_to_hub" {
  name                      = "peering-${var.spoke_name}-to-hub"
  resource_group_name       = var.spoke_rg
  virtual_network_name      = azurerm_virtual_network.spoke.name
  remote_virtual_network_id = var.hub_vnet_id

  allow_forwarded_traffic      = true
  use_remote_gateways          = var.use_remote_gateway
  allow_virtual_network_access = true

  depends_on = [azurerm_virtual_network_peering.hub_to_spoke]
}

Azure Virtual WAN: Alternativa Gerenciada para Conectividade em Escala

Para organizações com dezenas ou centenas de VNets e múltiplas conexões on-premises, o Azure Virtual WAN resolve o problema de transitividade de forma gerenciada:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

No Virtual WAN, a conectividade transitiva é nativa: Spoke1 pode falar com Spoke2 sem NVA ou UDRs adicionais. A Microsoft gerencia o roteamento internamente.

13. Resumo Final

Pontos essenciais:

Um VNet Peering são sempre dois objetos (um em cada VNet). Ambos precisam existir e estar no estado Connected para que o tráfego flua.
Peering é não transitivo: A peered com B, B peered com C, não significa que A comunica com C.
Dois tipos: Local VNet Peering (mesma região) e Global VNet Peering (regiões diferentes). Ambos usam a rede backbone privada da Microsoft.
Espaços de endereço das VNets peered não podem se sobrepor.
NSGs continuam se aplicando após o peering. O peering conecta as redes; os NSGs controlam o tráfego.

Diferenças críticas:

Estado "Connected" vs. "Initiated": Connected significa ambos os lados existem e a comunicação funciona. Initiated significa apenas um lado foi criado; sem comunicação.
Allow forwarded traffic vs. Allow gateway transit: o primeiro permite que tráfego encaminhado por um NVA passe pelo peering; o segundo permite que a outra VNet use o gateway desta VNet.
Peering vs. VPN Gateway: peering é direto, sem hardware, usa backbone privado, sem criptografia adicional. VPN usa gateway, tem custo de hora do gateway, é mais adequado para on-premises.
Peering local vs. Peering global: latência ligeiramente diferente; global peering tem custo de transferência maior e algumas limitações com Load Balancer Basic.

O que precisa ser lembrado:

Ao adicionar espaço de endereço a uma VNet que tem peerings, é necessário sincronizar os peerings para propagar as novas rotas.
Para hub-spoke com gateway no hub: Allow gateway transit no peering do hub + Use remote gateways no peering do spoke. O gateway deve estar provisionado antes de habilitar "Use remote gateways".
O peering entre assinaturas requer permissões de Network Contributor nas duas VNets, em suas respectivas assinaturas.
O limite é 500 peerings por VNet. Em ambientes muito grandes, considere Azure Virtual WAN.
A combinação peering + UDRs + NSGs forma a base de segmentação de rede no Azure. O peering fornece conectividade; UDRs controlam o roteamento; NSGs controlam o tráfego permitido.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 O que é um Peering: Natureza Bidirecional com Duas Entidades​

3.2 Tipos de Peering​

3.3 As Configurações de Peering​

3.4 Não Transitividade: O Conceito Fundamental​

4. Visão Estrutural​

Peering Ponto a Ponto​

Arquitetura Hub-Spoke com Peering e Gateway Transit​

5. Funcionamento na Prática​

Como o Tráfego Flui em um Peering​

Comportamentos Importantes e Não Óbvios​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Bicep​

7. Controle e Segurança​

NSGs Ainda Se Aplicam com Peering​

Permissões Necessárias para Criar Peerings​

Rastreando Tráfego entre VNets Peered​

8. Tomada de Decisão​

VNet Peering vs. outras opções de conectividade VNet​

Quando usar "Allow forwarded traffic"?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Monitorar Status de Todos os Peerings de uma Assinatura​

Verificar Rotas Efetivas para Confirmar Peering Ativo​

Diagnóstico de Conectividade via Network Watcher​

Limites Importantes​

12. Integração e Automação​

VNet Peering em Pipelines de Infraestrutura​

Azure Virtual WAN: Alternativa Gerenciada para Conectividade em Escala​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 O que é um Peering: Natureza Bidirecional com Duas Entidades

3.2 Tipos de Peering

3.3 As Configurações de Peering

3.4 Não Transitividade: O Conceito Fundamental

4. Visão Estrutural

Peering Ponto a Ponto

Arquitetura Hub-Spoke com Peering e Gateway Transit

5. Funcionamento na Prática

Como o Tráfego Flui em um Peering

Comportamentos Importantes e Não Óbvios

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell

6.4 Bicep

7. Controle e Segurança

NSGs Ainda Se Aplicam com Peering

Permissões Necessárias para Criar Peerings

Rastreando Tráfego entre VNets Peered

8. Tomada de Decisão

VNet Peering vs. outras opções de conectividade VNet

Quando usar "Allow forwarded traffic"?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Monitorar Status de Todos os Peerings de uma Assinatura

Verificar Rotas Efetivas para Confirmar Peering Ativo

Diagnóstico de Conectividade via Network Watcher

Limites Importantes

12. Integração e Automação

VNet Peering em Pipelines de Infraestrutura

Azure Virtual WAN: Alternativa Gerenciada para Conectividade em Escala

13. Resumo Final