🌐 Azure Public IP Address Infrastructure Guide

📋 Table of Contents

Overview of Azure Public IP Addresses
Public IP Address Prefixes
Custom Public IP Address Prefix (BYOIP)
Creating Public IP Addresses
Associating Public IP Addresses
Upgrading IP Address SKU
Implementation Flow
Troubleshooting

🔍 Overview of Azure Public IP Addresses

graph TB A[Internet] --> B[Azure Public IP] B --> C[Load Balancer] B --> D[Virtual Machine] B --> E[Application Gateway] B --> F[NAT Gateway] C --> G[Backend Pool VM1] C --> H[Backend Pool VM2] D --> I[Private IP: 10.0.1.4] G --> J[Private IP: 10.0.2.4] H --> K[Private IP: 10.0.2.5] style A fill:#ff9999 style B fill:#99ccff style C fill:#99ff99 style D fill:#99ff99 style E fill:#99ff99 style F fill:#99ff99

Traffic Flow Explanation:

This diagram shows how Azure Public IP addresses serve as the entry point from the internet to Azure resources. The public IP acts as a gateway that can be associated with various Azure services including Load Balancers, Virtual Machines, Application Gateways, and NAT Gateways. Each service then routes traffic to private IP addresses within the Azure virtual network, providing a secure boundary between public internet and private resources.

🎯 Public IP Address Prefixes

Understanding Public IP Prefixes

A public IP address prefix is a reserved range of contiguous public IP addresses. Instead of creating individual public IP addresses, you can reserve a block of addresses that are guaranteed to be sequential.

graph LR A[Public IP Prefix
40.112.0.0/28] --> B[40.112.0.1] A --> C[40.112.0.2] A --> D[40.112.0.3] A --> E[...] A --> F[40.112.0.14] B --> G[VM-Web01] C --> H[VM-Web02] D --> I[Load Balancer] F --> J[NAT Gateway] style A fill:#ffcc99 style B fill:#99ccff style C fill:#99ccff style D fill:#99ccff style F fill:#99ccff

Public IP Prefix Benefits:

This diagram illustrates how a single public IP prefix provides multiple sequential IP addresses. The /28 prefix provides 16 addresses (14 usable for resources, 2 reserved by Azure). This approach simplifies firewall rules, DNS management, and provides cost benefits when you need multiple public IP addresses.

When to Use Public IP Prefixes

Use Cases for Public IP Prefixes:

Multiple Resources: When you need 4 or more public IP addresses
Firewall Rules: Simplify external firewall configurations with IP ranges
DNS Management: Easier to manage DNS records with sequential IPs
Cost Optimization: More cost-effective for multiple IPs
Compliance: When regulatory requirements need IP range documentation

Creating a Public IP Prefix

Step 1: Create Resource Group

az group create \ --name rg-publicip-demo \ --location eastus \ --tags Environment=Demo Project=PublicIP-Guide

Resource Group Parameters:

Parameter	Description	Options
--name	Resource group name	Must be unique within subscription
--location	Azure region	eastus, westus2, centralus, etc.
--tags	Metadata tags	Key=Value pairs for organization

Why This Comes First: The resource group acts as a logical container for all related resources. It must be created before any other resources and determines the region where resources will be deployed.

Step 2: Create Public IP Prefix

az network public-ip prefix create \ --resource-group rg-publicip-demo \ --name pip-prefix-demo \ --length 28 \ --location eastus \ --sku Standard \ --zone 1 2 3 \ --tags Environment=Demo Purpose=WebServers

Public IP Prefix Parameters:

Parameter	Description	Options
--length	Prefix length (CIDR)	28 (16 IPs), 29 (8 IPs), 30 (4 IPs), 31 (2 IPs)
--sku	SKU type	Standard (recommended), Basic
--zone	Availability zones	1, 2, 3 (zone-redundant when multiple specified)

Configuration Details: The /28 prefix provides 16 IP addresses (14 usable). Standard SKU is required for zone-redundancy and advanced features. Availability zones ensure high availability across multiple data centers.

Step 3: Verify Prefix Creation

az network public-ip prefix show \ --resource-group rg-publicip-demo \ --name pip-prefix-demo \ --query "{Name:name, IPPrefix:ipPrefix, PublicIPAddresses:publicIpAddresses}" \ --output table

Verification Purpose: This command confirms the prefix was created successfully and displays the allocated IP range. The query parameter filters output to show only relevant information in a readable table format.

🏗️ Custom Public IP Address Prefix (Bring Your Own IP)

sequenceDiagram participant O as Organization participant RIR as Regional Internet Registry participant A as Azure participant I as Internet O->>RIR: Request IP Block Allocation RIR->>O: Allocate IP Block (e.g., 203.0.113.0/24) O->>A: Create Custom IP Prefix A->>RIR: Validate Ownership via ROA RIR->>A: Confirm Ownership A->>I: Advertise Custom IP Range I->>A: Route Traffic to Custom IPs A->>O: Custom IPs Available for Use

BYOIP (Bring Your Own IP) Process:

This sequence diagram shows the complete process of implementing a custom public IP prefix. Organizations must first obtain IP allocation from a Regional Internet Registry (RIR), then work with Azure to validate ownership through Route Origin Authorization (ROA). Once validated, Azure can advertise these custom IP ranges and route traffic accordingly.

Prerequisites for Custom IP Prefix

Requirements:

IP allocation from RIR (ARIN, RIPE, APNIC, etc.)
Route Origin Authorization (ROA) configured
Certificate of IP allocation
Azure subscription with appropriate permissions
Minimum /24 prefix size (256 IP addresses)

Step 1: Prepare ROA Certificate

# Create ROA (Route Origin Authorization) - This is done at RIR level # Example for ARIN (American Registry for Internet Numbers) # ROA Configuration: # - IP Prefix: 203.0.113.0/24 # - Max Length: 24 # - Origin AS: 8075 (Microsoft Azure ASN) # - Valid From: Current Date # - Valid To: Future Date (typically 1 year)

ROA Purpose: Route Origin Authorization is a cryptographic certificate that proves ownership of an IP prefix and authorizes specific Autonomous Systems (AS) to advertise it. For Azure, you must authorize ASN 8075 to advertise your custom IP range.

Step 2: Create Custom IP Prefix

az network custom-ip prefix create \ --resource-group rg-publicip-demo \ --name custom-prefix-demo \ --location eastus \ --cidr 203.0.113.0/24 \ --authorization-message "Azure Custom IP Prefix for Organization XYZ" \ --signed-message "base64-encoded-certificate-content" \ --zone 1 2 3

Custom IP Prefix Parameters:

Parameter	Description	Requirements
--cidr	Your allocated IP range	Minimum /24, must match ROA
--authorization-message	Ownership proof text	Must match RIR documentation
--signed-message	Certificate content	Base64-encoded ROA certificate

Validation Process: Azure validates the ROA certificate against RIR databases. This process can take 24-48 hours. The custom prefix remains in "Pending" state until validation completes.

Step 3: Commission Custom Prefix

# Check validation status az network custom-ip prefix show \ --resource-group rg-publicip-demo \ --name custom-prefix-demo \ --query "provisioningState" \ --output tsv # Commission the prefix (start advertising) az network custom-ip prefix update \ --resource-group rg-publicip-demo \ --name custom-prefix-demo \ --state commission

Commissioning Process: Once validated, the custom prefix must be commissioned to start advertising routes. This process typically takes 15-30 minutes. The prefix state changes from "Provisioned" to "Commissioned" when active.

graph TB A[Custom IP Prefix
203.0.113.0/24] --> B[Child Prefix 1
203.0.113.0/26] A --> C[Child Prefix 2
203.0.113.64/26] A --> D[Child Prefix 3
203.0.113.128/26] A --> E[Child Prefix 4
203.0.113.192/26] B --> F[Public IP 1
203.0.113.1] B --> G[Public IP 2
203.0.113.2] C --> H[Public IP 3
203.0.113.65] D --> I[Load Balancer
203.0.113.129] style A fill:#ff9999 style B fill:#ffcc99 style C fill:#ffcc99 style D fill:#ffcc99 style E fill:#ffcc99

Custom IP Prefix Subdivision:

This diagram shows how a custom /24 prefix can be subdivided into smaller /26 prefixes for better organization. Each child prefix can contain up to 64 IP addresses (62 usable). This hierarchical approach allows for better resource management and security segmentation.

🌐 Creating Public IP Addresses

graph LR A[Public IP Creation] --> B{SKU Type} B -->|Basic| C[Basic SKU Features] B -->|Standard| D[Standard SKU Features] C --> E[Dynamic/Static Allocation] C --> F[No Zone Support] C --> G[Basic Load Balancer Only] D --> H[Static Allocation Only] D --> I[Zone Redundant] D --> J[Standard Load Balancer] D --> K[Network Security Groups] style A fill:#99ccff style B fill:#ffcc99 style C fill:#ffcccc style D fill:#ccffcc

SKU Comparison:

This diagram illustrates the key differences between Basic and Standard SKU public IP addresses. Standard SKU provides enhanced security, availability, and features but requires static allocation. Basic SKU offers flexibility in allocation methods but lacks advanced features like availability zones and network security group support.

Creating Standard Public IP Address

Step 1: Create Standalone Public IP

az network public-ip create \ --resource-group rg-publicip-demo \ --name pip-web-server \ --location eastus \ --sku Standard \ --allocation-method Static \ --version IPv4 \ --zone 1 2 3 \ --dns-name web-server-demo-12345 \ --tags Environment=Production Tier=Web

Public IP Parameters:

Parameter	Description	Options
--allocation-method	IP assignment type	Static (recommended), Dynamic
--version	IP version	IPv4, IPv6
--dns-name	DNS label	Must be globally unique
--zone	Availability zones	1, 2, 3 (zone-redundant)

Static vs Dynamic: Static allocation reserves the IP address permanently, while Dynamic allocation may change when the resource is deallocated. Standard SKU only supports Static allocation.

Step 2: Create Public IP from Prefix

az network public-ip create \ --resource-group rg-publicip-demo \ --name pip-from-prefix \ --location eastus \ --sku Standard \ --allocation-method Static \ --public-ip-prefix pip-prefix-demo \ --tags Environment=Production Source=Prefix

Prefix-based Creation: When using --public-ip-prefix, Azure automatically assigns an available IP from the specified prefix. This ensures the IP address is within your reserved range and simplifies management of multiple related resources.

Step 3: Verify Public IP Creation

az network public-ip list \ --resource-group rg-publicip-demo \ --query "[].{Name:name, IP:ipAddress, SKU:sku.name, State:provisioningState}" \ --output table

Verification Output: This command displays all public IP addresses in the resource group with their current IP assignments, SKU types, and provisioning states. Use this to confirm successful creation and note the assigned IP addresses.

🔗 Associating Public IP Addresses to Resources

graph TB A[Public IP Address] --> B{Resource Type} B -->|Virtual Machine| C[NIC Association] B -->|Load Balancer| D[Frontend IP Config] B -->|Application Gateway| E[Frontend IP Config] B -->|NAT Gateway| F[Direct Association] B -->|Bastion Host| G[Direct Association] C --> H[VM Network Interface] D --> I[Load Balancer Frontend] E --> J[App Gateway Frontend] F --> K[NAT Gateway Resource] G --> L[Bastion Host Resource] H --> M[Virtual Machine] I --> N[Backend Pool] J --> O[Backend Pool] K --> P[Subnet Association] L --> Q[Subnet Association] style A fill:#99ccff style B fill:#ffcc99 style C fill:#ccffcc style D fill:#ccffcc style E fill:#ccffcc style F fill:#ccffcc style G fill:#ccffcc

Public IP Association Methods:

This diagram shows the different ways public IP addresses can be associated with Azure resources. Each resource type has specific association methods: VMs use Network Interface Cards (NICs), Load Balancers and Application Gateways use Frontend IP configurations, while NAT Gateways and Bastion Hosts support direct association.

Virtual Machine Association

Step 1: Create Virtual Network

az network vnet create \ --resource-group rg-publicip-demo \ --name vnet-demo \ --address-prefix 10.0.0.0/16 \ --location eastus \ --subnet-name subnet-web \ --subnet-prefix 10.0.1.0/24

Virtual Network Parameters:

Parameter	Description	Best Practices
--address-prefix	VNet IP range	Use RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
--subnet-prefix	Subnet IP range	Leave room for additional subnets

Network Foundation: The virtual network provides the private IP space for your resources. The subnet defines where VMs will be placed. Always plan IP addressing carefully to avoid conflicts and allow for future growth.

Step 2: Create Network Security Group

az network nsg create \ --resource-group rg-publicip-demo \ --name nsg-web-servers \ --location eastus

az network nsg rule create \ --resource-group rg-publicip-demo \ --nsg-name nsg-web-servers \ --name Allow-HTTP \ --protocol Tcp \ --direction Inbound \ --priority 1000 \ --source-address-prefix Internet \ --source-port-range "*" \ --destination-address-prefix "*" \ --destination-port-range 80 \ --access Allow

az network nsg rule create \ --resource-group rg-publicip-demo \ --nsg-name nsg-web-servers \ --name Allow-HTTPS \ --protocol Tcp \ --direction Inbound \ --priority 1001 \ --source-address-prefix Internet \ --source-port-range "*" \ --destination-address-prefix "*" \ --destination-port-range 443 \ --access Allow

Security Group Rules:

Parameter	Description	Values
--priority	Rule precedence	100-4096 (lower numbers processed first)
--direction	Traffic direction	Inbound, Outbound
--access	Action to take	Allow, Deny
--protocol	Network protocol	Tcp, Udp, Icmp, Esp, Ah, *

Security First: Network Security Groups act as virtual firewalls. Create restrictive rules that only allow necessary traffic. The priority system ensures rules are evaluated in order, with lower numbers taking precedence.

Step 3: Create Virtual Machine with Public IP

az vm create \ --resource-group rg-publicip-demo \ --name vm-web-server \ --location eastus \ --image Ubuntu2204 \ --size Standard_B2s \ --admin-username azureuser \ --generate-ssh-keys \ --vnet-name vnet-demo \ --subnet subnet-web \ --nsg nsg-web-servers \ --public-ip-address pip-web-server \ --public-ip-sku Standard

VM Creation Parameters:

Parameter	Description	Options
--image	OS image	Ubuntu2204, Win2022Datacenter, CentOS85Gen2
--size	VM size	Standard_B2s, Standard_D2s_v3, Standard_F2s_v2
--public-ip-address	Existing public IP	Name of previously created public IP
--generate-ssh-keys	Create SSH keys	Stores keys in ~/.ssh/

VM Configuration: This command creates a VM and associates it with the existing public IP address. The VM is placed in the specified subnet and protected by the network security group. SSH keys are automatically generated for secure access.

Load Balancer Association

graph TB A[Internet Traffic] --> B[Public IP: 40.112.0.5] B --> C[Load Balancer Frontend] C --> D[Load Balancing Rules] D --> E[Backend Pool] E --> F[VM1: 10.0.1.4] E --> G[VM2: 10.0.1.5] E --> H[VM3: 10.0.1.6] I[Health Probes] --> F I --> G I --> H style A fill:#ff9999 style B fill:#99ccff style C fill:#99ff99 style D fill:#ffcc99 style E fill:#ccffcc

Load Balancer Traffic Flow:

This diagram shows how a load balancer distributes incoming traffic from a public IP address across multiple backend VMs. Health probes continuously monitor backend health, and load balancing rules determine how traffic is distributed. Only healthy VMs receive traffic.

Step 1: Create Load Balancer

az network lb create \ --resource-group rg-publicip-demo \ --name lb-web-servers \ --location eastus \ --sku Standard \ --public-ip-address pip-from-prefix \ --frontend-ip-name frontend-web \ --backend-pool-name backend-web

Load Balancer Components:

Component	Description	Purpose
Frontend IP	Public-facing IP configuration	Receives incoming traffic
Backend Pool	Collection of backend targets	Distributes traffic to healthy targets
Load Balancing Rules	Traffic distribution rules	Defines how traffic is balanced
Health Probes	Health monitoring	Ensures only healthy targets receive traffic

Standard SKU Benefits: Standard Load Balancer provides zone-redundancy, larger backend pools, and enhanced security features. It's required when using Standard SKU public IP addresses.

Step 2: Create Health Probe

az network lb probe create \ --resource-group rg-publicip-demo \ --lb-name lb-web-servers \ --name probe-http \ --protocol Http \ --port 80 \ --path "/" \ --interval 15 \ --threshold 2

Health Probe Parameters:

Parameter	Description	Best Practices
--interval	Probe frequency (seconds)	15-30 seconds for web apps
--threshold	Failed probes before marking unhealthy	2-3 failures for quick detection
--path	HTTP path to probe	Use dedicated health endpoint

Health Monitoring: Health probes determine backend availability. HTTP probes check specific paths, while TCP probes verify port connectivity. Configure probes to match your application's health check requirements.

Step 3: Create Load Balancing Rule

az network lb rule create \ --resource-group rg-publicip-demo \ --lb-name lb-web-servers \ --name rule-http \ --protocol Tcp \ --frontend-port 80 \ --backend-port 80 \ --frontend-ip-name frontend-web \ --backend-pool-name backend-web \ --probe-name probe-http \ --load-distribution Default

Load Balancing Rule Parameters:

Parameter	Description	Options
--load-distribution	Distribution method	Default (5-tuple), SourceIP, SourceIPProtocol
--frontend-port	Port on load balancer	Port clients connect to
--backend-port	Port on backend VMs	Port where service runs

Distribution Methods: Default uses 5-tuple hash (source IP, source port, destination IP, destination port, protocol). SourceIP creates session affinity based on client IP address.

⬆️ Upgrading IP Address SKU

graph LR A[Basic SKU Public IP] --> B[Upgrade Process] B --> C[Standard SKU Public IP] A1[Dynamic Allocation] --> B1[Migration Steps] A2[No Zone Support] --> B1 A3[Basic LB Only] --> B1 B1 --> C1[Static Allocation] B1 --> C2[Zone Redundant] B1 --> C3[Standard LB Compatible] D[Downtime Required] --> B E[Configuration Changes] --> B style A fill:#ffcccc style B fill:#ffcc99 style C fill:#ccffcc style D fill:#ff9999 style E fill:#ff9999

SKU Upgrade Process:

This diagram illustrates the upgrade path from Basic to Standard SKU. The process requires downtime and configuration changes. Basic SKU features like dynamic allocation are replaced with Standard SKU capabilities like zone redundancy and static allocation.

Important Considerations:

Downtime: Upgrade requires temporary disconnection of resources
IP Address Change: The public IP address will change during upgrade
Configuration Update: Associated resources must support Standard SKU
Cost Impact: Standard SKU has different pricing structure

Step 1: Prepare for Upgrade

# Check current public IP configuration az network public-ip show \ --resource-group rg-publicip-demo \ --name pip-basic-example \ --query "{Name:name, SKU:sku.name, AllocationMethod:publicIpAllocationMethod, IP:ipAddress}" \ --output table # Identify associated resources az network public-ip show \ --resource-group rg-publicip-demo \ --name pip-basic-example \ --query "ipConfiguration.id" \ --output tsv

Pre-upgrade Assessment: Document the current configuration including the IP address, associated resources, and any dependent configurations like DNS records or firewall rules. This information is crucial for post-upgrade verification.

Step 2: Dissociate from Resources

# Dissociate from VM (if applicable) az vm deallocate \ --resource-group rg-publicip-demo \ --name vm-example # Update NIC to remove public IP az network nic ip-config update \ --resource-group rg-publicip-demo \ --nic-name vm-exampleVMNic \ --name ipconfig1 \ --remove PublicIpAddress

Resource Dissociation: Before upgrading, you must dissociate the public IP from all resources. For VMs, this involves deallocating the VM and updating the network interface configuration. This step causes downtime.

Step 3: Perform SKU Upgrade

# Upgrade public IP SKU az network public-ip update \ --resource-group rg-publicip-demo \ --name pip-basic-example \ --sku Standard \ --allocation-method Static

SKU Upgrade Command: This command upgrades the public IP to Standard SKU and changes allocation method to Static. The IP address will change during this process. Standard SKU requires static allocation and provides enhanced features.

Step 4: Re-associate with Resources

# Re-associate with VM NIC az network nic ip-config update \ --resource-group rg-publicip-demo \ --nic-name vm-exampleVMNic \ --name ipconfig1 \ --public-ip-address pip-basic-example # Start VM az vm start \ --resource-group rg-publicip-demo \ --name vm-example

Resource Re-association: After successful upgrade, re-associate the public IP with resources and restart services. Verify the new IP address and update any external references like DNS records or firewall rules.

Step 5: Verify Upgrade

# Verify upgrade completion az network public-ip show \ --resource-group rg-publicip-demo \ --name pip-basic-example \ --query "{Name:name, SKU:sku.name, AllocationMethod:publicIpAllocationMethod, IP:ipAddress, Zones:zones}" \ --output table # Test connectivity az network public-ip show \ --resource-group rg-publicip-demo \ --name pip-basic-example \ --query "ipAddress" \ --output tsv

Post-upgrade Verification: Confirm the SKU upgrade was successful by checking the configuration. Test connectivity to ensure services are accessible. Update documentation with the new IP address and configuration details.

🔄 Implementation Flow and Command Dependencies

graph TB A[1Create Resource Group
az group create] --> B[2Create Virtual Network
az network vnet create] B --> C[3Create Public IP Prefix
az network public-ip prefix create] C --> D[4Create Public IP
az network public-ip create] B --> E[5Create NSG
az network nsg create] E --> F[6Create NSG Rules
az network nsg rule create] D --> G[7Create VM
az vm create] F --> G B --> G D --> H[8Create Load Balancer
az network lb create] H --> I[9Create Health Probe
az network lb probe create] I --> J[10Create LB Rule
az network lb rule create] style A fill:#ff9999 style B fill:#ffcc99 style C fill:#ffcc99 style D fill:#99ccff style E fill:#ccffcc style F fill:#ccffcc style G fill:#99ff99 style H fill:#99ff99 style I fill:#ccccff style J fill:#ccccff

Implementation Order:

This diagram shows the correct order for implementing Azure public IP infrastructure. Each step depends on previous components: Resource Group → Virtual Network → Public IP resources → Security configurations → Resource deployment → Load balancer configuration. Following this order ensures all dependencies are satisfied.

Complete Implementation Script

#!/bin/bash # Azure Public IP Infrastructure Deployment Script # Variables RESOURCE_GROUP="rg-publicip-demo" LOCATION="eastus" VNET_NAME="vnet-demo" SUBNET_NAME="subnet-web" NSG_NAME="nsg-web-servers" PUBLIC_IP_PREFIX="pip-prefix-demo" PUBLIC_IP_NAME="pip-web-server" VM_NAME="vm-web-server" LB_NAME="lb-web-servers" echo "Starting Azure Public IP Infrastructure Deployment..." echo "==================================================" # Step 1: Create Resource Group echo "Step 1: Creating Resource Group..." az group create \ --name $RESOURCE_GROUP \ --location $LOCATION \ --tags Environment=Demo Project=PublicIP-Guide # Step 2: Create Virtual Network echo "Step 2: Creating Virtual Network..." az network vnet create \ --resource-group $RESOURCE_GROUP \ --name $VNET_NAME \ --address-prefix 10.0.0.0/16 \ --location $LOCATION \ --subnet-name $SUBNET_NAME \ --subnet-prefix 10.0.1.0/24 # Step 3: Create Public IP Prefix echo "Step 3: Creating Public IP Prefix..." az network public-ip prefix create \ --resource-group $RESOURCE_GROUP \ --name $PUBLIC_IP_PREFIX \ --length 28 \ --location $LOCATION \ --sku Standard \ --zone 1 2 3 # Step 4: Create Public IP from Prefix echo "Step 4: Creating Public IP..." az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $PUBLIC_IP_NAME \ --location $LOCATION \ --sku Standard \ --allocation-method Static \ --public-ip-prefix $PUBLIC_IP_PREFIX echo "Deployment completed successfully!" echo "Use 'az network public-ip show' to view created resources."

Deployment Script: This comprehensive script automates the creation of Azure public IP infrastructure. It includes error handling, progress indicators, and follows the correct dependency order. Save this script and execute it to deploy a complete environment.

🔧 Troubleshooting and Best Practices

graph LR A[Public IP Issues] --> B{Issue Type} B -->|Connectivity| C[Network Troubleshooting] B -->|Association| D[Resource Association] B -->|SKU Mismatch| E[SKU Compatibility] B -->|Zone Issues| F[Availability Zone Problems] C --> G[Check NSG Rules] C --> H[Verify Route Tables] C --> I[Test Network Connectivity] D --> J[Verify Resource State] D --> K[Check Association Status] D --> L[Review Resource Configuration] E --> M[Upgrade to Standard SKU] E --> N[Check Load Balancer SKU] E --> O[Verify Feature Compatibility] F --> P[Check Zone Configuration] F --> Q[Verify Regional Support] F --> R[Review Zone Redundancy] style A fill:#ff9999 style B fill:#ffcc99 style C fill:#ccffcc style D fill:#ccffcc style E fill:#ccffcc style F fill:#ccffcc

Troubleshooting Decision Tree:

This diagram provides a systematic approach to diagnosing public IP issues. Start by identifying the issue type, then follow the appropriate troubleshooting path. Common issues include connectivity problems, resource association failures, SKU mismatches, and availability zone conflicts.

Common Issues and Solutions

Issue: "Cannot associate Standard SKU public IP with Basic SKU Load Balancer"

Solution: Upgrade the Load Balancer to Standard SKU or use Basic SKU public IP. Standard SKU resources require Standard SKU dependencies.

# Check Load Balancer SKU az network lb show \ --resource-group rg-publicip-demo \ --name lb-web-servers \ --query "sku.name" \ --output tsv # Upgrade Load Balancer to Standard SKU az network lb update \ --resource-group rg-publicip-demo \ --name lb-web-servers \ --sku Standard

Issue: "Public IP address is not accessible from internet"

Solution: Check Network Security Group rules, ensure proper port configuration, and verify resource is running.

# Check NSG rules az network nsg show \ --resource-group rg-publicip-demo \ --name nsg-web-servers \ --query "securityRules[?direction=='Inbound']" \ --output table # Test connectivity az network public-ip show \ --resource-group rg-publicip-demo \ --name pip-web-server \ --query "ipAddress" \ --output tsv # Use the IP address to test # ping # telnet 80

Issue: "Cannot create public IP in specified availability zone"

Solution: Verify the region supports availability zones and check zone-specific resource limits.

# Check availability zones in region az vm list-skus \ --location eastus \ --query "[?resourceType=='virtualMachines'].{Name:name, Zones:locationInfo[0].zones}" \ --output table # Create zone-redundant public IP az network public-ip create \ --resource-group rg-publicip-demo \ --name pip-zone-redundant \ --location eastus \ --sku Standard \ --zone 1 2 3

Best Practices

Security Best Practices:

Always use Standard SKU for production workloads
Implement restrictive NSG rules - only open necessary ports
Use availability zones for high availability
Monitor public IP usage and costs
Document IP address assignments and dependencies
Implement proper backup and disaster recovery procedures

# Monitor public IP usage az network public-ip list \ --resource-group rg-publicip-demo \ --query "[].{Name:name, IP:ipAddress, Associated:ipConfiguration.id, SKU:sku.name}" \ --output table # Clean up unused public IPs az network public-ip list \ --resource-group rg-publicip-demo \ --query "[?ipConfiguration.id==null].name" \ --output tsv

Resource Management: Regularly audit public IP usage to identify unused resources and optimize costs. Use tags consistently for better organization and cost tracking. Implement automation for routine maintenance tasks.

📚 Additional Resources

Azure Public IP Documentation: Official Microsoft documentation
Azure CLI Reference: Complete command reference
Best Practices Guide: Security and performance recommendations
Pricing Calculator: Cost estimation for public IP resources