Fundamentação Teórica: Configure public IP addresses

1. Intuição Inicial

Dentro da sua VNet, todos os recursos têm endereços IP privados: números visíveis apenas dentro daquela rede. É como o ramal interno de uma empresa: o ramal 1234 funciona internamente, mas alguém de fora precisa ligar para o número externo da empresa para chegar até você.

Um endereço IP público no Azure é esse número externo: um endereço roteável na internet que permite que recursos fora da sua VNet (outros usuários na internet, parceiros, outros sistemas) cheguem ao seu recurso Azure. Sem um IP público, um recurso Azure é completamente inacessível de fora da sua rede privada.

A diferença fundamental em relação a um IP público tradicional (em um servidor físico seu): no Azure, o IP público é um recurso independente que pode ser criado, configurado, associado e desassociado de outros recursos separadamente. Você pode ter um IP público sem nenhum recurso associado a ele, e pode mover um IP público de um recurso para outro.

2. Contexto

O endereço IP público é o ponto de entrada para recursos Azure a partir da internet. Ele é consumido por vários tipos de recurso:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O IP público não é apenas sobre acesso de entrada (inbound). Ele também é necessário para alguns cenários de saída (outbound): quando uma VM precisa iniciar conexões para a internet, ela precisa de um IP público de saída. Esse IP pode ser o seu próprio IP público (se tiver um associado), o IP de um NAT Gateway da subnet, ou um IP efêmero atribuído automaticamente pelo Azure (SNAT).

3. Construção dos Conceitos

3.1 SKUs: Basic vs. Standard

Este é o conceito mais crítico sobre IPs públicos no Azure. Existem dois SKUs (níveis de serviço) com comportamentos completamente diferentes:

Característica	Basic	Standard
Método de alocação	Static ou Dynamic	Static apenas
Zonas de disponibilidade	Não suportado	Zone-redundant por padrão; pode ser zonal
Segurança padrão	Open por padrão (NSG opcional)	Fechado por padrão (NSG obrigatório para abrir)
Roteamento	Não determinístico	Roteamento Microsoft-preferred por padrão
Uso com Load Balancer	Apenas com LB Basic	Apenas com LB Standard
Uso com NAT Gateway	Não suportado	Suportado
Uso com Application Gateway v2	Não suportado	Obrigatório
Status futuro	Em processo de descontinuação	Recomendado para todos os cenários novos

Ponto crítico de segurança: um IP Basic associado a uma NIC de VM torna a VM acessível da internet por padrão em todas as portas, a menos que um NSG seja explicitamente configurado. Um IP Standard, pelo contrário, bloqueia todo o tráfego de entrada por padrão; você precisa de um NSG que explicitamente permita o tráfego desejado.

O SKU Basic está sendo descontinuado. A Microsoft anunciou o fim do suporte ao Basic em setembro de 2025. Use Standard em todos os cenários novos.

3.2 Métodos de Alocação

Dynamic (dinâmico): o endereço IP é atribuído quando o recurso associado é iniciado e liberado quando o recurso para. A cada reinicialização, o IP pode mudar. Disponível apenas no SKU Basic.

Static (estático): o endereço IP é atribuído no momento da criação do recurso de IP público e permanece o mesmo independentemente do estado do recurso associado. Mesmo que a VM seja desligada, o IP é mantido (e continua sendo cobrado). É o único método disponível no SKU Standard.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.3 Versão de IP: IPv4 e IPv6

O Azure suporta tanto IPv4 quanto IPv6 em IPs públicos. Para a maioria dos cenários, IPv4 é o padrão. IPv6 é suportado principalmente para:

Load Balancers (dual-stack)
VMs com dual-stack (IPv4 + IPv6 simultaneamente)
Application Gateway v2

Um recurso pode ter múltiplos IPs públicos: por exemplo, uma NIC pode ter configurações de IP adicionais, cada uma com seu próprio IP público.

3.4 DNS Name Label

Um IP público pode ter um DNS name label (rótulo DNS), que cria automaticamente um registro DNS no formato:

[label].[região].cloudapp.azure.com

Por exemplo, se você define o label meu-app em Brazil South, o FQDN gerado é:

meu-app.brazilsouth.cloudapp.azure.com

Esse FQDN aponta para o IP público e é útil para:

Acessar recursos por nome em vez de IP (especialmente com IPs dinâmicos que mudam)
Criar registros CNAME em domínios customizados apontando para o .cloudapp.azure.com
Obter certificados TLS para o domínio gerado

O label deve ser único dentro da região. Se meu-app já está em uso em Brazil South por outra conta, você precisará de um label diferente.

3.5 Zonas de Disponibilidade

IPs Standard podem ser configurados com diferentes modos de zona:

Modo	Descrição	Quando usar
Zone-redundant (padrão)	O IP é replicado em todas as zonas da região. Alta disponibilidade automática.	Produção, aplicações críticas
Zonal (ex: Zone 1)	O IP é fixado a uma zona específica. Útil para alinhar com recursos zonais.	Recursos zonais que precisam de IP alinhado à mesma zona
No zone	Sem associação de zona.	Regiões sem suporte a zonas; dev/test

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Fluxo de Tráfego de Entrada

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Azure realiza automaticamente um DNAT (Destination NAT): pacotes destinados ao IP público são automaticamente traduzidos para o IP privado da NIC associada. Do ponto de vista da VM, ela recebe tráfego no seu IP privado; ela nunca "vê" o IP público diretamente na sua interface de rede.

5. Funcionamento na Prática

Ciclo de Vida de um IP Público

Um IP público é um recurso Azure independente. Isso tem implicações práticas importantes:

Pode ser criado antes de ser associado a qualquer recurso
Pode ser desassociado de um recurso sem ser excluído
Pode ser reassociado a um recurso diferente
Continua sendo cobrado enquanto existir (mesmo sem associação), exceto em algumas situações específicas

Comportamento ao excluir uma VM: quando você exclui uma VM que tinha um IP público associado via NIC, o IP público não é automaticamente excluído junto. Ele permanece como recurso órfão na assinatura, sendo cobrado. É necessário excluí-lo manualmente (ou usar a opção de exclusão em cascata disponível no portal).

Interação com NAT Gateway

O NAT Gateway é o mecanismo moderno para controlar como VMs de uma subnet saem para a internet. Quando um NAT Gateway é associado a uma subnet e tem IPs públicos associados, todas as saídas de tráfego das VMs naquela subnet usam os IPs do NAT Gateway, de forma determinística.

Sem NAT Gateway, as VMs sem IP público próprio usam SNAT automático do Azure, que é não determinístico e pode esgotar as portas disponíveis em cenários de alta escala.

Prefixos de IP Público

Para cenários onde você precisa de múltiplos IPs públicos contíguos (mesmo bloco CIDR), o Azure oferece o recurso Public IP Prefix: um bloco reservado de IPs públicos consecutivos.

Exemplo: um prefixo /28 reserva 16 IPs públicos consecutivos como 40.100.0.0/28. Todos são de SKU Standard, estáticos, e podem ser atribuídos individualmente a diferentes recursos.

Benefício prático: você pode adicionar o range inteiro (40.100.0.0/28) a firewalls e listas de acesso de parceiros, e qualquer IP do prefix já está pré-autorizado.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: criação pontual, verificação de configurações, associação manual a recursos.

Caminho: Create a resource > Networking > Public IP address

Campos da criação:

IP Version: IPv4 ou IPv6
SKU: Basic ou Standard (escolha Standard)
Tier: Regional (padrão) ou Global (para Azure Front Door e Cross-Region Load Balancer)
Name: nome do recurso
IP address assignment: Static (para Standard é a única opção)
Availability zone: Zone-redundant, específica ou No zone
DNS name label: opcional, cria o FQDN .cloudapp.azure.com
Routing preference: Microsoft network (padrão, melhor desempenho) ou Internet (roteamento via ISP, pode ser mais barato para tráfego de saída)

6.2 Azure CLI

Criar IP público Standard, estático, zone-redundant:

az network public-ip create \
  --name pip-vm-frontend \
  --resource-group rg-networking \
  --location brazilsouth \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3 \
  --dns-name meu-app-frontend \
  --version IPv4

Criar IP público e associar a uma VM existente (via NIC):

# Obter o ID da NIC da VM
NIC_ID=$(az vm show \
  --name vm-frontend \
  --resource-group rg-producao \
  --query "networkProfile.networkInterfaces[0].id" -o tsv)

NIC_NAME=$(echo $NIC_ID | cut -d'/' -f9)
IP_CONFIG=$(az network nic ip-config list \
  --nic-name $NIC_NAME \
  --resource-group rg-producao \
  --query "[0].name" -o tsv)

# Associar o IP público à configuração de IP da NIC
az network nic ip-config update \
  --nic-name $NIC_NAME \
  --name $IP_CONFIG \
  --resource-group rg-producao \
  --public-ip-address pip-vm-frontend

Desassociar IP público de uma NIC sem excluí-lo:

az network nic ip-config update \
  --nic-name nic-vm-frontend \
  --name ipconfig1 \
  --resource-group rg-producao \
  --remove publicIpAddress

Listar IPs públicos e status de associação:

az network public-ip list \
  --resource-group rg-networking \
  --query "[].{Nome:name, IP:ipAddress, SKU:sku.name, Alocacao:publicIPAllocationMethod, Associado:ipConfiguration.id}" \
  --output table

Criar Public IP Prefix:

az network public-ip prefix create \
  --name pip-prefix-prod \
  --resource-group rg-networking \
  --location brazilsouth \
  --length 28 \
  --sku Standard \
  --zone 1 2 3

6.3 PowerShell

# Criar IP público Standard
$pip = New-AzPublicIpAddress `
  -Name "pip-vm-frontend" `
  -ResourceGroupName "rg-networking" `
  -Location "brazilsouth" `
  -Sku "Standard" `
  -AllocationMethod "Static" `
  -Zone @(1, 2, 3) `
  -DomainNameLabel "meu-app-frontend"

# Obter IP atribuído
Write-Output "IP atribuído: $($pip.IpAddress)"
Write-Output "FQDN: $($pip.DnsSettings.Fqdn)"

# Associar a uma NIC existente
$nic = Get-AzNetworkInterface -Name "nic-vm-frontend" -ResourceGroupName "rg-producao"
$nic.IpConfigurations[0].PublicIpAddress = $pip
Set-AzNetworkInterface -NetworkInterface $nic

6.4 Bicep

param location string = resourceGroup().location
param dnsLabel string = 'meu-app-${uniqueString(resourceGroup().id)}'

resource publicIp 'Microsoft.Network/publicIPAddresses@2023-05-01' = {
  name: 'pip-vm-frontend'
  location: location
  sku: {
    name: 'Standard'
    tier: 'Regional'
  }
  zones: ['1', '2', '3']
  properties: {
    publicIPAllocationMethod: 'Static'
    publicIPAddressVersion: 'IPv4'
    dnsSettings: {
      domainNameLabel: dnsLabel
    }
    idleTimeoutInMinutes: 4
  }
}

output ipAddress string = publicIp.properties.ipAddress
output fqdn string = publicIp.properties.dnsSettings.fqdn

7. Controle e Segurança

Comportamento de Segurança por SKU

O SKU determina o comportamento de segurança padrão, e essa diferença é crítica:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Consequência prática com Standard: quando você cria uma VM com IP Standard e tenta fazer SSH ou RDP, a conexão falha até que você configure um NSG com a regra de entrada adequada. Isso é comportamento esperado e correto; não é um bug.

IP Público vs. Azure Bastion para Acesso a VMs

Uma prática de segurança cada vez mais adotada é não associar IPs públicos diretamente a NICs de VMs. Em vez disso:

VMs ficam apenas com IPs privados
Acesso administrativo (SSH/RDP) é feito exclusivamente via Azure Bastion (que tem seu próprio IP público na AzureBastionSubnet)
Tráfego de aplicação chega via Load Balancer ou Application Gateway

Isso elimina a superfície de ataque direta nas VMs: não há porta exposta diretamente na internet.

Idle Timeout

IPs públicos têm uma configuração de idle timeout (padrão: 4 minutos, configurável até 30 minutos). Conexões TCP inativas por mais que esse tempo são encerradas pelo Azure. Para aplicações de longa duração (ex: conexões WebSocket, SSH persistente), configure o idle timeout adequadamente ou use TCP keepalive na aplicação.

8. Tomada de Decisão

Quando usar IP estático vs. dinâmico?

Situação	Escolha	Motivo
Qualquer uso com SKU Standard	Static (única opção)	Standard só suporta Static
DNS apontando para o IP	Static	DNS com IP dinâmico seria quebrado a cada reinicialização
Regras de firewall de parceiros	Static	Parceiros precisam de IP fixo para adicionar à allowlist
VM de desenvolvimento temporária	Dynamic (Basic)	Menor custo, IP não importa
Load Balancer, App Gateway, VPN Gateway	Static Standard	Obrigatório para esses serviços

Quando usar Public IP Prefix?

Situação	Usar prefix?	Motivo
Múltiplas VMs ou serviços que precisam de IPs contíguos	Sim	Range único para adicionar a firewalls
NAT Gateway com múltiplos IPs públicos	Sim	Melhor escalabilidade de portas SNAT
Apenas uma VM ou Load Balancer	Não	Overhead desnecessário
Necessidade de garantir adjacência de IPs para compliance	Sim	Prefix garante que todos estão no mesmo range

Qual Routing Preference escolher?

Opção	Descrição	Quando usar
Microsoft network (padrão)	Tráfego usa a rede backbone global da Microsoft pelo maior trecho possível. Menor latência, maior qualidade.	Produção, aplicações sensíveis a latência
Internet	Tráfego usa roteamento público da internet mais cedo. Pode reduzir custos de saída de dados.	Cenários onde custo de egress é prioritário sobre latência

9. Boas Práticas

Sempre use SKU Standard para novos recursos: o SKU Basic está sendo descontinuado. Usar Standard garante compatibilidade com Load Balancer Standard, Application Gateway v2, NAT Gateway e outros serviços modernos, além de comportamento de segurança mais adequado.

Evite IPs públicos diretamente em VMs de produção: use Load Balancer ou Application Gateway como ponto de entrada, e Azure Bastion para acesso administrativo. Isso reduz a superfície de ataque e centraliza o controle de tráfego.

Configure DNS name labels para recursos que precisam de nomes amigáveis: em vez de comunicar IPs que podem mudar durante manutenção ou reimplantação, use o FQDN do .cloudapp.azure.com ou aponte um CNAME do seu domínio para ele.

Use Public IP Prefix para NAT Gateways de alta escala: em subnets com muitas VMs fazendo conexões de saída para a internet, um NAT Gateway com IP Prefix aumenta o número de portas SNAT disponíveis e garante previsibilidade dos IPs de saída.

Nomeie recursos de IP público de forma associada ao recurso que usam: pip-agw-frontend-prod, pip-lb-api-brazilsouth, pip-vm-jumpbox tornam muito mais fácil identificar o propósito de cada IP e limpar IPs órfãos durante auditorias.

Audite IPs públicos órfãos regularmente: IPs sem associação continuam sendo cobrados. Uma varredura mensal identificando IPs sem ipConfiguration associada evita custos desnecessários.

10. Erros Comuns

Criar VMs com IP Basic e não configurar NSG

Uma VM com IP Basic fica acessível da internet em todas as portas por padrão. Um administrador cria uma VM de teste, esquece o NSG, e a VM fica com RDP ou SSH exposto globalmente. Em horas, tentativas de força bruta começam. Com IP Standard, isso não ocorre porque o tráfego é bloqueado por padrão.

Não excluir o IP público ao excluir a VM

O recurso de IP público sobrevive à exclusão da VM e continua sendo cobrado indefinidamente. Em assinaturas com muita rotatividade de VMs de desenvolvimento, isso pode gerar dezenas de IPs órfãos consumindo budget sem utilidade. Sempre use a opção de excluir recursos associados ao deletar uma VM no portal, ou verifique regularmente IPs sem associação.

Tentar associar IP Basic a um Load Balancer Standard (ou vice-versa)

SKUs de IP público e Load Balancer devem ser compatíveis: Basic com Basic, Standard com Standard. Tentar misturar gera um erro de criação. Em migrações de ambientes legados, é comum encontrar VMs com IPs Basic que precisam ser migradas para Standard antes de serem colocadas atrás de um Load Balancer Standard.

Usar IP dinâmico com DNS de parceiros ou certificados TLS

Um administrador configura um registro DNS apontando para o IP dinâmico de uma VM. A VM é reiniciada para manutenção, recebe um IP diferente, e o DNS aponta para o IP antigo que agora pertence a outra VM de outro cliente. Toda conexão usando aquele DNS falha. IPs dinâmicos nunca devem ser usados em entradas DNS externas.

Esquecer o idle timeout em conexões de longa duração

Uma aplicação mantém conexões WebSocket persistentes via um IP público. Após 4 minutos de inatividade (sem dados trafegando), o Azure encerra a conexão silenciosamente. A aplicação não percebe e continua tentando usar a conexão encerrada, resultando em erros de timeout no lado da aplicação. A solução é aumentar o idle timeout do IP público ou implementar TCP keepalive na aplicação.

11. Operação e Manutenção

Auditoria de IPs Públicos Órfãos

# Listar todos os IPs públicos sem associação
az network public-ip list \
  --query "[?ipConfiguration==null].{Nome:name, RG:resourceGroup, SKU:sku.name, IP:ipAddress}" \
  --output table

Verificar Uso de IP por Recurso

# Listar todos os IPs públicos com seus recursos associados
az network public-ip list \
  --query "[].{Nome:name, IP:ipAddress, SKU:sku.name, RecursoAssociado:ipConfiguration.id}" \
  --output table

Monitoramento de Métricas

IPs públicos têm métricas disponíveis no Azure Monitor:

Métrica	O que mede
ByteCount	Volume de bytes de entrada e saída
PacketCount	Número de pacotes processados
SynCount	Pacotes SYN recebidos (útil para detectar ataques SYN flood)
IfUnderDDoSAttack	Indicador de ataque DDoS em curso
DDoSTriggerTCPPackets	Pacotes TCP que dispararam mitigação DDoS

DDoS Protection

Por padrão, todos os IPs públicos no Azure têm proteção básica contra DDoS (DDoS Infrastructure Protection), que protege contra os ataques mais comuns sem custo adicional.

Para proteção avançada com SLAs, monitoramento dedicado e análise detalhada de ataques, existe o Azure DDoS Network Protection (pago, configurado na VNet) e o Azure DDoS IP Protection (pago, configurado por IP público individual).

Limites Importantes

Item	Limite padrão	Ajustável?
IPs públicos por assinatura	1.000	Sim, via suporte
IPs públicos por região	1.000 (compartilhado com o acima)	Sim
Prefixos de IP público por assinatura	200	Sim
Tamanho máximo de prefixo	`/28` (16 IPs) para IPv4	Não
Idle timeout máximo	30 minutos	Não

12. Integração e Automação

Associação Dinâmica de IPs em Pipelines

Em ambientes de CI/CD onde infraestrutura é criada e destruída frequentemente, o padrão recomendado é:

Criar o IP público como recurso separado com nome estável (ex: pip-app-prod)
O Load Balancer ou Application Gateway referencia o IP pelo ID
Em deploys, apenas os recursos de backend (VMs, VMSS) são recriados
O IP público permanece o mesmo, mantendo DNS e allowlists inalterados

Integração com Azure DNS

Para apontar um domínio customizado para um IP público do Azure via Azure DNS:

# Criar registro A no Azure DNS Zone
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name www \
  --ipv4-address $(az network public-ip show \
    --name pip-agw-frontend \
    --resource-group rg-networking \
    --query ipAddress -o tsv)

Para usar CNAME apontando para o DNS name label do IP (útil quando o IP pode mudar durante migrações):

az network dns record-set cname set-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name www \
  --cname meu-app.brazilsouth.cloudapp.azure.com

Automação de Limpeza de IPs Órfãos

# Script para identificar e remover IPs públicos órfãos
$orphanedIPs = Get-AzPublicIpAddress | Where-Object { $_.IpConfiguration -eq $null }

foreach ($ip in $orphanedIPs) {
    Write-Output "IP órfão encontrado: $($ip.Name) - $($ip.IpAddress)"
    # Descomentar para remover automaticamente:
    # Remove-AzPublicIpAddress -Name $ip.Name -ResourceGroupName $ip.ResourceGroupName -Force
}

Write-Output "Total de IPs órfãos: $($orphanedIPs.Count)"

13. Resumo Final

Pontos essenciais:

Um IP público no Azure é um recurso independente que pode existir sem estar associado a nenhum recurso. Pode ser criado, associado, desassociado e reusado separadamente.
Existem dois SKUs: Basic (legado, sendo descontinuado) e Standard (recomendado). Nunca use Basic em novos projetos.
Static mantém o mesmo IP independentemente do estado do recurso. Dynamic (apenas Basic) muda a cada reinicialização. SKU Standard só suporta Static.
O Azure faz DNAT automático: a VM nunca "vê" o IP público na sua interface; ela recebe tráfego no IP privado.

Diferenças críticas:

Basic: open por padrão (tráfego de entrada permitido sem NSG). Standard: closed por padrão (NSG obrigatório para permitir entrada).
IP Basic com Load Balancer Basic são compatíveis. IP Standard com Load Balancer Standard são compatíveis. Misturar SKUs gera erro.
DNS name label cria um FQDN no .cloudapp.azure.com mas não é um domínio customizado. Para domínio próprio, use Azure DNS com registro A ou CNAME apontando para o IP/FQDN.
Routing preference "Microsoft network" vs. "Internet": o primeiro prioriza o backbone privado da Microsoft (menor latência); o segundo pode reduzir custos de egress usando roteamento público mais cedo.

O que precisa ser lembrado:

IP público sem associação ainda é cobrado. Audite regularmente IPs órfãos.
Ao excluir uma VM, o IP público não é excluído automaticamente. É necessário excluir explicitamente.
SKU Basic está sendo descontinuado (setembro de 2025). Use Standard em todos os cenários novos.
Para acesso administrativo a VMs, prefira Azure Bastion em vez de IP público direto na NIC da VM.
O idle timeout padrão de 4 minutos pode causar problemas em conexões de longa duração. Ajuste conforme necessário.
Public IP Prefix é ideal para NAT Gateways e cenários que precisam de múltiplos IPs contíguos para allowlists de parceiros.
IPs Standard com zone-redundant garantem que o IP sobrevive a falhas de zona na região.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 SKUs: Basic vs. Standard​

3.2 Métodos de Alocação​

3.3 Versão de IP: IPv4 e IPv6​

3.4 DNS Name Label​

3.5 Zonas de Disponibilidade​

4. Visão Estrutural​

O Fluxo de Tráfego de Entrada​

5. Funcionamento na Prática​

Ciclo de Vida de um IP Público​

Interação com NAT Gateway​

Prefixos de IP Público​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Bicep​

7. Controle e Segurança​

Comportamento de Segurança por SKU​

IP Público vs. Azure Bastion para Acesso a VMs​

Idle Timeout​

8. Tomada de Decisão​

Quando usar IP estático vs. dinâmico?​

Quando usar Public IP Prefix?​

Qual Routing Preference escolher?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Auditoria de IPs Públicos Órfãos​

Verificar Uso de IP por Recurso​

Monitoramento de Métricas​

DDoS Protection​

Limites Importantes​

12. Integração e Automação​

Associação Dinâmica de IPs em Pipelines​

Integração com Azure DNS​

Automação de Limpeza de IPs Órfãos​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 SKUs: Basic vs. Standard

3.2 Métodos de Alocação

3.3 Versão de IP: IPv4 e IPv6

3.4 DNS Name Label

3.5 Zonas de Disponibilidade

4. Visão Estrutural

O Fluxo de Tráfego de Entrada

5. Funcionamento na Prática

Ciclo de Vida de um IP Público

Interação com NAT Gateway

Prefixos de IP Público

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell

6.4 Bicep

7. Controle e Segurança

Comportamento de Segurança por SKU

IP Público vs. Azure Bastion para Acesso a VMs

Idle Timeout

8. Tomada de Decisão

Quando usar IP estático vs. dinâmico?

Quando usar Public IP Prefix?

Qual Routing Preference escolher?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Auditoria de IPs Públicos Órfãos

Verificar Uso de IP por Recurso

Monitoramento de Métricas

DDoS Protection

Limites Importantes

12. Integração e Automação

Associação Dinâmica de IPs em Pipelines

Integração com Azure DNS

Automação de Limpeza de IPs Órfãos

13. Resumo Final