Redes Virtuais e Sub-redes

Uma rede virtual do Azure (VNet) é uma rede logicamente isolada na nuvem do Azure que você define e controla. Ela é o componente fundamental da rede do Azure, permitindo que recursos do Azure, como máquinas virtuais, bancos de dados e serviços de aplicações, se comuniquem com segurança entre si, com a internet e com redes locais. Uma VNet está limitada a uma única região do Azure e a um espaço de endereços CIDR IPv4 específico (e, opcionalmente, IPv6), definido durante sua criação.

Ao criar uma VNet, você atribui um espaço de endereços usando a notação CIDR. A notação CIDR (Roteamento entre domínios sem classe) especifica tanto o endereço de rede quanto o número de bits usados no prefixo da rede. Por exemplo, 10.0.0.0/16 fornece 65.536 endereços IP (de 10.0.0.0 a 10.0.255.255). O espaço de endereços deve ser um intervalo de IP privado (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, conforme a RFC 1918). Escolha um espaço de endereços grande o suficiente para acomodar todas as sub-redes planejadas e permitir expansão, mas evite sobreposição com redes locais se você planejar uma conexão híbrida.

Uma sub-rede divide o espaço de endereços da VNet em segmentos de rede menores. Cada sub-rede tem seu próprio intervalo de IP (um subconjunto do espaço de endereços da VNet) e pode conter recursos de tipos diferentes. As sub-redes têm duas finalidades: organização (agrupar recursos relacionados) e isolamento (aplicar regras de segurança diferentes a grupos de recursos distintos). Por exemplo, você pode ter uma sub-rede web-tier (10.0.1.0/24) para servidores Web, uma sub-rede app-tier (10.0.2.0/24) para servidores de aplicações e uma sub-rede data-tier (10.0.3.0/24) para bancos de dados.

Dentro de cada sub-rede, o Azure reserva os quatro primeiros endereços IP e o último endereço IP para uso próprio. Em uma sub-rede 10.0.1.0/24: 10.0.1.0 (endereço de rede), 10.0.1.1 (gateway padrão), 10.0.1.2 e 10.0.1.3 (reservados para o DNS do Azure) e 10.0.1.255 (endereço de transmissão). Isso deixa 251 IPs utilizáveis em uma sub-rede /24. Considere essa reserva ao dimensionar as sub-redes: uma sub-rede /28 tem apenas 11 endereços utilizáveis (16 menos 5 reservados).

Por padrão, os recursos dentro da mesma VNet podem se comunicar usando seus endereços IP privados, mesmo que estejam em sub-redes diferentes. Nenhuma configuração adicional é necessária para a comunicação dentro da VNet. Recursos em VNets diferentes não podem se comunicar por padrão — você precisa conectá-los explicitamente usando o Emparelhamento de VNet. Os recursos na mesma sub-rede compartilham o mesmo segmento de rede, o que torna a comunicação entre eles o caminho mais direto possível dentro da camada de rede definida por software do Azure.

As VMs em uma VNet podem iniciar conexões de saída para a internet por padrão — o Azure fornece automaticamente acesso de saída à internet por meio de um serviço NAT gerenciado. Para o acesso de entrada pela internet, um recurso precisa de um endereço IP público atribuído à sua interface de rede ou ao balanceador de carga. Em seguida, você controla o acesso de entrada usando regras de Grupo de Segurança de Rede (NSG) para especificar exatamente quais portas e protocolos são permitidos. Uma arquitetura comum coloca servidores Web em uma sub-rede pública com IPs públicos e servidores de aplicações em uma sub-rede privada acessível somente a partir da camada Web.

Por padrão, o Azure gerencia o roteamento automaticamente: o tráfego entre sub-redes permanece dentro da VNet, o tráfego de saída para a internet passa por NAT e o tráfego para serviços do Azure usa a rede principal do Azure. Você pode substituir esse comportamento usando rotas definidas pelo usuário (UDRs) em uma tabela de rotas. Um uso comum é forçar todo o tráfego de saída para a internet a passar por um dispositivo virtual de rede (NVA) ou pelo Azure Firewall em uma VNet de hub, para inspeção centralizada. Você cria uma tabela de rotas, adiciona entradas de rota e associa a tabela a uma ou mais sub-redes para aplicá-la.

Alguns serviços do Azure — como o Serviço de Aplicativos do Azure (integração com VNet), o Serviço de Kubernetes do Azure, a Instância Gerenciada do Azure SQL e o Azure Databricks — exigem uma sub-rede dedicada delegada a esse serviço. Uma sub-rede delegada significa que o Azure pode inserir recursos específicos do serviço (interfaces de rede, endereços IP internos) nessa sub-rede em seu nome. Não é possível implantar outros tipos de recursos em uma sub-rede delegada — ela é reservada exclusivamente para esse serviço do Azure. Sempre aloque uma sub-rede dedicada com espaço de IP suficiente ao planejar o uso de serviços que exigem delegação.

Práticas recomendadas essenciais para o design de VNet: planeje seu espaço de endereços antes de criar a VNet — não é possível alterá-lo sem recriar os recursos. Use sub-redes separadas para cada camada do aplicativo, a fim de aplicar políticas de segurança distintas. Evite a sobreposição de espaços de endereços com redes locais se planeja conectar-se por VPN ou ExpressRoute. Reserve sub-redes maiores para serviços que precisam de escalabilidade (por exemplo, pools de nós do AKS). Dê nomes claros aos recursos (por exemplo, vnet-prod-eastus-001) para facilitar o gerenciamento em larga escala. Uma VNet bem projetada é muito mais fácil de proteger e solucionar problemas do que uma criada de forma improvisada.

As VNets do Azure podem ser conectadas a redes locais por meio de dois mecanismos: Gateway de VPN — um túnel IPsec/IKE criptografado pela internet pública, com boa relação custo-benefício para necessidades moderadas de largura de banda. Azure ExpressRoute — uma conexão privada e dedicada de fibra por meio de um parceiro provedor de rede, que oferece maior largura de banda, menor latência e desempenho mais previsível que a VPN. Para cargas de trabalho confidenciais ou cenários que exigem largura de banda garantida, o ExpressRoute é a opção preferencial, embora tenha um custo significativamente maior e prazos de provisionamento mais longos.

O dimensionamento do espaço de endereços de uma VNet exige planejamento das necessidades atuais e futuras. Um padrão comum em empresas é: espaço de endereços da VNet: /16 (65.536 endereços). Sub-redes: /24 por camada de carga de trabalho (251 endereços utilizáveis cada). Uma VNet /16 pode conter 256 sub-redes /24 — mais que o suficiente para a maioria dos ambientes. Para ambientes muito grandes, use /8 ou solicite vários intervalos sem sobreposição. Sempre deixe espaço para crescimento: alocar hoje uma /24 quando talvez você precise de uma /22 no próximo ano resultará em um trabalho trabalhoso de reendereçamento mais tarde.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que: uma VNet do Azure é uma rede logicamente isolada, com um espaço de endereços CIDR definido e restrita a uma única região; as sub-redes dividem a VNet em segmentos para organização e isolamento de políticas de segurança; e o Azure reserva 5 endereços IP por sub-rede, enquanto os recursos dentro da mesma VNet se comunicam de forma privada por padrão, sem configuração adicional. A seguir, exploraremos Grupos de Segurança de Rede e Grupos de Segurança de Aplicativos para filtragem de tráfego.