Theoretical Foundation: Configure public IP addresses

1. Initial Intuition

Within your VNet, all resources have private IP addresses: numbers visible only within that network. It's like an internal extension in a company: extension 1234 works internally, but someone from outside needs to call the company's external number to reach you.

A public IP address in Azure is that external number: an internet-routable address that allows resources outside your VNet (other users on the internet, partners, other systems) to reach your Azure resource. Without a public IP, an Azure resource is completely inaccessible from outside your private network.

The fundamental difference compared to a traditional public IP (on your physical server): in Azure, the public IP is an independent resource that can be created, configured, associated, and disassociated from other resources separately. You can have a public IP without any resource associated to it, and you can move a public IP from one resource to another.

2. Context

The public IP address is the entry point for Azure resources from the internet. It is consumed by various types of resources:

100%

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

The public IP is not just about inbound access. It's also necessary for some outbound scenarios: when a VM needs to initiate connections to the internet, it needs an outbound public IP. This IP can be its own public IP (if it has one associated), the IP of a NAT Gateway on the subnet, or an ephemeral IP automatically assigned by Azure (SNAT).

3. Building the Concepts

3.1 SKUs: Basic vs. Standard

This is the most critical concept about public IPs in Azure. There are two SKUs (service levels) with completely different behaviors:

Feature	Basic	Standard
Allocation method	Static or Dynamic	Static only
Availability zones	Not supported	Zone-redundant by default; can be zonal
Default security	Open by default (NSG optional)	Closed by default (NSG required to open)
Routing	Non-deterministic	Microsoft-preferred routing by default
Use with Load Balancer	Only with Basic LB	Only with Standard LB
Use with NAT Gateway	Not supported	Supported
Use with Application Gateway v2	Not supported	Required
Future status	Being deprecated	Recommended for all new scenarios

Critical security point: a Basic IP associated to a VM NIC makes the VM accessible from the internet by default on all ports, unless an NSG is explicitly configured. A Standard IP, on the contrary, blocks all inbound traffic by default; you need an NSG that explicitly allows the desired traffic.

The Basic SKU is being deprecated. Microsoft announced the end of support for Basic in September 2025. Use Standard in all new scenarios.

3.2 Allocation Methods

Dynamic: the IP address is assigned when the associated resource starts and released when the resource stops. With each reboot, the IP can change. Available only in Basic SKU.

Static: the IP address is assigned at the time of creating the public IP resource and remains the same regardless of the associated resource state. Even if the VM is turned off, the IP is maintained (and continues to be charged). It's the only method available in Standard SKU.

100%

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

3.3 IP Version: IPv4 and IPv6

Azure supports both IPv4 and IPv6 in public IPs. For most scenarios, IPv4 is the default. IPv6 is supported mainly for:

Load Balancers (dual-stack)
VMs with dual-stack (IPv4 + IPv6 simultaneously)
Application Gateway v2

A resource can have multiple public IPs: for example, a NIC can have additional IP configurations, each with its own public IP.

3.4 DNS Name Label

A public IP can have a DNS name label, which automatically creates a DNS record in the format:

[label].[region].cloudapp.azure.com

For example, if you define the label my-app in Brazil South, the generated FQDN is:

my-app.brazilsouth.cloudapp.azure.com

This FQDN points to the public IP and is useful for:

Accessing resources by name instead of IP (especially with dynamic IPs that change)
Creating CNAME records in custom domains pointing to .cloudapp.azure.com
Obtaining TLS certificates for the generated domain

The label must be unique within the region. If my-app is already in use in Brazil South by another account, you'll need a different label.

3.5 Availability Zones

Standard IPs can be configured with different zone modes:

Mode	Description	When to use
Zone-redundant (default)	The IP is replicated across all zones in the region. Automatic high availability.	Production, critical applications
Zonal (ex: Zone 1)	The IP is pinned to a specific zone. Useful for aligning with zonal resources.	Zonal resources that need IP aligned to the same zone
No zone	No zone association.	Regions without zone support; dev/test

4. Structural View

100%

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

The Inbound Traffic Flow

100%

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

Azure automatically performs **DNAT** (Destination NAT): packets destined to the public IP are automatically translated to the private IP of the associated NIC. From the VM's perspective, it receives traffic on its private IP; it never "sees" the public IP directly on its network interface.

---

## 5. Practical Operation

### Public IP Lifecycle

A public IP is an independent Azure resource. This has important practical implications:

- Can be created **before** being associated to any resource
- Can be **disassociated** from a resource without being deleted
- Can be **reassociated** to a different resource
- Continues being **charged** while it exists (even without association), except in some specific situations

**Behavior when deleting a VM**: when you delete a VM that had a public IP associated via NIC, the public IP is **not automatically deleted** along with it. It remains as an orphan resource in the subscription, being charged. It must be deleted manually (or use the cascade deletion option available in the portal).

### Interaction with NAT Gateway

The **NAT Gateway** is the modern mechanism to control how VMs in a subnet exit to the internet. When a NAT Gateway is associated to a subnet and has public IPs associated, all outbound traffic from VMs in that subnet use the NAT Gateway IPs, deterministically.

Without NAT Gateway, VMs without their own public IP use Azure's automatic SNAT, which is non-deterministic and can exhaust available ports in high-scale scenarios.

### Public IP Prefixes

For scenarios where you need **multiple contiguous public IPs** (same CIDR block), Azure offers the **Public IP Prefix** resource: a reserved block of consecutive public IPs.

Example: a `/28` prefix reserves 16 consecutive public IPs like `40.100.0.0/28`. All are Standard SKU, static, and can be assigned individually to different resources.

Practical benefit: you can add the entire range (`40.100.0.0/28`) to firewalls and partner access lists, and any IP from the prefix is already pre-authorized.

---

## 6. Implementation Methods

### 6.1 Azure Portal

**When to use**: one-off creation, configuration verification, manual association to resources.

**Path**: `Create a resource > Networking > Public IP address`

Creation fields:
- **IP Version**: IPv4 or IPv6
- **SKU**: Basic or Standard (choose Standard)
- **Tier**: Regional (default) or Global (for Azure Front Door and Cross-Region Load Balancer)
- **Name**: resource name
- **IP address assignment**: Static (for Standard it's the only option)
- **Availability zone**: Zone-redundant, specific or No zone
- **DNS name label**: optional, creates the `.cloudapp.azure.com` FQDN
- **Routing preference**: Microsoft network (default, better performance) or Internet (routing via ISP, can be cheaper for outbound traffic)

### 6.2 Azure CLI

Create Standard, static, zone-redundant public IP:

```bash
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 my-app-frontend \
  --version IPv4

Create public IP and associate to an existing VM (via NIC):

# Get the VM NIC ID
NIC_ID=$(az vm show \
  --name vm-frontend \
  --resource-group rg-production \
  --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-production \
  --query "[0].name" -o tsv)

# Associate the public IP to the NIC IP configuration
az network nic ip-config update \
  --nic-name $NIC_NAME \
  --name $IP_CONFIG \
  --resource-group rg-production \
  --public-ip-address pip-vm-frontend

Disassociate public IP from a NIC without deleting it:

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

List public IPs and association status:

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

Create 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

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

# Get assigned IP
Write-Output "Assigned IP: $($pip.IpAddress)"
Write-Output "FQDN: $($pip.DnsSettings.Fqdn)"

# Associate to an existing NIC
$nic = Get-AzNetworkInterface -Name "nic-vm-frontend" -ResourceGroupName "rg-production"
$nic.IpConfigurations[0].PublicIpAddress = $pip
Set-AzNetworkInterface -NetworkInterface $nic

6.4 Bicep

param location string = resourceGroup().location
param dnsLabel string = 'my-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. Control and Security

Security Behavior by SKU

The SKU determines the default security behavior, and this difference is critical:

100%

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

Practical consequence with Standard: when you create a VM with Standard IP and try to SSH or RDP, the connection fails until you configure an NSG with the appropriate inbound rule. This is expected and correct behavior; it's not a bug.

Public IP vs. Azure Bastion for VM Access

An increasingly adopted security practice is not associating public IPs directly to VM NICs. Instead:

VMs stay with private IPs only
Administrative access (SSH/RDP) is done exclusively via Azure Bastion (which has its own public IP in the AzureBastionSubnet)
Application traffic arrives via Load Balancer or Application Gateway

This eliminates the direct attack surface on VMs: there's no port exposed directly on the internet.

Idle Timeout

Public IPs have an idle timeout configuration (default: 4 minutes, configurable up to 30 minutes). TCP connections inactive for longer than this time are terminated by Azure. For long-duration applications (ex: WebSocket connections, persistent SSH), configure the idle timeout appropriately or use TCP keepalive in the application.

8. Decision Making

When to use static vs. dynamic IP?

Situation	Choice	Reason
Any use with Standard SKU	Static (only option)	Standard only supports Static
DNS pointing to the IP	Static	DNS with dynamic IP would break on every reboot
Partner firewall rules	Static	Partners need fixed IP to add to allowlist
Temporary development VM	Dynamic (Basic)	Lower cost, IP doesn't matter
Load Balancer, App Gateway, VPN Gateway	Static Standard	Required for these services

When to use Public IP Prefix?

Situation	Use prefix?	Reason
Multiple VMs or services that need contiguous IPs	Yes	Single range to add to firewalls
NAT Gateway with multiple public IPs	Yes	Better SNAT port scalability
Only one VM or Load Balancer	No	Unnecessary overhead
Need to guarantee IP adjacency for compliance	Yes	Prefix guarantees all are in the same range

Which Routing Preference to choose?

Option	Description	When to use
Microsoft network (default)	Traffic uses Microsoft's global backbone network for the longest stretch possible. Lower latency, higher quality.	Production, latency-sensitive applications
Internet	Traffic uses public internet routing earlier. May reduce data egress costs.	Scenarios where egress cost is prioritized over latency

9. Best Practices

Always use Standard SKU for new resources: the Basic SKU is being deprecated. Using Standard ensures compatibility with Standard Load Balancer, Application Gateway v2, NAT Gateway and other modern services, plus more appropriate security behavior. Avoid public IPs directly on production VMs: use Load Balancer or Application Gateway as entry point, and Azure Bastion for administrative access. This reduces the attack surface and centralizes traffic control.

Configure DNS name labels for resources that need friendly names: instead of communicating IPs that may change during maintenance or redeployment, use the FQDN from .cloudapp.azure.com or point a CNAME from your domain to it.

Use Public IP Prefix for high-scale NAT Gateways: in subnets with many VMs making outbound connections to the internet, a NAT Gateway with IP Prefix increases the number of available SNAT ports and ensures predictability of outbound IPs.

Name public IP resources in association with the resource they use: pip-agw-frontend-prod, pip-lb-api-brazilsouth, pip-vm-jumpbox make it much easier to identify the purpose of each IP and clean up orphaned IPs during audits.

Audit orphaned public IPs regularly: IPs without association continue to be charged. A monthly scan identifying IPs without associated ipConfiguration prevents unnecessary costs.

10. Common Errors

Creating VMs with Basic IP and not configuring NSG

A VM with Basic IP becomes accessible from the internet on all ports by default. An administrator creates a test VM, forgets the NSG, and the VM is left with RDP or SSH exposed globally. Within hours, brute force attempts begin. With Standard IP, this doesn't occur because traffic is blocked by default.

Not deleting the public IP when deleting the VM

The public IP resource survives VM deletion and continues to be charged indefinitely. In subscriptions with high turnover of development VMs, this can generate dozens of orphaned IPs consuming budget without utility. Always use the option to delete associated resources when deleting a VM in the portal, or regularly check IPs without association.

Trying to associate Basic IP to a Standard Load Balancer (or vice versa)

Public IP and Load Balancer SKUs must be compatible: Basic with Basic, Standard with Standard. Trying to mix generates a creation error. In migrations from legacy environments, it's common to find VMs with Basic IPs that need to be migrated to Standard before being placed behind a Standard Load Balancer.

Using dynamic IP with partner DNS or TLS certificates

An administrator configures a DNS record pointing to a VM's dynamic IP. The VM is restarted for maintenance, receives a different IP, and DNS points to the old IP that now belongs to another customer's VM. All connections using that DNS fail. Dynamic IPs should never be used in external DNS entries.

Forgetting idle timeout on long-duration connections

An application maintains persistent WebSocket connections via a public IP. After 4 minutes of inactivity (no data flowing), Azure silently terminates the connection. The application doesn't notice and continues trying to use the terminated connection, resulting in timeout errors on the application side. The solution is to increase the public IP's idle timeout or implement TCP keepalive in the application.

11. Operation and Maintenance

Orphaned Public IP Audit

# List all public IPs without association
az network public-ip list \
  --query "[?ipConfiguration==null].{Name:name, RG:resourceGroup, SKU:sku.name, IP:ipAddress}" \
  --output table

Check IP Usage by Resource

# List all public IPs with their associated resources
az network public-ip list \
  --query "[].{Name:name, IP:ipAddress, SKU:sku.name, AssociatedResource:ipConfiguration.id}" \
  --output table

Metrics Monitoring

Public IPs have metrics available in Azure Monitor:

Metric	What it measures
ByteCount	Volume of inbound and outbound bytes
PacketCount	Number of packets processed
SynCount	SYN packets received (useful for detecting SYN flood attacks)
IfUnderDDoSAttack	DDoS attack indicator in progress
DDoSTriggerTCPPackets	TCP packets that triggered DDoS mitigation

DDoS Protection

By default, all public IPs in Azure have basic DDoS protection (DDoS Infrastructure Protection), which protects against the most common attacks at no additional cost.

For advanced protection with SLAs, dedicated monitoring and detailed attack analysis, there's Azure DDoS Network Protection (paid, configured on VNet) and Azure DDoS IP Protection (paid, configured per individual public IP).

Important Limits

Item	Default limit	Adjustable?
Public IPs per subscription	1,000	Yes, via support
Public IPs per region	1,000 (shared with above)	Yes
Public IP prefixes per subscription	200	Yes
Maximum prefix size	`/28` (16 IPs) for IPv4	No
Maximum idle timeout	30 minutes	No

12. Integration and Automation

Dynamic IP Association in Pipelines

In CI/CD environments where infrastructure is created and destroyed frequently, the recommended pattern is:

Create the public IP as a separate resource with stable name (e.g., pip-app-prod)
The Load Balancer or Application Gateway references the IP by ID
In deployments, only backend resources (VMs, VMSS) are recreated
The public IP remains the same, keeping DNS and allowlists unchanged

Azure DNS Integration

To point a custom domain to an Azure public IP via Azure DNS:

# Create A record in 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)

To use CNAME pointing to the IP's DNS name label (useful when IP may change during migrations):

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

Orphaned IP Cleanup Automation

# Script to identify and remove orphaned public IPs
$orphanedIPs = Get-AzPublicIpAddress | Where-Object { $_.IpConfiguration -eq $null }

foreach ($ip in $orphanedIPs) {
    Write-Output "Orphaned IP found: $($ip.Name) - $($ip.IpAddress)"
    # Uncomment to automatically remove:
    # Remove-AzPublicIpAddress -Name $ip.Name -ResourceGroupName $ip.ResourceGroupName -Force
}

Write-Output "Total orphaned IPs: $($orphanedIPs.Count)"

13. Final Summary

Essential points:

A public IP in Azure is an independent resource that can exist without being associated with any resource. It can be created, associated, disassociated and reused separately.
There are two SKUs: Basic (legacy, being discontinued) and Standard (recommended). Never use Basic in new projects.
Static maintains the same IP regardless of resource state. Dynamic (Basic only) changes with each restart. Standard SKU only supports Static.
Azure performs automatic DNAT: the VM never "sees" the public IP on its interface; it receives traffic on the private IP.

Critical differences:

Basic: open by default (inbound traffic allowed without NSG). Standard: closed by default (NSG mandatory to allow inbound).
Basic IP with Basic Load Balancer are compatible. Standard IP with Standard Load Balancer are compatible. Mixing SKUs generates error.
DNS name label creates an FQDN on .cloudapp.azure.com but is not a custom domain. For your own domain, use Azure DNS with A record or CNAME pointing to the IP/FQDN.
Routing preference "Microsoft network" vs. "Internet": the former prioritizes Microsoft's private backbone (lower latency); the latter can reduce egress costs using public routing earlier.

What needs to be remembered:

Public IP without association is still charged. Audit orphaned IPs regularly.
When deleting a VM, the public IP is not automatically deleted. Explicit deletion is required.
Basic SKU is being discontinued (September 2025). Use Standard in all new scenarios.
For administrative access to VMs, prefer Azure Bastion instead of direct public IP on the VM's NIC.
The default idle timeout of 4 minutes can cause problems in long-duration connections. Adjust as needed.
Public IP Prefix is ideal for NAT Gateways and scenarios that need multiple contiguous IPs for partner allowlists.
Standard IPs with zone-redundant ensure the IP survives zone failures in the region.

1. Initial Intuition​

2. Context​

3. Building the Concepts​

3.1 SKUs: Basic vs. Standard​

3.2 Allocation Methods​

3.3 IP Version: IPv4 and IPv6​

3.4 DNS Name Label​

3.5 Availability Zones​

4. Structural View​

The Inbound Traffic Flow​

6.3 PowerShell​

6.4 Bicep​

7. Control and Security​

Security Behavior by SKU​

Public IP vs. Azure Bastion for VM Access​

Idle Timeout​

8. Decision Making​

When to use static vs. dynamic IP?​

When to use Public IP Prefix?​

Which Routing Preference to choose?​

9. Best Practices​

10. Common Errors​

11. Operation and Maintenance​

Orphaned Public IP Audit​

Check IP Usage by Resource​

Metrics Monitoring​

DDoS Protection​

Important Limits​

12. Integration and Automation​

Dynamic IP Association in Pipelines​

Azure DNS Integration​

Orphaned IP Cleanup Automation​

13. Final Summary​

1. Initial Intuition

2. Context

3. Building the Concepts

3.1 SKUs: Basic vs. Standard

3.2 Allocation Methods

3.3 IP Version: IPv4 and IPv6

3.4 DNS Name Label

3.5 Availability Zones

4. Structural View

The Inbound Traffic Flow

6.3 PowerShell

6.4 Bicep

7. Control and Security

Security Behavior by SKU

Public IP vs. Azure Bastion for VM Access

Idle Timeout

8. Decision Making

When to use static vs. dynamic IP?

When to use Public IP Prefix?

Which Routing Preference to choose?

9. Best Practices

10. Common Errors

11. Operation and Maintenance

Orphaned Public IP Audit

Check IP Usage by Resource

Metrics Monitoring

DDoS Protection

Important Limits

12. Integration and Automation

Dynamic IP Association in Pipelines

Azure DNS Integration

Orphaned IP Cleanup Automation

13. Final Summary