IP Addressing: Public, Private & Prefixes
Master Azure IP addressing — dynamic vs static private IPs, Basic vs Standard public IPs, public IP prefixes, BYOIP, and subnet delegation for managed services.
IP Addressing: Public, Private & Prefixes
Every Azure resource that communicates needs an IP address. This module covers how Azure assigns private and public IPs, when to use prefixes, and how subnet delegation works.
🎬 Video coming soon
IP Addressing and Prefixes Explained
IP Addressing and Prefixes Explained
~13:00Think of IP addresses like phone numbers for your cloud resources. Private IPs are internal extensions — only devices inside the building (VNet) can call them. Public IPs are external numbers — the outside world can reach you. You choose whether each number is permanent (static) or changes when you restart (dynamic).
Private IP Addresses
Private IPs are assigned to resources within a VNet — they’re for internal communication only. You choose between two allocation methods:
| Allocation | How It Works | When to Use |
|---|---|---|
| Dynamic | Azure assigns the next available IP from the subnet. IP may change on stop/deallocate. | General workloads, test VMs |
| Static | You pick a specific IP from the subnet range. It never changes. | DNS servers, domain controllers, apps that need consistent IPs |
Exam Tip: A dynamic private IP is assigned when the resource starts (not when the NIC is created). If you stop-deallocate and restart a VM, it may get a different dynamic IP. Static IPs stay assigned even when the resource is stopped.
🏢 Ravi’s scenario: His domain controllers in the SharedServices subnet need static private IPs (10.10.10.4 and 10.10.10.5) so DNS always resolves to the right servers. His general workload VMs use dynamic allocation.
Public IP Addresses
Public IPs allow resources to communicate with the internet and public-facing Azure services. Azure offers two SKUs:
| Feature | Basic SKU | Standard SKU |
|---|---|---|
| Allocation | Dynamic or Static | Static only |
| Availability Zones | Not supported | Zone-redundant by default |
| Security | Open by default | Secure by default (closed inbound) |
| Routing preference | Not available | Internet or Microsoft network |
| Global tier | Not supported | Supported (for cross-region LB) |
| SLA | No SLA | 99.99% SLA |
| Retirement | Retiring 30 September 2025 | Current — use this |
Exam Tip: Basic public IPs are retiring on 30 September 2025. For the exam and all new deployments, always choose Standard SKU. Standard IPs are static-only, zone-redundant, and secure by default (you must create an NSG or LB rule to allow inbound traffic).
Where Can You Attach a Public IP?
Not every resource supports a direct public IP. Here’s what does:
| Resource | Public IP Attachment |
|---|---|
| VM Network Interface (NIC) | Yes — one public IP per IP configuration |
| Public Load Balancer | Yes — frontend IP |
| VPN Gateway | Yes — required for S2S and P2S |
| Application Gateway | Yes — frontend IP |
| Azure Bastion | Yes — Standard SKU required |
| NAT Gateway | Yes — one or more for outbound |
| Azure Firewall | Yes — one or more for outbound SNAT |
Resources like Azure SQL, Storage, and Key Vault get public endpoints automatically — you don’t attach a public IP to them. You can disable their public access and use private endpoints instead (covered in Domain 4).
Public IP Prefixes
A public IP prefix is a contiguous range of public IPs reserved for your subscription. This is powerful when your firewall rules depend on knowing Azure’s outbound IPs in advance.
| Prefix Size | Addresses | Use Case |
|---|---|---|
| /31 | 2 | Minimal — two services |
| /30 | 4 | Small deployment |
| /29 | 8 | Medium — NAT Gateway |
| /28 | 16 | Maximum for Azure-owned prefixes |
Note: /28 (16 addresses) is the maximum prefix size for Azure-owned public IP prefixes. For larger contiguous ranges, use BYOIP (Custom IP Prefix) — see below.
🏪 Sam’s scenario: Harbour Retail’s payment gateway vendor requires allowlisting Sam’s outbound Azure IPs. Instead of updating the vendor every time an IP changes, Sam creates a /29 prefix (8 IPs) and assigns them to his NAT Gateway. The vendor allowlists that range once and it never changes.
Key facts:
- Prefixes are region-specific
- You can create individual public IPs from a prefix
- Prefix IPs are static by default
- You pay for allocated IPs whether used or not
Bring Your Own IP (BYOIP)
BYOIP — Custom IP Prefixes
Large enterprises sometimes own their own public IP ranges (from their ISP or RIR). Azure lets you bring these into Azure with Custom IP Prefixes (BYOIP).
Steps:
- Create a Route Origin Authorization (ROA) with your Regional Internet Registry (ARIN, RIPE, APNIC) authorising Azure ASN 8075
- Create a Custom IP Prefix resource in Azure — this provisions and validates the range
- Commission the prefix — Azure starts advertising it via BGP
- Create public IP addresses and prefixes derived from your custom prefix
Requirements:
- Minimum range: /24 for IPv4
- You must own the range (validated via ROA)
- Provisioning takes up to 30 minutes; commissioning takes up to 10 minutes
This is a niche topic on the exam but could appear in scenario questions about enterprises that need to preserve their existing public IPs during migration.
Subnet Delegation
Subnet delegation gives an Azure PaaS service permission to inject its resources into your subnet. This lets the service use private IPs from your VNet while the service manages the infrastructure.
| Service | Delegation Identifier | Notes |
|---|---|---|
| App Service (Web Apps) | Microsoft.Web/serverFarms | VNet integration for outbound traffic |
| Azure Container Instances | Microsoft.ContainerInstance/containerGroups | Containers get VNet IPs |
| Azure SQL Managed Instance | Microsoft.Sql/managedInstances | Requires large dedicated subnet (/27 minimum) |
| Azure Databricks | Microsoft.Databricks/workspaces | Two subnets needed (public + private) |
| Azure NetApp Files | Microsoft.NetApp/volumes | Dedicated subnet required |
Delegation rules:
- Only one delegation per subnet (you can’t delegate to two services)
- The delegated subnet can still have other resources like private endpoints
- Some delegations prevent adding resources beyond the delegated service
- Delegation can be removed only after all delegated resources are removed
🏢 Ravi’s scenario: He needs App Service web apps to access his SQL Server on the private network. He delegates a subnet to Microsoft.Web/serverFarms, enabling VNet integration. The web apps get private IPs in that subnet for outbound calls to SQL.
Key Takeaways
- Standard SKU public IPs are the only choice going forward (Basic retiring Sept 2025)
- Standard IPs are always static, zone-redundant, and secure by default
- Public IP prefixes give you a guaranteed contiguous range
- Subnet delegation grants a PaaS service access to deploy into your subnet
- Only one service delegation per subnet
Test Your Knowledge
Sam needs his Azure outbound IPs to never change so his payment vendor can allowlist them. What should he use?
Which statement about Standard SKU public IPs is correct?
Ravi wants to delegate a subnet to both App Service and Azure Container Instances. Is this possible?
Next up: Name Resolution: Azure DNS — Configure public zones, private zones, and the DNS Private Resolver for hybrid name resolution.