Todo mundo cria a primeira VNet sem pensar muito. Escolhe um /16 qualquer, coloca tudo em uma subnet, e funciona. O problema aparece dois anos depois, quando a empresa cresce, precisa conectar ao on-premises ou separar ambientes, e descobre que o range de IP conflita com tudo. Daí o custo de refatorar e recriar recursos numa rede nova.
Vale 30 minutos planejando antes de criar a primeira VNet.
O que é uma VNet, sem enrolação
Uma VNet é a rede privada do Azure. Isolamento fundamental que separa seus recursos dos de outros clientes e da internet. Tudo que você cria no Azure fica dentro de uma VNet ou precisa ser conectado a uma para se comunicar de forma privada.
Diferente de uma rede física, uma VNet é regional (existe dentro de uma região Azure), isolada por padrão (sem configuração explícita, VNets diferentes não se comunicam) e tem custo zero. O que você paga é pelo tráfego que sai.
resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
name: 'vnet-producao'
location: location
properties: {
addressSpace: {
addressPrefixes: ['10.0.0.0/16']
}
}
}
Subnets: o erro que parece simples
Dentro de uma VNet você cria subnets para segmentar recursos. O erro mais comum: criar tudo em uma subnet só porque é mais simples. O problema é que NSGs são aplicados por subnet. Sem subnets separadas, você não consegue ter regras de firewall diferentes para a camada web e para o banco de dados.
VNet: 10.0.0.0/16
+-- snet-web: 10.0.1.0/24 (servidores web)
+-- snet-app: 10.0.2.0/24 (logica de negocio)
+-- snet-data: 10.0.3.0/24 (bancos de dados)
+-- snet-pe: 10.0.4.0/26 (Private Endpoints)
Essa separação parece burocracia até o dia que você precisa bloquear todo o acesso direto ao banco de dados sem afetar a aplicação. Com subnets separadas, é uma regra de NSG. Sem elas, é uma semana de refatoração.
Planejamento de IP: o que não te contam
Use sempre ranges RFC 1918 (privados): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
O que importa de verdade: ranges sobrepostos inviabilizam peering e conectividade com on-premises. Se a VNet A usa 10.0.0.0/16 e a VNet B também usa 10.0.0.0/16, você nunca vai conseguir conectar as duas. E trocar o range de uma VNet em produção é destrutivo, você precisa recriar tudo.
Reserve mais espaço do que você acha que vai precisar. Use /16 para VNets de produção no mínimo. O espaço de IP não custa nada, a refatoração custa muito.
O que o Azure reserva (e você esquece de contar)
Em cada subnet, o Azure reserva 5 endereços para uso interno: .0 (rede), .1 (gateway), .2 e .3 (DNS), .255 (broadcast). Uma subnet /29 tem 8 IPs totais e só 3 disponíveis para seus recursos. Planeje com isso.
Como os recursos se comunicam
Por padrão, recursos na mesma VNet se comunicam livremente, mesmo em subnets diferentes. Para restringir, use NSGs. Para conectar VNets diferentes ou ao on-premises:
- VNet Peering: conexão direta entre duas VNets, mesmo entre regiões
- VPN Gateway: túnel criptografado pela internet para on-premises
- ExpressRoute: conexão privada dedicada para on-premises
Cada um tem custo e caso de uso diferente. O peering é o mais simples para conectar VNets no Azure. Para on-premises, a escolha entre VPN e ExpressRoute depende do volume de dados e dos requisitos de SLA.
Planejamento de IP bem feito desde o início é o tipo de decisão que não aparece em nenhum relatório, mas evita semanas de trabalho emergencial depois.