Planejamento de endereço IP para redes virtuais Azure

Este artigo aborda o planejamento de endereço IP público e privado para implantações de Azure. Você aprenderá como alocar espaço de endereços, evitar sobreposições de intervalos, escolher o tipo de IP público correto e avaliar o suporte a pilha dupla IPv6.

O que este artigo aborda

Este artigo aborda estratégias de alocação de endereços privados, tipos e SKUs de IP público, planejamento de CIDR para evitar faixas sobrepostas, considerações sobre pilha dupla com IPv6 e Gerenciador de Endereços IP (IPAM) para ambientes em grande escala.

Quem precisa deste artigo

Leia este artigo se você:

  • Estão implantando uma VNet (rede virtual) em Azure e precisam decidir quais intervalos de endereços IP usar.
  • Estão conectando redes do Azure a ambientes locais e precisam evitar conflitos de endereços.
  • Você precisará escolher entre IPs públicos padrão, prefixos de IP público ou trazer seus próprios intervalos de IP (BYOIP).
  • Quer entender quando o IPv6 em dual stack é apropriado para suas cargas de trabalho.
  • Estão gerenciando um ambiente grande ou crescente e precisam de uma estratégia para acompanhar as alocações de IP em escala.

Foco em migração direta: escolha intervalos privados que não se sobreponham à sua rede local para que o roteamento VPN ou ExpressRoute funcione sem tradução. Reserve um grande bloco de zona de destino com espaço para as cargas de trabalho que você migrará nos próximos anos.

Foco em modernização: planeje espaço de endereços não sobrepostos em suas regiões primária e de backup para que as cargas de trabalho ativo-ativo possam se conectar posteriormente e reserve sub-redes com o tamanho correto para o Ambiente do Serviço de Aplicativos e o AKS.

Foco multinuvem: Crie um plano global de endereçamento que não entre em conflito com as faixas CIDR existentes de VPCs da AWS e do Google Cloud, o que é obrigatório antes de conectar as nuvens por VPN ou interconexão.

Azure serviços e recursos

Os seguintes serviços e recursos dão suporte ao planejamento de endereço IP no Azure:

Serviço ou recurso O que ele fornece Quando usar isso
Espaços de endereçamento privado da RFC 1918 Três intervalos reservados para uso privado: 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Azure VNets usam esses intervalos para comunicação interna. Sempre: cada VNet requer pelo menos um intervalo de endereços privados desses espaços.
Espaço de endereço compartilhado RFC 6598 100.64.0.0/10: tratado como espaço de endereço privado em Azure. Originalmente projetado para ambientes de NAT de nível de operadora (CGNAT). Quando sua organização já usa intervalos RFC 6598 localmente ou quando o espaço RFC 1918 estiver esgotado.
IP público padrão Um endereço IP público estático com redundância de zona atribuído a um único recurso. Seguro por padrão, com tráfego de entrada bloqueado. Quando um recurso precisa de um ponto de extremidade público exclusivo, como um balanceador de carga, um gateway de VPN ou uma máquina virtual voltada para o público.
Prefixo de IP público Um bloco contíguo reservado de endereços IP públicos de uma região de Azure específica. Quando você precisa de intervalos de IP previsíveis para o Gateway da NAT, Conjuntos de Dimensionamento de Máquinas Virtuais ou adicionar endereços IP externos a uma lista aprovada.
BYOIP / Prefixo IP personalizado Integre seus próprios intervalos de IP públicos para Azure. Usa um processo de três fases: validar a propriedade, provisionar o prefixo e, em seguida, comissioná-lo para uso. Quando você precisar preservar a reputação existente dos IPs, manter entradas em listas de permissões externas ou migrar cargas de trabalho sem alterar os IPs públicos.
AZURE VIRTUAL NETWORK MANAGER IPAM Um recurso interno de Gerenciamento de Endereços IP no Gerenciador de Rede Virtual do Azure. Geralmente disponível na maioria das regiões. Fornece visibilidade centralizada e rastreamento de alocação em todas as assinaturas. Ao gerenciar várias VNets em diversas assinaturas e precisar de rastreamento automatizado da utilização de endereços. Consulte o gerenciamento de rede centralizado.

Como escolher

Use as tabelas de decisão a seguir para orientar suas decisões de planejamento de IP.

Práticas recomendadas de planejamento de IP

Prática Por que Example
Alocar um CIDR pai grande (/16) e subdividir Evita o esgotamento de endereços à medida que as cargas de trabalho aumentam. Mais fácil resumir rotas. Atribua 10.1.0.0/16 ao ambiente de produção e, em seguida, esculpe /24 sub-redes para cada camada de carga de trabalho.
Deixe pelo menos 30% de folga em cada sub-rede Serviços de escalonamento, como Conjuntos de Dimensionamento de Máquinas Virtuais, AKS e Ambientes do Serviço de Aplicativo, consomem IPs rapidamente durante a expansão horizontal. Uma sub-rede /24 fornece 251 IPs utilizáveis. Se sua implantação de linha de base usa 100 IPs, você tem espaço para triplicar.
Usar blocos CIDR contíguos para cada ambiente Simplifica o resumo de rotas e as regras de firewall. Uma única rota de resumo representa todo o ambiente. Produção: 10.1.0.0/16. Staging: 10.2.0.0/16. Desenvolvimento: 10.3.0.0/16.
Evite os intervalos reservados pela plataforma e proibidos do Azure O uso de intervalos reservados causa falhas de roteamento e erros de implantação. Não atribua 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8 ou 255.255.255.255/32.
Alocações de documentos em Azure IPAM ou em uma planilha Impede a sobreposição à medida que o ambiente cresce. Centraliza a visibilidade das equipes de rede. Use Gerenciador de Rede Virtual do Azure IPAM para acompanhamento automatizado ou mantenha uma planilha compartilhada para ambientes menores.

Diagrama mostrando como um espaço de endereço de VNet é dividido em sub-redes dimensionadas para camadas de carga de trabalho e serviços de plataforma dedicados, como gateway, firewall e Bastion.

Tipos de endereço IP público

Tipo O que é Quando usar isso
IP público padrão Um IP público estático atribuído individualmente. Redundância de zona por padrão em regiões com zonas de disponibilidade habilitadas. Seguro por padrão: todo o tráfego de entrada é bloqueado até que uma regra de NSG ou balanceador de carga permita isso. Balanceadores de carga voltados para o público, Gateways de VPN, Azure Bastion, gateways de aplicativos ou qualquer recurso que precise de um ponto de extremidade público exclusivo.
Prefixo de IP público Um bloco contíguo reservado de IPs públicos de uma região específica. Garante endereços sequenciais. Gateway da NAT (requer prefixo para vários IPs de saída), Conjuntos de Dimensionamento de Máquinas Virtuais ou quando sistemas externos precisam adicionar a uma lista aprovada um intervalo previsível de IPs.
BYOIP / Prefixo IP personalizado Intervalos de IPs públicos de propriedade do cliente integrados ao Azure por meio de um processo de três fases: validação, provisionamento e comissionamento. Os prefixos regionais são provisionados em aproximadamente 30 minutos; os prefixos globais levam de 3 a 4 horas. Preservando a reputação de IP durante a migração na nuvem, mantendo entradas de lista aprovadas externas ou atendendo aos requisitos regulatórios de propriedade de IP. Os IPs derivados de um prefixo IP personalizado também podem usar Azure Proteção contra DDoS.

Note

Os IPs públicos da SKU básica foram desativados em 30 de setembro de 2025. Os IPs Básicos existentes continuam funcionando, mas não têm suporte e não têm SLA. Atualize para o SKU Standard para todas as novas implantações.

Decisão do IPv6

Scenario Recommendation Lógica
A carga de trabalho atende somente clientes IPv4, sem requisitos de IPv6 regulamentar Apenas IPv4 Configuração mais simples. Evita a sobrecarga de gerenciamento de pilha dupla. A maioria dos serviços Azure dá suporte ao IPv4 nativamente.
A carga de trabalho deve atender a clientes IPv6 ou os regulamentos exigem suporte para IPv6 Pilha dupla (IPv4 + IPv6) As VNets do Azure permitem sub-redes de pilha dupla. Implante o IPv6 junto com o IPv4 nos mesmos recursos.
A carga de trabalho precisa de IPv6, mas depende de Firewall do Azure, WAN Virtual ou servidor de rota Somente IPv4 (com terminação IPv6 externa) Firewall do Azure, WAN Virtual e Servidor de Rota não dão suporte atualmente ao IPv6. Termine o IPv6 em um balanceador de carga externo ou dispositivo de borda antes de o tráfego entrar nesses serviços. Gateway de VPN IPv6 está disponível na versão prévia.

Pilha dupla IPv6 no Azure

O Azure permite implantações de pilha dupla IPv6 em redes virtuais. Ao habilitar a pilha dupla, cada sub-rede recebe um intervalo IPv4 e um intervalo IPv6 /64. Os recursos recebem endereços de ambas as famílias e podem se comunicar simultaneamente por qualquer um dos protocolos.

O IPv6 no Azure tem requisitos de dimensionamento específicos. As sub-redes IPv6 devem ser exatamente /64. Não há suporte para nenhum outro comprimento de prefixo. O espaço de endereço IPv6 que você atribui a uma VNet deve ser grande o suficiente para acomodar sub-redes /64 para cada sub-rede que precise de conectividade IPv6. Planeje sua alocação de endereço IPv6 junto com seus intervalos IPv4 durante o design de rede inicial.

Os seguintes serviços do Azure oferecem suporte a configurações de pilha dupla com IPv6:

Service Suporte a IPv6
Rede Virtual do Azure Sub-redes de pilha dupla com intervalos IPv6 /64
Standard Load Balancer Front-ends IPv6 públicos e internos
Gateway de VPN Pontos de extremidade de túnel IPv6 (versão preliminar; requer ativação)
Gateway da NAT Tradução de saída IPv6 (somente SKU StandardV2; SKU Standard é somente IPv4)
IP público (SKU Padrão) Endereços públicos IPv6
Conjuntos de Dimensionamento de Máquinas Virtuais Interfaces de rede IPv6
Emparelhamento de VNet Tráfego IPv6 entre VNets emparelhadas
Grupos de segurança de rede Regras IPv6 para filtragem
DNS (DNS do Azure) Suporte a registro AAAA

Principais serviços que não dão suporte ao IPv6: Firewall do Azure (requer uma sub-rede somente IPv4), WAN Virtual (somente IPv4) e Servidor de Rota (somente IPv4). O Gateway de VPN permite IPv6 no modo de pilha dupla, mas apenas como um recurso de pré-visualização (requer ativação). Se sua arquitetura depender de Firewall do Azure, WAN Virtual ou Servidor de Rota para inspeção ou roteamento de tráfego, projete sua rede para que o tráfego IPv6 seja tratado antes de alcançar esses componentes.

Para obter recursos detalhados do IPv6, limitações e etapas de configuração, consulte IPv6 para Rede Virtual do Azure.

endereços reservados pelo Azure

Azure reserva cinco endereços IP em cada sub-rede:

Endereço reservado Purpose
Primeiro endereço (.0) Identificador de rede
Segundo endereço (.1) Gateway padrão
Terceiro endereço (.2) mapeamento de DNS do Azure
Quarto endereço (.3) mapeamento de DNS do Azure
Último endereço (broadcast) Endereço de difusão

Considere estes cinco endereços reservados em todos os cálculos de dimensionamento de sub-redes. Uma sub-rede /24 fornece 256 endereços totais menos 5 reservados, deixando 251 IPs de host utilizáveis. A menor sub-rede IPv4 com suporte é /29 (8 endereços menos 5 reservados = 3 utilizáveis). A maior sub-rede IPv4 com suporte é /2.

Tip

Os endereços IP públicos de SKU padrão incorrem em uma cobrança se estão ou não anexados a um recurso. Como parte da higiene de IP, exclua periodicamente os endereços IP públicos que você não usa mais e libere os prefixos IP públicos que você não utiliza mais. IPs públicos não anexados são uma fonte frequente de custo evitável e uma superfície de ataque desnecessária.

Considerações sobre o design

Foco do projeto de planejamento de IP "lift-and-shift"

  • Reserve um único bloco CIDR grande (um /16 é comum) para a zona de destino e subdivide-o para cada aplicativo migrado, deixando um buffer de aproximadamente 20% para crescimento.
  • Escolha intervalos que não se sobreponham a redes locais que você conecta por meio de Gateway de VPN ou ExpressRoute, portanto, o roteamento funciona sem tradução de endereço.
  • Contabilize os cinco endereços reservados de Azure por sub-rede e as sub-redes dedicadas que os serviços de plataforma exigem, como GatewaySubnet (/27) e AzureFirewallSubnet (/26).
  • Onde não há peering entre redes, você pode reutilizar deliberadamente intervalos IPv4 privados para economizar espaço de endereçamento.

Modernizar o foco no projeto de planejamento de IP

  • Aloque intervalos não sobrepostos em suas regiões primária e de backup para que as cargas de trabalho ativo-ativo possam usar o emparelhamento global posteriormente sem precisar reendereçar.
  • Reserve uma sub-rede dedicada dimensionada para o Ambiente do Serviço de Aplicativos (/24 ou /23 próximo à escala máxima). Para o AKS com sobreposição CNI, dimensione a sub-rede apenas para os nós, pois os pods utilizam um CIDR de sobreposição separado, o que torna a sub-rede do nó muito menor do que um design CNI plano exige.
  • Reserve uma sub-rede dedicada para pontos de extremidade privados para que a adoção de PaaS não fragmente seu plano de endereço.
  • Use o gerenciamento de endereços IP do Gerenciador de Rede Virtual do Azure para acompanhar e automatizar alocações à medida que seu ambiente cresce.

Foco do planejamento e design de IP entre nuvens

  • Estabeleça primeiro um plano global de endereçamento: reserve blocos CIDR do Azure que não se sobreponham às VPCs existentes da AWS nem às redes VPC existentes do Google Cloud, o que é necessário para VPN com roteamento ou interconexão.
  • Documente os intervalos de endereços de cada nuvem e branch conectados para que você possa planejar rotas resumidas por meio de WAN Virtual do Azure.
  • Reserve espaço de endereço para componentes de trânsito, como o hub WAN Virtual e as sub-redes do Gateway de VPN, com espaço para escalar à medida que você adiciona bordas e filiais na nuvem.
  • Quando as sobreposições forem inevitáveis, planeje aplicar NAT às conexões VPN afetadas ou reendereçar as cargas de trabalho durante a migração, em vez de depois.

Pré-requisitos

Antes de planejar a alocação de endereço IP:

  • Design de rede virtual: Você tem uma estrutura de VNet existente ou planejada. Se você ainda não projetou suas VNets, consulte primeiro Redes virtuais e sub-redes do Azure.
  • Inventário de IP local: Documente intervalos de endereços locais existentes, incluindo todos os intervalos usados por filiais, data centers ou outros provedores de nuvem. Endereços não sobrepostos são necessários para conectividade híbrida.
  • Projeções de crescimento: Estimar quantas sub-redes e hosts adicionais você precisará nos próximos 2 a 3 anos. Alocar espaço de endereço antecipadamente é mais fácil do que expandir uma VNet mais tarde.

Considerações de segurança

O planejamento de IP tem implicações diretas de segurança. Siga estas práticas para reduzir o risco:

  • Impedir sobreposição de endereço: Intervalos de IP sobrepostos entre redes locais, VNets Azure e VNets emparelhadas causam falhas de roteamento. O tráfego pode chegar ao destino errado ou ser removido silenciosamente. Verifique se cada intervalo de endereços é exclusivo em toda a sua rede.
  • Evite intervalos proibidos: Azure reserva os seguintes intervalos para operações de plataforma. Nunca os use como espaço de endereço da VNet:
    • 169.254.0.0/16 (link-local)
    • 168.63.129.16/32 (DNS interno do Azure)
    • 224.0.0.0/4 (multicast)
    • 127.0.0.0/8 (loopback)
    • 255.255.255.255/32 (difundido)
  • Documento e auditoria: Mantenha um registro atual de todas as alocações de IP. Intervalos não documentados levam à sobreposição acidental quando novas cargas de trabalho são implantadas. Use Gerenciador de Rede Virtual do Azure IPAM para controle de conformidade automatizado ou mantenha uma planilha compartilhada que é revisada durante cada implantação.
  • Proteja IPs públicos: Associe a Proteção contra DDoS do Azure aos recursos de IP público em ambientes de produção. Os intervalos BYOIP também podem ser protegidos pela Proteção contra DDoS.

Estes artigos abordam tópicos que interagem com o planejamento de endereços IP:

Saiba mais

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:

Proteja suas sub-redes com grupos de segurança de rede: Espelhe suas regras de firewall existentes como regras de NSG para manter sua postura de segurança no Azure.

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

Proteja suas sub-redes com grupos de segurança de rede: imponha uma segmentação estrita para que apenas o tráfego do balanceador de carga atinja suas sub-redes de aplicativo.

A seguir, em sua jornada multinuvem:

Proteja suas sub-redes com grupos de segurança de rede: Espelhe seus AWS Security Groups e as regras de firewall do Google Cloud como NSGs do Azure.

  • Last updated on