Fundamentação Teórica: Create and configure virtual networks and subnets

---

1. Intuição Inicial

Pense em como uma empresa organiza seu escritório físico. Há uma recepção acessível a todos, uma área de trabalho geral, uma sala de servidores com acesso restrito e uma sala de reuniões para clientes. Cada área tem suas regras de acesso. As pessoas dentro do mesmo andar se comunicam diretamente; para falar com outro andar, passam pelo elevador.

No Azure, a Virtual Network (VNet) é esse edifício. É o espaço de rede privado e isolado onde seus recursos vivem. As subnets (sub-redes) são os andares ou salas: divisões lógicas dentro da VNet que permitem organizar recursos e aplicar controles de tráfego diferentes para cada segmento.

Uma VM na subnet de aplicação fala diretamente com uma VM na subnet de banco de dados (mesmo edifício), mas o tráfego vindo da internet precisa passar por um porteiro controlado. Esse isolamento e organização são o propósito central das VNets e subnets.

---

2. Contexto

A VNet é a fundação da infraestrutura de rede no Azure. Praticamente todo recurso que precisa se comunicar com outros recursos ou com a internet passa por uma VNet.

100%

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

O Azure gerencia a infraestrutura física de rede. Você gerencia a topologia lógica: quais endereços IP existem, como os segmentos são divididos, quais regras de tráfego se aplicam e como as redes se conectam entre si.

Tudo que estudamos até agora (usuários, grupos, RBAC) é sobre quem pode gerenciar os recursos. As VNets são sobre como os recursos se comunicam. São dimensões complementares da segurança e operacao do Azure.

---

3. Construção dos Conceitos

3.1 Endereçamento IP e Notação CIDR

Antes de falar sobre VNets, é preciso entender como endereços IP são organizados. Uma VNet é definida por um intervalo de endereços IP, expresso em notação CIDR (Classless Inter-Domain Routing).

A notação CIDR tem o formato X.X.X.X/Y, onde:

• X.X.X.X é o endereço base
• /Y é o prefixo, que indica quantos bits são fixos (a parte da rede)

Exemplos práticos:

Notação CIDR	Endereços disponíveis	Faixa
10.0.0.0/8	16.777.216	10.0.0.0 a 10.255.255.255
10.0.0.0/16	65.536	10.0.0.0 a 10.0.255.255
10.0.0.0/24	256	10.0.0.0 a 10.0.0.255
10.0.1.0/24	256	10.0.1.0 a 10.0.1.255
10.0.0.0/28	16	10.0.0.0 a 10.0.0.15

Quanto maior o número após a barra, menor o bloco de endereços.

3.2 Espaços de Endereço Privados

O Azure recomenda usar os intervalos de IP privados (RFC 1918) para VNets:

Intervalo privado	CIDR	Uso típico
10.0.0.0/8	Até 10.255.255.255	Redes corporativas grandes
172.16.0.0/12	Até 172.31.255.255	Redes corporativas médias
192.168.0.0/16	Até 192.168.255.255	Redes menores

Usar endereços privados garante que não haverá conflito com IPs públicos da internet. Usar endereços públicos em uma VNet não é recomendado e pode causar problemas de roteamento.

3.3 A Virtual Network (VNet)

Uma VNet é um recurso Azure que define um espaço de endereçamento IP isolado. Características fundamentais:

• Escopo regional: uma VNet existe em uma única região Azure. VMs em regiões diferentes precisam de mecanismos de conectividade específicos (VNet Peering ou VPN).
• Escopo de assinatura: uma VNet pertence a uma assinatura e a um Resource Group.
• Isolamento por padrão: VNets diferentes são completamente isoladas entre si por padrão. Recursos em VNet-A não podem falar com recursos em VNet-B sem configuração explícita.
• Múltiplos espaços de endereço: uma VNet pode ter mais de um bloco CIDR associado, permitindo expansão futura sem recriar a VNet.

3.4 Subnets

Uma subnet é uma subdivisão do espaço de endereço da VNet. Ela deve ser um subconjunto do CIDR da VNet.

Exemplo:

• VNet: 10.0.0.0/16 (65.536 endereços)
• Subnet-Frontend: 10.0.1.0/24 (256 endereços)
• Subnet-Backend: 10.0.2.0/24 (256 endereços)
• Subnet-Database: 10.0.3.0/24 (256 endereços)
• Subnet-Management: 10.0.4.0/24 (256 endereços)

Endereços reservados pelo Azure em cada subnet: o Azure reserva automaticamente 5 endereços em cada subnet:

Endereço	Uso
Primeiro (ex: 10.0.1.0)	Endereço de rede
Segundo (ex: 10.0.1.1)	Gateway padrão (Azure)
Terceiro (ex: 10.0.1.2)	DNS mapeado para Azure DNS
Quarto (ex: 10.0.1.3)	Reservado para uso futuro
Último (ex: 10.0.1.255)	Broadcast

Isso significa que uma subnet /24 tem 256 endereços totais, mas apenas 251 disponíveis para recursos.

Implicação importante: o tamanho mínimo de subnet suportado pelo Azure é /29, que tem 8 endereços totais e apenas 3 disponíveis para recursos. Planeje com folga.

3.5 Tipos Especiais de Subnet

Algumas subnets têm nomes e comportamentos reservados:

Nome reservado	Propósito	Obrigatório?
GatewaySubnet	Hospeda VPN Gateway e ExpressRoute Gateway	Sim, se usar esses serviços
AzureFirewallSubnet	Hospeda Azure Firewall	Sim, se usar Azure Firewall
AzureFirewallManagementSubnet	Gerenciamento do Azure Firewall	Sim, em certos modos do Firewall
AzureBastionSubnet	Hospeda Azure Bastion	Sim, se usar Azure Bastion

A GatewaySubnet merece atenção especial: ela deve ter pelo menos /27 (recomendado /27 ou maior), não pode ter NSG associado, e não pode hospedar outros recursos além dos gateways.

3.6 Delegação de Subnet

A delegação de subnet é uma configuração que reserva uma subnet exclusivamente para um serviço Azure específico. Quando uma subnet é delegada, apenas aquele serviço pode implantar recursos nela.

Exemplos de serviços que usam delegação:

• Microsoft.ContainerInstance/containerGroups (Azure Container Instances)
• Microsoft.Web/serverFarms (App Service Regional VNet Integration)
• Microsoft.Sql/managedInstances (Azure SQL Managed Instance)
• Microsoft.NetApp/volumes (Azure NetApp Files)

A delegação é necessária porque esses serviços precisam de controle especial sobre o espaço de endereço e as rotas da subnet.

---

4. Visão Estrutural

100%

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

Como os Recursos se Comunicam Dentro de uma VNet

100%

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

Por padrão, todos os recursos dentro de uma VNet podem se comunicar livremente entre si, independentemente de estarem em subnets diferentes. O isolamento entre subnets requer configuração explícita via Network Security Groups (NSGs), que estudaremos em módulos posteriores.

---

5. Funcionamento na Prática

Ciclo de Vida de uma VNet

100%

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

Comportamentos Importantes e Não Óbvios

Espaços de endereço não podem se sobrepor com redes conectadas: se você planeja conectar sua VNet com outra VNet via peering, ou com uma rede on-premises via VPN, os espaços de endereço não podem se sobrepor. Por exemplo, se sua VNet usa 10.0.0.0/16 e a rede on-premises também usa 10.0.0.0/16, o roteamento ficará ambíguo e a conexão falhará. Planeje o endereçamento considerando todas as redes que precisarão se conectar.

Subnets não podem ser redimensionadas facilmente: você pode expandir o CIDR de uma subnet (torná-la maior) apenas se não houver conflito com outras subnets, e apenas se não houver recursos implantados nela com endereços que caiam fora do novo range. Na prática, reduzir uma subnet é impossível enquanto há recursos nela. Planeje com folga desde o início.

Adição de espaços de endereço à VNet: você pode adicionar blocos CIDR adicionais a uma VNet existente. O que você não pode fazer é modificar ou remover um espaço de endereço que já está em uso. Isso permite expansão gradual da VNet sem recriar tudo.

VNet não tem custo por si só: criar uma VNet e subnets não tem custo direto. Os custos de rede no Azure vêm de transferência de dados (especialmente entre regiões), endereços IP públicos, gateways e outros recursos de rede.

DNS por padrão: por padrão, o Azure fornece resolução de DNS para nomes dentro da VNet usando o Azure DNS (168.63.129.16). VMs na mesma VNet podem se resolver por hostname sem configuração adicional. Para resolução de nomes customizados ou on-premises, é necessário configurar um servidor DNS personalizado na VNet.

---

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: criacao inicial, exploração, ajustes pontuais.

Caminho: Create a resource > Networking > Virtual Network

O assistente de criacao no portal tem quatro abas:

1. Basics: nome, região, resource group
2. IP Addresses: espaço de endereço da VNet, criacao de subnets
3. Security: Azure Bastion, Azure Firewall, DDoS Protection (opcionais)
4. Tags: metadados de organização

Vantagem: o portal valida conflitos de CIDR em tempo real e avisa sobre problemas de configuração.

Limitação: não escala para múltiplas VNets ou ambientes repetíveis.

6.2 Azure CLI

Criar VNet com espaço de endereço:

az network vnet create \
  --name vnet-producao \
  --resource-group rg-networking \
  --location brazilsouth \
  --address-prefix 10.0.0.0/16

Adicionar subnets:

# Subnet de frontend
az network vnet subnet create \
  --name subnet-frontend \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --address-prefix 10.0.1.0/24

# Subnet de backend
az network vnet subnet create \
  --name subnet-backend \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --address-prefix 10.0.2.0/24

# GatewaySubnet (sem NSG, sem outros recursos)
az network vnet subnet create \
  --name GatewaySubnet \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --address-prefix 10.0.255.0/27

Adicionar segundo espaço de endereço à VNet existente:

az network vnet update \
  --name vnet-producao \
  --resource-group rg-networking \
  --add addressSpace.addressPrefixes "10.1.0.0/16"

Criar subnet com delegação para Azure Container Instances:

az network vnet subnet create \
  --name subnet-containers \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --address-prefix 10.0.10.0/24 \
  --delegations "Microsoft.ContainerInstance/containerGroups"

Listar subnets de uma VNet:

az network vnet subnet list \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --output table

6.3 PowerShell (Az Module)

# Criar VNet
$vnet = New-AzVirtualNetwork `
  -Name "vnet-producao" `
  -ResourceGroupName "rg-networking" `
  -Location "brazilsouth" `
  -AddressPrefix "10.0.0.0/16"

# Adicionar subnet de frontend
Add-AzVirtualNetworkSubnetConfig `
  -Name "subnet-frontend" `
  -VirtualNetwork $vnet `
  -AddressPrefix "10.0.1.0/24"

# Adicionar subnet de backend
Add-AzVirtualNetworkSubnetConfig `
  -Name "subnet-backend" `
  -VirtualNetwork $vnet `
  -AddressPrefix "10.0.2.0/24"

# Salvar as alterações na VNet
$vnet | Set-AzVirtualNetwork

Obter informações de uma VNet existente:

Get-AzVirtualNetwork `
  -Name "vnet-producao" `
  -ResourceGroupName "rg-networking" |
  Select-Object Name, Location, @{Name="AddressSpace";Expression={$_.AddressSpace.AddressPrefixes}},
    @{Name="Subnets";Expression={$_.Subnets | Select-Object Name, AddressPrefix}}

6.4 Bicep (Infrastructure as Code)

param location string = resourceGroup().location

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
  name: 'vnet-producao'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'subnet-frontend'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
      {
        name: 'subnet-backend'
        properties: {
          addressPrefix: '10.0.2.0/24'
        }
      }
      {
        name: 'subnet-database'
        properties: {
          addressPrefix: '10.0.3.0/24'
        }
      }
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '10.0.255.0/27'
        }
      }
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: '10.0.254.0/26'
        }
      }
    ]
  }
}

---

7. Controle e Segurança

Segmentação por Subnet como Princípio de Segurança

A separação em subnets não é apenas organizacional: é a base para aplicar controles de segurança diferentes a cada camada da aplicação:

100%

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

Esse modelo de segmentação em camadas (frontend, backend, database, management) é a arquitetura de referência para aplicações web no Azure. Cada camada fica em sua subnet, e NSGs controlam o tráfego entre elas.

Service Endpoints vs. Private Endpoints

Dois mecanismos que modificam como recursos Azure acessam serviços PaaS (como Storage, SQL, Key Vault) a partir de uma subnet:

Mecanismo	Como funciona	Quando usar
Service Endpoint	Roteia o tráfego para o serviço PaaS pela rede backbone do Azure, sem passar pela internet. O recurso PaaS ainda tem IP público.	Segurança básica, sem necessidade de IP privado para o serviço
Private Endpoint	Injeta uma NIC com IP privado da subnet para o serviço PaaS. O serviço fica acessível via IP privado da VNet.	Alta segurança, serviço PaaS acessível apenas de dentro da VNet

Service Endpoints são configurados na subnet. Private Endpoints são recursos separados que se associam à subnet.

---

8. Tomada de Decisão

Como dimensionar o espaço de endereço da VNet?

Situação	Recomendação	Motivo
Ambiente de produção pequeno (< 100 VMs)	/22 (1.022 endereços úteis)	Espaço suficiente com folga
Ambiente de produção médio (100-500 VMs)	/20 (4.094 endereços úteis)	Folga para crescimento e serviços
Ambiente enterprise ou hub central	/16 (65.531 endereços úteis)	Espaço para múltiplas subnets e serviços gerenciados
Ambiente de desenvolvimento	/24 (251 endereços úteis)	Menor custo de planejamento, ambiente temporário

Como dimensionar cada subnet?

Tipo de subnet	Tamanho recomendado	Motivo
Subnet de workload (VMs)	/24 ou maior	Flexibilidade para crescimento
GatewaySubnet	/27 (mínimo)	Requisito do serviço
AzureBastionSubnet	/26 (mínimo)	Requisito do serviço
AzureFirewallSubnet	/26 (mínimo)	Requisito do serviço
Subnet de serviço gerenciado (ex: AKS, SQL MI)	/24 ou maior	Serviços gerenciados consomem muitos IPs
Subnet de Private Endpoints	/27 ou maior	Cada Private Endpoint usa um IP

Uma VNet por ambiente ou compartilhada?

Abordagem	Quando usar	Trade-off
VNet separada por ambiente (prod, dev, staging)	Isolamento total entre ambientes, compliance rígido	Mais VNets para gerenciar, conectividade via peering se necessário
VNet compartilhada com subnets separadas	Equipes pequenas, ambientes simples	Menor isolamento, NSGs necessários para separação
Hub-Spoke (uma VNet central conectada a VNets de spoke)	Enterprise, múltiplas equipes, serviços compartilhados (Firewall, VPN)	Arquitetura mais complexa, mais escalável

---

9. Boas Práticas

Planeje o endereçamento IP antes de criar qualquer VNet: o espaço de endereço é difícil de mudar depois que recursos estão implantados. Mapeie todas as redes que precisarão se conectar (outras VNets, rede on-premises) e garanta que não há sobreposição. Um documento de IPAM (IP Address Management) é altamente recomendado.

Reserve espaço para serviços gerenciados: Azure Kubernetes Service (AKS), SQL Managed Instance e outros serviços gerenciados consomem muito mais endereços IP do que se imagina. Um cluster AKS médio pode precisar de centenas de IPs. Dimensione as subnets para esses serviços com generosidade.

Use naming conventions consistentes: nomes como snet-frontend-prod-brazilsouth (tipo-propósito-ambiente-região) facilitam a gestão e automação. O Azure recomenda que o nome da subnet comece com snet- para distinguir de outros recursos de rede.

Crie uma subnet por camada lógica, não por VM: a subnet é uma unidade de política de rede, não um container para uma única VM. Todas as VMs de frontend ficam em subnet-frontend, todas as de banco de dados ficam em subnet-database.

Sempre reserve a GatewaySubnet mesmo que não use agora: criar a GatewaySubnet na VNet inicial garante que o espaço de endereço está reservado para uso futuro. Adicionar depois pode ser impossível se os outros blocos já estiverem ocupados.

Não use /28 ou menor para subnets de workload: com apenas 11 endereços disponíveis (16 menos 5 reservados), uma subnet /28 fica cheia com menos de 10 VMs. Sempre prefira /24 ou maior para subnets que hospedam VMs.

---

10. Erros Comuns

Criar VNets com espaços de endereço que se sobrepõem

A empresa tem uma VNet em produção com 10.0.0.0/16 e uma rede on-premises que também usa 10.0.0.0/16. Quando tentam conectar via VPN, a conexão falha com erros de roteamento ambíguo. Para resolver, é necessário recriar a VNet com um espaço diferente e reimplantar todos os recursos, o que é um trabalho enorme. A solução é mapear todos os espaços de endereço existentes antes de criar qualquer VNet nova.

Dimensionar subnets muito pequenas

Um administrador cria uma subnet /27 (27 endereços úteis) para um cluster AKS. O AKS começa a expandir e em pouco tempo não há mais IPs disponíveis; novos pods ficam em Pending porque não conseguem receber um IP. Para AKS especialmente, subnets /24 ou maiores são o mínimo recomendado.

Associar NSG à GatewaySubnet

O Azure não permite associar NSGs à GatewaySubnet (e emite um aviso, mas alguns usuários ignoram). Mesmo quando a associação é feita, ela pode causar problemas de conectividade no gateway. A GatewaySubnet deve sempre ficar sem NSG.

Confundir o espaço de endereço da VNet com o da subnet

A VNet tem 10.0.0.0/16. O administrador cria uma subnet com 10.1.0.0/24, que está fora do espaço da VNet. O Azure rejeita a criacao com erro. A subnet deve sempre estar dentro do espaço de endereço da VNet.

Não planejar para peering antes de criar as VNets

Duas equipes criam suas VNets independentemente, ambas usando 10.0.0.0/16. Depois descobrem que precisam conectar as duas VNets via peering. Como os espaços se sobrepõem, o peering não pode ser criado. Uma das equipes precisa recriar sua VNet com um espaço diferente.

---

11. Operacao e Manutenção

Monitoramento de Uso de Endereços IP

Para verificar quantos IPs estão em uso em cada subnet:

# Listar IPs disponíveis em uma subnet
az network vnet subnet show \
  --name subnet-backend \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --query "{Nome:name, Prefix:addressPrefix, DisponivelIPs:ipConfigurations}" \
  --output json

O campo ipConfigurations lista todos os IPs atribuídos. A diferença entre o total de endereços da subnet (menos 5 reservados) e o número de ipConfigurations é a capacidade disponível.

Expandir a VNet com Novo Espaço de Endereço

# Adicionar novo bloco CIDR sem afetar recursos existentes
az network vnet update \
  --name vnet-producao \
  --resource-group rg-networking \
  --add addressSpace.addressPrefixes "10.1.0.0/16"

# Criar nova subnet no novo espaço
az network vnet subnet create \
  --name subnet-expansion \
  --vnet-name vnet-producao \
  --resource-group rg-networking \
  --address-prefix 10.1.0.0/24

Azure Network Watcher

O Network Watcher é o serviço de diagnóstico de rede do Azure. Funcionalidades relevantes para VNets:

• Topology: visão gráfica da topologia de rede de uma região
• IP Flow Verify: verifica se um pacote seria permitido ou negado entre dois pontos, com base nas regras de NSG
• Effective Routes: mostra as rotas efetivas de uma NIC específica
• Connection Troubleshoot: diagnostica conectividade entre dois endpoints

# Verificar se o tráfego da VM para um IP seria permitido
az network watcher test-ip-flow \
  --vm /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-backend \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.2.4:1433 \
  --remote 10.0.1.4:12345 \
  --resource-group rg-networking \
  --watcher-resource-group NetworkWatcherRG

Limites Importantes

Item	Limite padrão	Ajustável?
VNets por assinatura por região	1.000	Sim, via suporte
Subnets por VNet	3.000	Não
Espaços de endereço por VNet	200	Não
Endereços IP privados por VNet	65.536 (por bloco /16)	Não (adicionar mais blocos)
Endereços reservados por subnet	5	Não

---

12. Integração e Automação

Topologia Hub-Spoke com VNet Peering

A arquitetura hub-spoke é o padrão enterprise para organizar múltiplas VNets:

100%

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

No hub-spoke, serviços compartilhados (Firewall, VPN, DNS, Bastion) ficam no hub central, e cada spoke tem suas próprias subnets de workload. O tráfego entre spokes passa pelo hub (e pelo Firewall), garantindo visibilidade e controle centralizado.

Automação com Azure Policy

O Azure Policy pode garantir conformidade de VNets automaticamente:

• Exigir que todas as VNets de uma assinatura usem um intervalo de endereço específico
• Exigir que a GatewaySubnet tenha um tamanho mínimo
• Exigir que certas subnets tenham NSGs associados
• Exigir que Service Endpoints estejam habilitados para Storage e SQL

# Exemplo: atribuir política que requer NSG em todas as subnets
az policy assignment create \
  --name "require-nsg-on-subnets" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/2c2be004-5c73-4e68-9f32-f9e9b13f5f4e" \
  --scope "/subscriptions/<sub-id>"

VNets em Bicep com Módulos Reutilizáveis

Para organizações que gerenciam múltiplos ambientes, criar módulos Bicep reutilizáveis para VNets padroniza a criacao:

// Módulo: modules/vnet.bicep
param vnetName string
param location string
param addressPrefixes array
param subnets array

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: addressPrefixes
    }
    subnets: [for subnet in subnets: {
      name: subnet.name
      properties: {
        addressPrefix: subnet.prefix
      }
    }]
  }
}

output vnetId string = vnet.id
output subnetIds array = [for (subnet, i) in subnets: vnet.properties.subnets[i].id]

---

13. Resumo Final

Pontos essenciais:

• Uma VNet é um espaço de rede privado e isolado no Azure, definido por um ou mais blocos CIDR. Ela existe em uma única região e uma única assinatura.
• Subnets são subdivisões do espaço de endereço da VNet. O Azure reserva sempre 5 endereços por subnet (primeiro, segundo, terceiro, quarto e último).
• Por padrão, todos os recursos dentro de uma VNet se comunicam livremente entre si, independentemente de estarem em subnets diferentes. O isolamento requer NSGs.
• VNets diferentes são completamente isoladas entre si por padrão. Peering ou VPN é necessário para conectá-las.

Diferenças críticas:

• Espaço de endereço da VNet vs. CIDR da subnet: a subnet deve ser um subconjunto do espaço da VNet. Criar uma subnet com CIDR fora do espaço da VNet gera erro.
• Service Endpoint vs. Private Endpoint: Service Endpoint roteia o tráfego pelo backbone Azure mantendo o IP público do serviço; Private Endpoint injeta um IP privado da VNet no serviço PaaS.
• GatewaySubnet vs. subnets regulares: a GatewaySubnet tem nome obrigatório, não pode ter NSG e hospeda apenas gateways. Subnets regulares podem ter NSGs e hospedar qualquer recurso.
• Delegação de subnet vs. subnet regular: subnet delegada é reservada exclusivamente para um tipo de serviço Azure; subnets regulares podem hospedar qualquer recurso.

O que precisa ser lembrado:

• O tamanho mínimo de subnet suportado é /29, mas na prática use /24 ou maior para subnets de workload.
• A GatewaySubnet deve ter pelo menos /27 e não pode ter NSG.
• A AzureBastionSubnet deve ter pelo menos /26.
• O espaço de endereço planejado deve considerar todas as redes que precisarão se conectar (outras VNets, on-premises) para evitar sobreposição.
• O Azure reserva 5 endereços por subnet: leve isso em conta no dimensionamento.
• VNets são gratuitas; os custos de rede vêm de recursos como gateways, transferência de dados entre regiões e endereços IP públicos.
• Planejar o espaço de endereço antes de criar a VNet é muito mais fácil do que modificá-lo depois.