Azure redes virtuais e sub-redes

Azure redes virtuais (VNets) e sub-redes são os blocos de construção fundamentais de cada rede Azure. Este artigo explica como as VNets fornecem isolamento, como as sub-redes organizam recursos e como dimensionar e estruturar sua rede para cargas de trabalho de produção.

O que este artigo aborda

Este artigo aborda os limites de isolamento da VNet, o dimensionamento de sub-redes e os endereços reservados, sub-redes de plataforma dedicadas para serviços como Firewall do Azure e Application Gateway, o emparelhamento de VNet e padrões comuns de layout de rede.

Quem precisa deste artigo

Leia este artigo se você:

  • Estão implantando sua primeira carga de trabalho para Azure e precisam entender como a rede funciona antes de criar recursos.
  • Estão planejando um ambiente de várias cargas de trabalho e precisam decidir quantas VNets e sub-redes criar.
  • Estão migrando cargas de trabalho locais para Azure e precisam entender como Azure rede difere da rede física.
  • É necessário dimensionar as sub-redes corretamente para Azure serviços de plataforma, como Firewall do Azure, Gateway de VPN ou AKS (Serviço de Kubernetes do Azure).
  • Deseja entender quando separar cargas de trabalho em VNets diferentes em vez de mantê-las na mesma VNet.

Foco em migração direta: espelhe a segmentação de sub-redes do seu ambiente local no Azure. Mapeie as VLANs e as zonas de segurança existentes para sub-redes, mantenha os espaços de endereçamento alinhados com as faixas que sua equipe já utiliza e dimensione as sub-redes com folga para que você não precise reendereçar durante a migração.

Modernizar o foco: Crie sub-redes em torno de serviços de plataforma e automação. Dimensione corretamente as sub-redes para AKS, endpoints privados e serviços de plataforma dedicados, e planeje o uso do Gerenciador de Rede Virtual do Azure para aplicar uma configuração consistente em muitas VNets.

Foco em nuvem cruzada: planeje espaços de endereço não sobrepostos no Azure, AWS e Google Cloud antes de criar qualquer VNet. Reserve intervalos CIDR que não entrem em conflito com VPCs existentes para que você possa estabelecer emparelhamento ou conectar-se a nuvens via VPN sem NAT.

Azure serviços e recursos

Os seguintes serviços e recursos compõem a base de rede virtual no Azure:

Serviço ou recurso O que ele fornece Quando usar isso
Rede Virtual do Azure (VNet) Uma rede isolada e privada em Azure. Tudo sobre rede no Azure começa aqui. Os recursos na mesma VNet podem se comunicar por padrão; recursos em VNets diferentes não podem se comunicar, a menos que você os conecte explicitamente. Sempre: toda carga de trabalho que precisa de conectividade de rede requer uma VNet.
Sub-rede Uma partição do espaço de endereço da VNet. As sub-redes são o escopo do NSG (grupo de segurança de rede) e da associação de tabela de rotas. Sempre: organize componentes de carga de trabalho em sub-redes por função ou limite de segurança.
Emparelhamento de VNet Conectividade privada de baixa latência entre duas VNets na mesma região ou entre regiões. O tráfego permanece na infraestrutura da Microsoft. O emparelhamento não é transitivo; cada emparelhamento é um link direto. Quando os recursos em VNets separadas precisam se comunicar. Para emparelhamento entre regiões, consulte conectividade entre regiões.
Emparelhamento de sub-redes (versão preliminar) Emparelhamento entre sub-redes específicas em vez de VNets inteiras. Fornece controle granular sobre quais sub-redes participam dos relacionamentos de emparelhamento. Quando você precisa de controle de emparelhamento preciso entre sub-redes específicas em diferentes VNets. Consulte a seção de restrições .
Tabela de rotas/UDRs (rotas definidas pelo usuário) Substitua as rotas padrão do sistema em Azure para controlar para onde o tráfego é enviado. Aplicado no nível da sub-rede. Quando você precisa forçar o tráfego através de um firewall ou dispositivo virtual de rede (NVA). Necessário para o controle de saída em topologia hub-and-spoke. Consulte Design do Firewall do Azure e Topologia hub-and-spoke.
Gerenciador de Rede Virtual do Azure (AVNM) Crie, gerencie e aplique centralmente configurações de rede às VNets em várias assinaturas. Ao gerenciar várias VNets em diversas assinaturas. Consulte o gerenciamento de rede centralizado.

Diagrama mostrando a VNet com sub-redes de carga de trabalho para camadas web, de aplicativo e de dados ao lado de sub-redes de plataforma dedicadas para gateway, firewall e Bastion

Como escolher

O que é uma rede virtual?

Uma rede virtual (VNet) é uma rede isolada definida pelo software em Azure. Pense nisso como sua rede privada em Azure. Ao contrário de uma rede física que usa cabos, comutadores e roteadores, uma VNet é totalmente definida pelo software. Você o cria, atribui um espaço de endereço e implanta recursos nele.

Principais características:

  • Com escopo regional: uma VNet existe em uma única região do Azure. Todos os recursos nessa VNet devem estar na mesma região. Uma VNet abrange zonas de disponibilidade nessa região.
  • Isolamento por padrão: recursos em uma VNet não podem se comunicar com recursos em outra VNet, a menos que você crie explicitamente uma conexão (emparelhamento ou VPN).
  • Conectividade interna padrão: os recursos na mesma VNet podem se comunicar entre si por padrão por meio de rotas do sistema que Azure fornece.

O que é uma sub-rede?

Uma sub-rede é um intervalo de endereços IP em sua VNet. As sub-redes permitem que você:

  • Segmentar sua rede por componente de carga de trabalho (por exemplo, camada da Web, camada de aplicativo, camada de dados).
  • Aplicar regras de segurança: Os NSGs são anexados no nível da sub-rede para filtrar o tráfego.
  • Roteamento de controle: tabelas de rotas são anexadas no nível da sub-rede para direcionar o tráfego.

Azure reserva cinco endereços IP em cada sub-rede: os quatro primeiros endereços e o último endereço. Por exemplo, em uma sub-rede /24 (256 endereços), apenas 251 são utilizáveis. Leve essa reserva em consideração em seus cálculos de dimensionamento.

Exemplo: aplicativo de três camadas

Um aplicativo Web típico de três camadas usa três sub-redes para separar preocupações e aplicar regras de segurança distintas:

Sub-rede Faixa de CIDR Purpose Recursos de exemplo
web-subnet 10.0.1.0/24 Servidores web front-end que aceitam tráfego HTTP/HTTPS de entrada da Internet ou do Gateway de Aplicativo. Ambiente do Serviço de Aplicativos do Azure, Conjuntos de Dimensionamento de Máquinas Virtuais executando NGINX.
app-subnet 10.0.2.0/24 Lógica de aplicativo de camada intermediária. Aceita o tráfego somente da sub-rede Web. Azure Functions (integrado à VNet), VMs executando lógica de negócios
data-subnet 10.0.3.0/24 Armazenamentos de dados. Aceita o tráfego somente da sub-rede do aplicativo. Sem acesso direto à Internet. Instância Gerenciada de SQL do Azure, pontos de extremidade privados para o Banco de Dados SQL do Azure ou Cosmos DB.

Esse layout permite aplicar um NSG a cada sub-rede que restringe o tráfego apenas ao que essa camada precisa. A sub-rede Web permite HTTPS de entrada (porta 443). A sub-rede do aplicativo permite o tráfego de entrada somente do intervalo de IP da sub-rede Web. A sub-rede de dados permite o tráfego de entrada somente do intervalo de IP da sub-rede do aplicativo.

Para um padrão de modernização baseado no AKS, você pode usar uma sub-rede aks-nodes, como 10.0.4.0/24, para os conjuntos de nós do cluster ao implantar o Azure CNI Overlay. Nesse modelo, somente os nós consomem endereços IP da VNet da sub-rede. Os pods usam um CIDR de sobreposição separado, o que permite manter a sub-rede do nó menor do que um design de rede plana do AKS.

Padrões comuns

Os layouts de sub-rede a seguir abrangem os cenários de implantação de Azure mais comuns:

Pattern Subnets Quando usar
Aplicativo Web simples web + data Aplicativos de duas camadas com um front-end e um banco de dados. Complexidade mínima.
Empresa de três camadas web + app + data + management Cargas de trabalho empresariais tradicionais com camadas distintas e uma sub-rede jump box ou Bastion para administração.
AKS com serviços compartilhados aks-nodes + aks-ingress + appgw + shared Cargas de trabalho do Kubernetes com uma sub-rede dedicada para o controlador de entrada e um Gateway de Aplicativo para WAF.
Saída em topologia hub-and-spoke AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management A VNet central em uma topologia hub-and-spoke. Serviços compartilhados pelos quais as VNets spoke roteiam o tráfego. Consulte topologia Hub-and-spoke.
Carga de trabalho de dados compute + data + private-endpoints + management Cargas de trabalho de plataforma de dados e análise onde pontos de extremidade privados para armazenamento e bancos de dados precisam de sua própria sub-rede para clareza no planejamento de IP.

Quantas VNets e sub-redes?

O princípio de orientação é simples: use uma rede virtual por aplicativo e uma sub-rede por componente (camada). Esse padrão mantém cada carga de trabalho isolada, facilita o controle do tráfego entre camadas com grupos de segurança de rede e deixa espaço para crescer. Ajuste a partir daí com base em serviços compartilhados, requisitos de isolamento e escala.

Use esta tabela de decisão para determinar sua VNet e sua estratégia de sub-rede:

Sua situação Abordagem recomendada
Carga de trabalho única, equipe única, nenhum serviço compartilhado necessário Uma VNet com sub-redes por componente de aplicativo (Web, lógica do aplicativo, dados). Consulte a topologia de carga de trabalho única.
Várias cargas de trabalho independentes que compartilham um gateway ou firewall VNet central para serviços compartilhados + uma VNet spoke por carga de trabalho. Consulte a topologia hub-and-spoke.
Isolamento estrito entre cargas de trabalho (raio de explosão, requisitos de conformidade) Uma VNet por carga de trabalho, sem emparelhamento entre elas.
Ambiente muito grande com muitas assinaturas e regiões WAN Virtual do Azure com gerenciamento de hub automatizado. Consulte WAN Virtual topologia.

Referência de dimensionamento de sub-rede dedicada

Muitos serviços de plataforma do Azure exigem sua própria sub-rede dedicada com um nome específico e um tamanho mínimo. O diagrama a seguir mostra os requisitos de nomenclatura e os tamanhos mínimos para sub-redes de plataforma dedicadas:

Diagrama mostrando os tamanhos mínimos de sub-rede para cinco sub-redes de plataforma dedicadas, incluindo gateway, firewall, Bastion e Servidor de Rota

Use esta tabela ao planejar seu espaço de endereço:

serviço Azure Tamanho mínimo da sub-rede Nome da sub-rede necessário Observações
Firewall do Azure /26 (59 IPs utilizáveis) AzureFirewallSubnet Obrigatório para todos os SKUs de firewall. Consulte Firewall do Azure design.
Gateway de VPN /27 (27 IPs utilizáveis) GatewaySubnet A Microsoft recomenda /27 ou superior para garantir margem para escalabilidade.
Azure Bastion /26 (59 IPs utilizáveis) AzureBastionSubnet Mínimo /26 para todas as implantações criadas após novembro de 2021.
Gateway de Aplicativo v2 /24 recomendado (251 IPs utilizáveis) Nenhum nome necessário Altamente recomendado /24 para acomodar o escalonamento automático. O mínimo é baseado em fórmula (instâncias + 5 IPs reservados + 1 IP de front-end privado).
Ambiente do Serviço de Aplicativo /24 (produção), /23 (escala máxima) Nenhum nome necessário O dimensionamento consome IPs da sub-rede. Use /23 se você planeja escalar próximo ao máximo de 200 instâncias.
Servidor de Rota do Azure /26 (59 IPs utilizáveis) RouteServerSubnet Necessário para a troca de rotas BGP com NVAs.
Resolvedor Privado de DNS do Azure /28 mínimo por sub-rede de ponto de extremidade Sub-redes dedicadas de entrada e saída Requer sub-redes separadas para endpoints de entrada e de saída. Não é possível compartilhar com outros recursos.
AKS (Serviço de Kubernetes do Azure) Baseado em fórmula (dependente de CNI) Nenhum nome necessário Consulte as diretrizes de dimensionamento do AKS.

Note

Os pontos de extremidade privados consomem endereços IP de sub-redes existentes. Eles não exigem uma sub-rede dedicada. Leve em consideração o consumo de IP ao dimensionar a sub-rede. Para obter um planejamento de IP detalhado, consulte o planejamento de endereço IP.

Dimensionamento de sub-rede do AKS

O dimensionamento da sub-rede do AKS depende da opção de plug-in CNI (Interface de Rede de Contêiner). Não há um único tamanho mínimo:

  • Sobreposição de CNI do Azure: a sub-rede só precisa acomodar nós, pois os pods usam um bloco CIDR (Classless Inter-Domain Routing) privado separado. Uma sub-rede significativamente menor é aceitável em comparação com a rede simples.
  • CNI do Azure (rede plana): a sub-rede deve acomodar nós E pods. Fórmula: (nodes + surge) × (max_pods + 1). Um /21 ou maior é comum para clusters com 50 ou mais nós.
  • Kubenet: somente os nós consomem IPs de sub-rede da VNet. Os pods obtêm endereços IP internos do cluster.

Para obter fórmulas de dimensionamento para cada opção de CNI, consulte Planejar o endereçamento IP do seu cluster AKS.

Restrições de emparelhamento de sub-rede

O emparelhamento de sub-rede conecta sub-redes específicas entre VNets em vez de espaços de endereço inteiros. Essa abordagem permite controle granular sobre quais sub-redes participam de relações de peering.

Importante

O emparelhamento de sub-redes está atualmente em versão preliminar e está sujeito às seguintes restrições:

  • Requer adicionar a assinatura a uma lista aprovada (não inscrição por autoatendimento)
  • Somente CLI, modelo do ARM, Terraform ou PowerShell (sem suporte do portal)
  • SKUs V5 baseados em Intel (ou SKUs baseados em AMD Genoa/Cobalt 100) são necessários para uso em produção a fim de evitar uma falha conhecida em SKUs de gerações anteriores: consulte Configurar o emparelhamento de sub-redes para consultar os requisitos atuais de hardware
  • Máximo de 200 sub-redes por lado por link de emparelhamento
  • Máximo de 1.000 sub-redes no total, considerando todos os links de emparelhamento, por rede virtual
  • As sub-redes devem pertencer a espaços de endereço exclusivos e não sobrepostos

Para informações sobre as limitações atuais e a inscrição, consulte Configurar o emparelhamento de sub-redes.

Note

O Gerenciador de Rede Virtual do Azure (AVNM) não consegue distinguir o emparelhamento de sub-rede do emparelhamento de VNet. Se você usar o AVNM para gerenciar configurações de emparelhamento, esteja ciente de que os relacionamentos de emparelhamento em nível de sub-rede aparecem como emparelhamento de VNet padrão no AVNM.

Considerações sobre o design

Foco no design de VNet e sub-redes com abordagem "lift-and-shift"

  • Recrie sua segmentação local: mapeie cada VLAN ou zona de segurança para uma sub-rede para que os limites de firewall existentes e a propriedade operacional sejam transferidos com o mínimo de reformulação.
  • Dimensionar sub-redes com margem de segurança. Como a renumeração de endereços IP após a migração causa interrupções, aloque blocos CIDR maiores do que o necessário para a quantidade atual de hosts, a fim de acomodar o crescimento e os cinco endereços reservados pelo Azure em cada sub-rede.
  • Mantenha os espaços de endereço do Azure alinhados com as faixas da rede local, sempre que possível, para simplificar o roteamento e evitar sobreposições ao se conectar por meio do Gateway de VPN ou do ExpressRoute.
  • Use por padrão uma VNet por aplicação migrada, com uma sub-rede por nível. Esse design espelha arquiteturas locais típicas de três camadas e torna a migração mais previsível.

Modernize a abordagem de projeto de VNet e sub-rede

  • Planeje as sub-redes com base primeiro nos serviços da plataforma: sub-redes dedicadas para Firewall do Azure, Application Gateway e Bastion, além de sub-redes dimensionadas corretamente para o AKS com base na opção de CNI escolhida.
  • Usar a Sobreposição de CNI do Azure para AKS para manter as sub-redes de nós pequenas, pois os pods utilizam um CIDR de overlay separado em vez do espaço de endereços da VNet.
  • Reserve uma sub-rede dedicada para pontos de extremidade particulares para que o consumo de IP permaneça previsível à medida que você adota mais serviços PaaS do Azure.
  • Adote o Gerenciador de Rede Virtual do Azure desde cedo para aplicar de forma consistente configurações de grupos de rede, conectividade e segurança à medida que o número de VNets aumenta em várias assinaturas.

Foco no design de VNet e sub-redes entre nuvens

  • Estabeleça um plano de endereço global antes de criar qualquer VNet. Reserve blocos CIDR não sobrepostos para Azure que não colidam com VPCs AWS existentes ou redes VPC do Google Cloud. Essa reserva é obrigatória para VPN roteada ou interconexão.
  • Mapeie os primitivos de rede de cada nuvem para Azure: uma rede VPC do AWS ou do Google Cloud VPC corresponde a uma VNet Azure e os grupos de segurança correspondem aos NSGs.
  • Reserve espaço na sub-rede para componentes de conectividade entre nuvens, como um GatewaySubnet para o Gateway de VPN ou o hub usado pelo WAN Virtual do Azure, para que a infraestrutura de trânsito tenha espaço para crescer.
  • Padronizar a nomenclatura e a marcação de sub-rede entre nuvens para que as equipes de operações possam correlacionar camadas equivalentes quando solucionarem problemas de tráfego multinuvem.

Pré-requisitos

Antes de projetar sua rede virtual e layout de sub-rede, verifique se você tem:

  • Azure assinatura: uma assinatura Azure ativa com permissões para criar recursos de rede (função Colaborador de Rede ou superior).
  • Grupo de recursos: um grupo de recursos em sua região de destino para conter recursos de VNet.
  • Decisão da região: escolha sua região de Azure primária com base na proximidade com usuários, requisitos de conformidade e disponibilidade do serviço.
  • Planejamento de espaço de endereços: defina um intervalo de endereços IP (bloco CIDR) que não se sobreponha às suas redes locais ou a outras VNets com as quais você pretende estabelecer emparelhamento. Consulte o planejamento de endereço IP para obter diretrizes.

Considerações de segurança

Redes virtuais e sub-redes são sua primeira camada de segmentação de rede. Aplique as seguintes práticas de segurança:

  • NSGs (grupos de segurança de rede): associe NSGs a cada sub-rede para filtrar o tráfego de entrada e saída. Defina regras de permissão específicas para a função de cada sub-rede e negue todo o resto por padrão. Para obter diretrizes detalhadas, consulte grupos de segurança de rede e grupos de segurança de aplicativos.
  • Túnel forçado com UDRs: se os requisitos de conformidade exigirem que todo o tráfego associado à Internet passe por um dispositivo de inspeção local ou um firewall de nuvem, use tabelas de rotas com rotas definidas pelo usuário para substituir o roteamento padrão da Internet. Consulte Conectividade de saída e de egresso.
  • Isolamento de sub-rede: coloque recursos com diferentes níveis de confiança em sub-redes separadas. Por exemplo, mantenha os bancos de dados em uma sub-rede que permita apenas o tráfego de entrada da sub-rede da camada de aplicativo. Essa separação limita o movimento lateral se um invasor comprometer um componente.
  • Sub-redes dedicadas para serviços de plataforma: muitos serviços de plataforma Azure (Firewall do Azure, Gateway de Aplicativo, Bastion) são implantados em sub-redes dedicadas. Esse isolamento garante que o roteamento de serviços de plataforma e as regras de segurança não interfiram com suas sub-redes de carga de trabalho.

Interação entre NSG e sub-rede

Quando você associa um NSG a uma sub-rede, as regras NSG se aplicam a todos os recursos nessa sub-rede. Entenda estes comportamentos de interação:

  • Avaliação cumulativa: se a NIC de uma VM também tiver um NSG, Azure avaliará o NSG no nível da sub-rede e o NSG no nível de NIC. Para o tráfego de entrada, o Azure avalia primeiro o NSG da sub-rede e, em seguida, o NSG da NIC. Para o tráfego de saída, o Azure avalia primeiro o NSG da NIC e depois o NSG da sub-rede.
  • Negação padrão: Azure inclui regras padrão que permitem o tráfego intra-VNet e o acesso à Internet de saída. Depois de adicionar regras de negação personalizadas, verifique se o tráfego legítimo (como as sondas de integridade do Azure Load Balancer provenientes do endereço IP 168.63.129.16) não está sendo bloqueado inadvertidamente.
  • Marcas de serviço e ASGs: use marcas de serviço (como AzureLoadBalancer, Internet, ) VirtualNetworke ASGs (grupos de segurança de aplicativos) em regras NSG em vez de endereços IP brutos. Essa abordagem simplifica o gerenciamento de regras e se adapta automaticamente à medida que os intervalos de IP Azure são alterados.
  • Logs de fluxo para visibilidade: habilite os logs de fluxo do NSG em cada NSG de nível de sub-rede para capturar o tráfego aceito e negado. Os logs de fluxo ajudam você a verificar se as regras de segurança funcionam conforme o esperado e fornecem evidências para auditorias de conformidade. Consulte os logs de fluxo do NSG para obter instruções de instalação.

Estes artigos no guia de design de rede do Azure abordam tópicos relacionados:

Saiba mais

Para obter mais informações sobre Azure rede virtual, consulte os seguintes recursos:

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

Próximo passo na sua jornada de migração:

Planeje seu espaço de endereço IP: aloque um pool de CIDR /16 que evite a sobreposição com seus intervalos de endereços locais.

A seguir, em sua jornada de modernização:

Planeje seu espaço de endereços IP: aloque pools de IP de região dupla com intervalos não sobrepostos para emparelhamento ativo-ativo.

A seguir, em sua jornada multinuvem:

Planeje seu espaço de endereço IP: projete endereçamentos não sobrepostos em Azure, Amazon Web Services (AWS) e Google Cloud.

  • Last updated on