Emparelhamento de VNets e Pontos de Extremidade de Serviço

Os recursos em diferentes VNets do Azure não podem se comunicar entre si por padrão — mesmo quando estão na mesma região do Azure. No entanto, organizações grandes costumam ter várias VNets: VNets separadas para desenvolvimento, preparação e produção, ou VNets diferentes para departamentos distintos. O emparelhamento de VNet conecta duas VNets diretamente pela rede de backbone privada da Microsoft, permitindo que os recursos de ambas se comuniquem como se estivessem na mesma rede — sem que o tráfego atravesse a internet pública ou exija um gateway de VPN.

O emparelhamento de VNet é uma conexão não transitiva: se a VNet A estiver emparelhada com a VNet B e a VNet B estiver emparelhada com a VNet C, a VNet A não poderá se comunicar com a VNet C, a menos que você crie um emparelhamento separado entre A e C. Os links de emparelhamento são bidirecionais, mas precisam ser configurados nos dois lados — criar um emparelhamento de A para B não cria automaticamente um de B para A. Depois que os dois lados forem configurados, o tráfego entre as VNets emparelhadas usará o backbone do Azure, com baixa latência e alta largura de banda, comparáveis às da comunicação entre sub-redes dentro de uma única VNet.

O emparelhamento de VNet oferece duas opções de escopo: o emparelhamento de VNet local conecta duas VNets na mesma região do Azure. O tráfego permanece dentro da região e está sujeito a uma pequena tarifa de transferência por GB. O emparelhamento de VNet global conecta duas VNets em regiões diferentes do Azure, com roteamento pela rede global da Microsoft. Isso permite que os recursos em East US se comuniquem de forma privada com recursos em West Europe sem passar pela internet pública. O emparelhamento global tem um custo de transferência um pouco maior que o emparelhamento local, mas ainda é significativamente mais barato e confiável do que rotear o tráfego por uma VPN.

Um padrão empresarial comum usa o emparelhamento de VNet para implementar uma topologia hub e spoke. Uma VNet central, o hub, hospeda serviços compartilhados: Azure Firewall, VPN Gateway, servidores DNS e monitoramento. Várias VNets spoke — uma por ambiente ou carga de trabalho — estabelecem emparelhamento com o hub. Ao rotear todo o tráfego dos spokes pelo firewall do hub, a organização obtém uma inspeção de segurança centralizada sem precisar gerenciar NSGs complexos em cada spoke. Como o emparelhamento não é transitivo, o firewall do hub roteia o tráfego entre os spokes usando UDRs (rotas definidas pelo usuário).

O emparelhamento de VNet tem um requisito fundamental: os espaços de endereçamento das VNets emparelhadas não podem se sobrepor. Se a VNet A usar 10.0.0.0/16 e a VNet B também usar 10.0.0.0/16, o emparelhamento falhará porque o Azure não poderá rotear o tráfego entre intervalos de endereços idênticos. Por isso, é tão importante planejar intervalos CIDR sem sobreposição para todas as VNets — e para as redes locais — antes de começar. Alterar o espaço de endereçamento de uma VNet depois que os recursos forem implantados exige recriar a VNet ou usar o recurso (limitado) de adicionar/remover espaço de endereçamento.

Os Service Endpoints estendem a identidade da VNet a serviços PaaS do Azure, como Azure Storage, Azure SQL Database, Azure Key Vault e Cosmos DB. Quando você habilita um Service Endpoint em uma sub-rede, o tráfego dos recursos dessa sub-rede para o serviço do Azure especificado é roteado pela rede de backbone do Azure, em vez de passar pela internet pública — mesmo que seja usado o endereço IP público do serviço. Assim, o serviço pode restringir o acesso apenas aos recursos dentro de VNets que tenham o Service Endpoint habilitado, proporcionando uma melhoria significativa de segurança em comparação com Endpoints acessíveis pela internet.

Service Endpoints e Private Endpoints oferecem acesso seguro aos serviços PaaS do Azure, mas funcionam de maneiras diferentes: Service Endpoint — roteia o tráfego pela rede de backbone do Azure, mas ainda usa o endereço IP público do serviço; o Service Endpoint existe no nível da sub-rede. Private Endpoint — atribui ao serviço um endereço IP privado da sua VNet; o Endpoint público pode ser totalmente desabilitado, tornando o serviço realmente privado. Private Endpoints oferecem um isolamento mais forte e também podem ser acessados a partir da rede local por VPN/ExpressRoute. Para obter o mais alto nível de segurança, prefira Private Endpoints; Service Endpoints são uma alternativa mais simples e de menor custo.

Depois de habilitar um Service Endpoint em uma sub-rede, você configura o serviço do Azure para aceitar conexões somente dessa sub-rede. Em uma conta de armazenamento, isso significa adicionar uma regra de VNet nas configurações do firewall da conta. Depois dessa alteração, somente as VMs na sub-rede especificada poderão acessar a conta de armazenamento — todo o restante do tráfego da internet será negado. Essa é uma maneira rápida e sem custo de melhorar significativamente a segurança da conta de armazenamento em comparação com deixá-la aberta a todo o tráfego da internet, especialmente no caso de contas que hospedam dados confidenciais de aplicativos.

A integração de VNet — diferente do emparelhamento de VNet — permite que aplicativos do Azure App Service façam chamadas de saída para recursos dentro de uma VNet. Sem a integração de VNet, o tráfego de saída de um App Service sempre sai pela internet pública — mesmo ao chamar recursos como Azure SQL ou Azure Cache for Redis na mesma VNet. Com a integração de VNet habilitada, o tráfego de saída do aplicativo é roteado para dentro da VNet e pode alcançar recursos privados. Isso exige uma sub-rede delegada dedicada na VNet com um espaço de endereçamento de pelo menos /28.

Como o emparelhamento de VNet não é transitivo, conectar mais de duas VNets exige emparelhamento direto entre cada par (complexidade O(n²)) ou um hub central de roteamento. Em um modelo hub e spoke, a VNet do hub contém uma Network Virtual Appliance (NVA) ou o Azure Firewall, que atua como um roteador de trânsito entre as VNets spoke. Cada spoke adiciona uma UDR que aponta todo o tráfego (0.0.0.0/0 ou CIDRs específicos dos spokes) para o IP da NVA no hub. A NVA então encaminha o tráfego para o spoke de destino correto, fornecendo efetivamente conectividade transitiva por meio do hub.

Principais limitações do emparelhamento de VNet: é obrigatório usar espaços de endereçamento sem sobreposição — planeje cuidadosamente os intervalos CIDR antes de criar as VNets. Não é transitivo — o emparelhamento A-B e B-C não conecta A-C. Não é possível redimensionar o espaço de endereçamento de uma VNet se ela tiver emparelhamentos ativos sem excluí-los temporariamente. Trânsito pelo gateway — as VNets spoke podem usar o gateway de VPN ou ExpressRoute na VNet do hub habilitando 'Usar Gateways Remotos' na configuração de emparelhamento, mas isso exige que o gateway do hub seja criado primeiro. Entender essas limitações é importante para projetar arquiteturas escaláveis e fáceis de manter com várias VNets.

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

Nesta lição, você aprendeu que: o emparelhamento de VNet conecta duas VNets pela rede de backbone da Microsoft para oferecer comunicação privada e de baixa latência sem uma VPN, mas o emparelhamento não é transitivo; os Service Endpoints roteiam o tráfego da sub-rede para serviços PaaS do Azure pela rede de backbone, sem expô-los à internet pública; e os Private Endpoints são a alternativa mais segura, pois atribuem um IP privado a um serviço PaaS, permitindo desabilitar completamente o Endpoint público. A seguir, exploraremos os fundamentos do Azure DNS e do Load Balancer.