Redes e subredes virtuais Azure

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

O que este artigo aborda

Este artigo aborda limites de isolamento de VNet, dimensionamento de subredes e endereços reservados, subredes dedicadas de plataforma para serviços como Azure Firewall e Application Gateway, peering VNet e padrões comuns de layout de rede.

Quem precisa deste artigo

Leia este artigo se:

  • Estás a implementar a tua primeira carga de trabalho no Azure e precisas de perceber como funciona a rede antes de criares recursos.
  • Estão a planear um ambiente com múltiplas cargas de trabalho e precisam de decidir quantos VNets e sub-redes criar.
  • Estão a migrar cargas de trabalho on-premises para o Azure e precisam de perceber como a rede Azure difere da rede física.
  • É necessário dimensionar corretamente as subredes para serviços da plataforma Azure como Azure Firewall, Gateway de VPN ou Azure Kubernetes Service (AKS).
  • Quero perceber quando separar as cargas de trabalho em diferentes VNets versus mantê-las no mesmo VNet.

Foco em levantar e deslocar: Espelhe a segmentação da sua sub-rede local no Azure. Mapeie VLANs e zonas de segurança existentes para sub-redes, mantenha os espaços de endereçamento alinhados com os intervalos que a sua equipa já opera, e dimensione generosamente as subredes para não ter de reendereçar durante a migração.

Modernizar o foco: Projetar sub-redes em torno de serviços de plataforma e automação. Dimensione corretamente as sub-redes para o AKS, os pontos finais privados e os serviços de plataforma dedicados, e planeie a utilização do Azure Virtual Network Manager para aplicar uma configuração consistente em várias redes virtuais.

Foco multicloud: Planeie espaços de endereçamento não sobrepostos em Azure, AWS e Google Cloud antes de criar uma VNet. Reserve blocos CIDR que não entrem em conflito com VPCs existentes para poder ligar nuvens por peering ou VPN sem recorrer a NAT.

Serviços e funcionalidades do Azure

Os seguintes serviços e funcionalidades compõem a base das redes virtuais no Azure:

Serviço ou Característica O que oferece Quando usar
Rede Virtual do Azure (VNet) Uma rede privada e isolada no Azure. Toda a rede Azure começa aqui. Os recursos no mesmo VNet podem comunicar por defeito; recursos em diferentes VNets não podem comunicar a menos que os ligues explicitamente. Sempre: toda carga de trabalho que necessita de conectividade de rede requer um VNet.
Sub-rede Uma partição do espaço de endereçamento da VNet. As sub-redes são o âmbito de aplicação das associações de grupos de segurança de rede (NSG) e tabelas de rotas. Sempre: organizar os componentes da carga de trabalho em sub-redes por função ou limite de segurança.
Emparelhamento VNet Baixa latência, conectividade privada entre dois VNets na mesma região ou entre regiões. O tráfego permanece na rede principal da Microsoft. O peering não é transitivo; Cada peering é uma ligação direta. Quando os recursos em VNets separados precisam de comunicar. Para emparelhamento entre regiões, consulte Conectividade entre regiões.
Emparelhamento de sub-rede (pré-visualização) Emparelhamento entre sub-redes específicas em vez de VNets inteiras. Fornece controlo granular sobre quais sub-redes participam nas relações de peering. Quando precisas de controlo de peering detalhado entre sub-redes específicas em diferentes VNets. Veja a secção de restrições .
Tabela de rotas / Rotas Definidas pelo Utilizador (UDRs) Substituir as rotas de sistema predefinidas no Azure para controlar para onde é enviado o tráfego. Aplicado ao nível da sub-rede. Quando precisar de forçar o tráfego através de um firewall ou dispositivo virtual de rede (NVA). Necessária para o controlo do tráfego de saída em arquitetura hub-and-spoke. Veja estrutura do Azure Firewall e topologia hub-and-spoke.
Azure Virtual Network Manager (AVNM) Criar, gerir e aplicar, de forma centralizada, configurações de rede em VNets em várias subscrições. Ao gerir muitos VNets em múltiplas subscrições. Ver Gestão centralizada de rede.

Diagrama que mostra a VNet com sub-redes de cargas de trabalho para as camadas Web, de aplicação e de dados, bem como 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 por software no Azure. Pensa nisso como a tua rede privada no Azure. Ao contrário de uma rede física que utiliza cabos, switches e routers, um VNet é inteiramente definido por software. Cria-o, atribui-lhe um espaço de endereçamento e implementa recursos nele.

Principais características:

  • Region-scoped: Um VNet existe numa única região do Azure. Todos os recursos desse VNet devem estar na mesma região. Um VNet abrange zonas de disponibilidade dentro dessa região.
  • Isolamento por defeito: Os recursos de um VNet não podem comunicar com recursos de outro VNet a menos que crie explicitamente uma ligação (peering ou VPN).
  • Conectividade interna predefinida: Os recursos na mesma VNet podem comunicar entre si, por predefinição, através das rotas de sistema fornecidas pelo Azure.

O que é uma sub-rede?

Uma sub-rede é um conjunto de endereços IP dentro do seu VNet. As sub-redes permitem-lhe:

  • Segmente a sua rede por componente de carga de trabalho (por exemplo, nível web, nível de aplicação, nível de dados).
  • Aplique as regras de segurança: Os NSGs ligam-se ao nível da sub-rede para filtrar o tráfego.
  • Controlo do encaminhamento: as tabelas de encaminhamento são associadas ao nível da sub-rede para encaminhar o tráfego.

O Azure reserva cinco endereços IP em cada subrede: os primeiros quatro endereços e o último endereço. Por exemplo, numa sub-rede /24 (256 endereços), apenas 251 são utilizáveis. Tenha esta reserva em conta nos seus cálculos de dimensionamento.

Exemplo: Aplicação em três níveis

Uma aplicação web típica de três níveis utiliza três sub-redes para separar preocupações e aplicar regras de segurança distintas:

Sub-rede Gama 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 Application Gateway Azure Ambiente do Serviço de Aplicações, Conjuntos de Dimensionamento de Máquinas Virtuais com NGINX em execução
app-subnet 10.0.2.0/24 Lógica de aplicação de nível intermédio. Aceita tráfego apenas da sub-rede web. Funções do Azure (integradas na VNet), VMs que executam lógica de negócio
data-subnet 10.0.3.0/24 Armazenamentos de dados. Aceita apenas tráfego da sub-rede da aplicação. Sem acesso direto à internet. Azure SQL Managed Instance, pontos finais privados para Base de Dados SQL do Azure ou Cosmos DB

Este layout permite aplicar um NSG a cada sub-rede que restringe o tráfego apenas ao que esse nível precisa. A sub-rede web permite HTTPS de entrada (porta 443). A sub-rede da aplicação permite tráfego de entrada apenas a partir da faixa IP da sub-rede web. A sub-rede de dados permite apenas tráfego de entrada proveniente do intervalo de endereços IP da sub-rede da aplicação.

Para um padrão de modernização baseado em AKS, pode utilizar uma sub-rede aks-nodes, como 10.0.4.0/24, para os conjuntos de nós do cluster ao implementar o Azure CNI Overlay. Nesse modelo, apenas os nós consomem endereços IP VNet da sub-rede. Os pods utilizam um intervalo CIDR de sobreposição separado, o que permite manter a sub-rede do nó mais pequena do que numa arquitetura AKS de rede plana.

Padrões comuns

Os seguintes layouts de sub-redes cobrem os cenários de implementação do Azure mais comuns:

Padrão Subredes Quando utilizar
Aplicação web simples web + data Aplicações de dois níveis com interface e base de dados. Complexidade mínima.
Empresa de três níveis web + app + data + management Cargas de trabalho empresariais tradicionais com camadas distintas e um servidor de salto ou uma sub-rede de bastião para administração.
AKS com serviços partilhados aks-nodes + aks-ingress + appgw + shared Cargas de trabalho Kubernetes com uma sub-rede dedicada de controlador de entrada e um Gateway de Aplicações para WAF.
Saída de eixo por cubo e raio AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management O hub VNet numa topologia hub-and-spoke. Serviços partilhados que falavam VNets encaminham o tráfego. Ver topologia de hub-and-spoke.
Carga de trabalho de dados compute + data + private-endpoints + management Cargas de trabalho de análise e plataformas de dados em que os pontos finais privados para armazenamento e bases de dados necessitam da sua própria sub-rede para maior clareza no planeamento de endereços IP.

Quantos VNets e sub-redes?

O princípio orientador é simples: usar uma rede virtual por aplicação e uma sub-rede por componente (nível). Este padrão mantém cada carga de trabalho isolada, facilita o controlo do tráfego entre níveis com grupos de segurança de rede e deixa espaço para crescer. Ajusta a partir daí com base nos serviços partilhados, requisitos de isolamento e escala.

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

A sua situação Abordagem recomendada
Carga de trabalho única, equipa única, sem necessidade de serviços partilhados Um VNet com sub-redes por componente de aplicação (web, lógica de aplicação, dados). Ver Topologia de carga única.
Múltiplas cargas de trabalho independentes que partilham um gateway ou firewall Hub VNet para serviços partilhados + uma VNet spoke por cada carga de trabalho. Ver topologia de hub-and-spoke.
Isolamento rigoroso entre cargas de trabalho (raio de explosão, requisitos de conformidade) Uma VNet por carga de trabalho, sem emparelhamento entre as mesmas.
Ambiente muito grande com muitas subscrições e regiões WAN Virtual do Azure com gestão automatizada de hubs. Ver topologia WAN Virtual.

Referência dedicada para o dimensionamento de sub-redes

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

Diagrama mostrando tamanhos mínimos de sub-redes para cinco subredes dedicadas de plataforma, incluindo gateway, firewall, Bastion e Route Server

Use esta tabela ao planear o seu espaço de endereçamento:

Serviço do Azure Tamanho mínimo da sub-rede Nome da sub-rede obrigatória Notes
Azure Firewall /26 (59 IPs utilizáveis) AzureFirewallSubnet Obrigatório para todos os SKUs de firewall. Ver design do Azure Firewall.
Gateway de VPN /27 (27 IPs utilizáveis) GatewaySubnet A Microsoft recomenda /27 ou superior para permitir margem para expansão.
Azure Bastion /26 (59 IPs utilizáveis) AzureBastionSubnet Mínimo /26 para todas as implantações criadas após novembro de 2021.
Gateway de Aplicação v2 /24 recomendado (251 IPs utilizáveis) Sem nome obrigatório É altamente recomendada uma sub-rede /24 para suportar o dimensionamento automático. O mínimo é calculado com base na fórmula (instâncias + 5 endereços IP reservados + 1 IP privado de front-end).
Ambiente do Serviço de Aplicações /24 (produção), /23 (escala máxima) Sem nome obrigatório O dimensionamento consome endereços IP da sub-rede. Usa /23 se planeias escalar perto do máximo de 200 instâncias.
Azure Route Server /26 (59 IPs utilizáveis) RouteServerSubnet Necessário para a troca de rotas BGP com NVAs.
DNS do Azure Private Resolver /28 mínimo por sub-rede de pontos finais Sub-redes dedicadas de entrada e saída Requer sub-redes separadas para os endpoints de entrada e saída. Não posso partilhar com outros recursos.
AKS (Serviço Kubernetes do Azure) Baseado em fórmulas (dependente do CNI) Sem nome obrigatório Veja as orientações de dimensionamento do AKS.

Note

Os endpoints privados consomem endereços IP de sub-redes existentes. Eles não precisam de uma sub-rede dedicada. Considere este consumo de IP no tamanho da sua sub-rede. Para planeamento detalhado de IP, consulte planeamento de endereços IP.

Dimensionamento das subredes AKS

O dimensionamento da sub-rede AKS depende da escolha do seu plugin Container Networking Interface (CNI). Não existe um tamanho mínimo único:

  • Azure CNI Overlay: A sub-rede só precisa de alojar os nós, porque os pods utilizam um bloco CIDR privado (Classless Inter-Domain Routing) separado. Uma sub-rede significativamente menor é aceitável comparada com uma rede plana.
  • Azure CNI (rede plana): A sub-rede deve ter capacidade para os nós e os pods. Fórmula: (nodes + surge) × (max_pods + 1). Um /21 ou maior é comum para clusters com 50 ou mais nós.
  • Kubenet: Apenas os nós consomem IPs de sub-redes VNet. Os pods recebem endereços IP internos do cluster.

Para fórmulas de dimensionamento por opção de CNI, consulte Planear o endereçamento IP do seu cluster do AKS.

Restrições do peering de sub-redes

O peering de sub-redes estabelece a ligação entre sub-redes específicas de redes virtuais (VNets), em vez de espaços de endereços completos. Esta abordagem proporciona controlo granular sobre quais sub-redes participam nas relações de peering.

Importante

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

  • Requer a adição da subscrição a uma lista de aprovados (não autoinscrição)
  • CLI, template ARM, Terraform ou PowerShell apenas (sem suporte para portal)
  • São necessárias SKUs V5 baseadas em Intel (ou SKUs baseadas em AMD Genoa/Cobalt 100) para utilização em produção, de modo a evitar um erro conhecido em SKUs de gerações mais antigas: consulte Configurar peering de sub-redes para os requisitos de hardware atuais
  • Máximo de 200 sub-redes em cada lado de cada ligação de peering
  • Máximo de 1 000 sub-redes no total em todas as ligações de peering em cada VNet
  • As sub-redes devem pertencer a espaços de endereçamento únicos e não sobrepostos

Para conhecer as limitações atuais e a inscrição, veja Configurar o peering de sub-rede.

Note

O Azure Virtual Network Manager (AVNM) não consegue distinguir o emparelhamento de sub-rede do emparelhamento de VNet. Se utilizar o AVNM para gerir configurações de emparelhamento, tenha em atenção que as relações de emparelhamento de sub-rede aparecem como emparelhamento de VNet padrão no AVNM.

Considerações de design

Foco em design de VNet e sub-redes de elevação e deslocamento

  • Recrie a sua segmentação local: mapeie cada VLAN ou zona de segurança para uma sub-rede para que os limites existentes do firewall e a propriedade operacional sejam transferidos com o mínimo de redesenho.
  • Dimensione as sub-redes com margem de expansão. Renumerar endereços após a migração causa perturbações, por isso atribua intervalos CIDR maiores do que os necessários para o número atual de hosts, de modo a acomodar o crescimento e os cinco endereços reservados pelo Azure por sub-rede.
  • Mantenha os espaços de endereçamento do Azure alinhados com os intervalos locais, sempre que possível, para simplificar o encaminhamento e evitar sobreposições ao ligar através de Gateway de VPN ou ExpressRoute.
  • Utilize por predefinição uma VNet para cada aplicação migrada, com uma sub-rede por camada. Este design espelha os layouts típicos de três níveis no local e mantém a mudança previsível.

Modernizar VNet e foco no design de sub-redes

  • Projete primeiro as sub-redes em função dos serviços da plataforma: sub-redes dedicadas para o Azure Firewall, o Application Gateway e o Bastion, bem como sub-redes corretamente dimensionadas para o AKS, consoante a opção de CNI.
  • Use o Azure CNI Overlay para AKS para manter as subredes de nós pequenas, porque os pods extraem de um CIDR overlay separado em vez do espaço de endereçamento VNet.
  • Reserve uma sub-rede dedicada para endpoints privados para que o consumo de IP se mantenha previsível à medida que adota mais serviços PaaS do Azure.
  • Adote o Azure Virtual Network Manager cedo para aplicar grupos de rede, conectividade e configurações de segurança de forma consistente à medida que o número de VNets cresce entre as subscrições.

Foco na conceção de VNet e sub-redes multicloud

  • Estabeleça um plano global de endereços antes de criar qualquer VNet. Reserve blocos CIDR não sobrepostos para o Azure que não colidam com as VPCs AWS existentes ou as redes VPC do Google Cloud. Esta reserva é obrigatória para VPN encaminhada ou interligação.
  • Mapeie as primitivas de rede de cada nuvem para o Azure: uma rede VPC AWS ou Google Cloud VPC corresponde a um Azure VNet, e os grupos de segurança correspondem a NSGs.
  • Reserve espaço de sub-rede para componentes de conectividade cross-cloud, como um GatewaySubnet Gateway de VPN ou o hub usado pelo WAN Virtual do Azure, para que a infraestrutura de trânsito tenha espaço para escalar.
  • Padronize a nomeação e a etiquetagem das subredes entre clouds para que as equipas de operações possam correlacionar níveis equivalentes quando resolvem problemas no tráfego multicloud.

Pré-requisitos

Antes de desenhar o layout da sua rede virtual e sub-rede, certifique-se de que tem:

  • Subscrição Azure: Uma subscrição Azure ativa com permissões para criar recursos de rede (função de Network Contributor ou superior).
  • Grupo de recursos: Um grupo de recursos na sua região-alvo para conter recursos VNet.
  • Decisão da região: Escolha a sua região principal do Azure com base na proximidade aos utilizadores, requisitos de conformidade e disponibilidade de serviços.
  • Plano do espaço de endereçamento: Decida um intervalo de endereços IP (bloco CIDR) que não se sobreponha às suas redes no local nem a outras VNets que pretenda emparelhar. Consulte planeamento de endereços IP para orientações.

Considerações de segurança

Redes e subredes virtuais são a sua primeira camada de segmentação de rede. Aplicar as seguintes práticas de segurança:

  • Grupos de segurança de rede (NSGs): Associam 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 tudo o resto por defeito. Para orientações detalhadas, consulte Grupos de Segurança de Rede e Grupos de Segurança de Aplicações.
  • Tunelamento forçado com UDRs: Se os seus requisitos de conformidade exigem que todo o tráfego dirigido à internet passe por um dispositivo de inspeção local ou por um firewall na cloud, utilize tabelas de rotas com rotas definidas pelo utilizador para sobrepor o encaminhamento padrão da internet. Consulte Conectividade de saída e de egresso.
  • Isolamento de sub-redes: Coloque recursos com diferentes níveis de confiança em sub-redes separadas. Por exemplo, manter as bases de dados numa sub-rede que só permite tráfego de entrada da sub-rede do nível de aplicação. Esta separação limita o movimento lateral se um atacante comprometer um componente.
  • Subredes dedicadas para serviços de plataforma: Muitos serviços da plataforma Azure (Azure Firewall, Application Gateway, Bastion) são implementados em subredes dedicadas. Este isolamento garante que o encaminhamento de serviços da plataforma e as regras de segurança não interfiram com as sub-redes da sua carga de trabalho.

Interação entre NSG e sub-redes

Quando associas um NSG a uma sub-rede, as regras do NSG aplicam-se a todos os recursos dessa sub-rede. Compreenda estes comportamentos de interação:

  • Avaliação cumulativa: Se a NIC de uma VM também tiver um NSG, o Azure avalia tanto o NSG ao nível da subrede como o NSG ao nível da NIC. Para o tráfego de entrada, o Azure avalia primeiro o NSG da subrede e depois o NSG da NIC. Para o tráfego de saída, o Azure avalia primeiro o NSG da NIC, depois o NSG da subrede.
  • Negar por predefinição: O Azure inclui regras predefinidas que permitem tráfego dentro da VNet e acesso de saída à Internet. Depois de adicionares regras de negação personalizadas, verifica se o tráfego legítimo (como as sondas de saúde do Balanceador de Carga do Azure a partir do endereço IP 168.63.129.16) não está bloqueado inadvertidamente.
  • Etiquetas de serviço e ASGs: Use etiquetas de serviço (como AzureLoadBalancer, Internet, ) VirtualNetworke grupos de segurança de aplicações (ASGs) nas regras NSG em vez de endereços IP brutos. Esta abordagem simplifica a gestão de regras e adapta-se automaticamente à medida que os intervalos de IP do Azure mudam.
  • Registos de fluxo para visibilidade: Ative os registos de fluxo do NSG em cada NSG ao nível da sub-rede para capturar tráfego permitido e negado. Os registos de fluxo ajudam-no a verificar se as regras de segurança funcionam como previsto e fornecem evidências para auditorias de conformidade. Consulte os registos de fluxo NSG para instruções de configuração.

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

Saiba mais

Para mais informações sobre redes virtuais do Azure, consulte os seguintes recursos:

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Planifique o seu espaço de endereços IP: Aloque um bloco CIDR /16 que evite sobreposição com os seus intervalos de endereços no local.

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

Planeie o seu espaço de endereços IP: Aloque blocos de endereços IP de duas regiões com intervalos não sobrepostos para peering ativo-ativo.

A seguir na sua jornada através da cloud:

Planeie o seu espaço de endereços IP: Projete endereçamentos não sobrepostos entre Azure, Amazon Web Services (AWS) e Google Cloud.

  • Last updated on