1.5 Public IP Addresses, Public IP Prefixes & Custom IP Prefixes (BYOIP)
Key Takeaways
- A Public IP Prefix reserves a contiguous, dedicated block of Standard SKU public IPv4 addresses in your subscription, sized from /28 (16 addresses) down to /31 (2 addresses), so partners can allowlist one CIDR instead of scattered individual IPs.
- A Custom IP address prefix (BYOIP) is a range you already own at an RIR such as ARIN or RIPE and authorise Microsoft to advertise; it moves through three phases — Validation, Provision, and Commission — and is not reachable until it is commissioned.
- By default a unified custom IPv4 prefix must be between /21 and /24, a regional child IPv4 prefix between /22 and /26, a global custom IPv6 prefix /48, and a regional child IPv6 prefix /64.
- A custom IP prefix cannot be attached to a resource directly: you derive public IP prefixes and Standard SKU public IPs from it, and those derived addresses attach to resources.
- In regions with availability zones a custom IPv4 prefix must be declared zone-redundant or pinned to a specific zone, and every IP derived from it inherits that zonal property.
Public IP Addresses, Public IP Prefixes & Custom IP Prefixes
The AZ-700 IP addressing objective is not only about private RFC 1918 planning. Microsoft explicitly tests creating public IP addresses, associating them to resources, creating a Public IP Prefix, choosing when a prefix is the right design, and planning and implementing a Custom IP address prefix (bring your own IP). These are three distinct resources that candidates routinely conflate.
| Resource | What it is | Who owns the addresses |
|---|---|---|
| Public IP address | A single routable address resource you attach to a NIC, load balancer frontend, gateway, firewall, Bastion host, or NAT gateway | Microsoft |
| Public IP Prefix | A reserved, contiguous block of Standard SKU public IPv4 addresses set aside for your subscription | Microsoft |
| Custom IP address prefix (BYOIP) | A range you own and have registered with a Routing Internet Registry, which Microsoft is authorised to advertise on your behalf | You |
1. Standard SKU Public IP Addresses
Modern Azure architectures — and every AZ-700 answer — use Standard SKU public IPs. The Basic SKU public IP was retired on September 30, 2025.
| Behaviour | Standard SKU public IP |
|---|---|
| Allocation | Static only |
| Default inbound posture | Secure by default — closed. Traffic is denied unless an NSG explicitly allows it |
| Availability zones | Can be created as zone-redundant or zonal (pinned to a single zone) |
| Attach targets | VM NICs, Standard Load Balancer frontends, virtual network gateways, Azure Firewall, Azure Bastion, NAT Gateway, Application Gateway v2 |
[!IMPORTANT] The "closed by default" behaviour is a favourite exam trap. A VM with a Standard SKU public IP and no NSG rule is unreachable from the internet. Under the retired Basic SKU the same VM would have been reachable. If a scenario says "the VM was migrated to a Standard public IP and RDP stopped working," the answer is a missing inbound NSG allow rule, not a routing or firewall fault.
Associating public IPs
A public IP is a separate ARM resource with its own lifecycle. You associate it to an IP configuration — a NIC's IP configuration, a load balancer frontend IP configuration, or a gateway's IP configuration — and you can disassociate and re-associate it to preserve the address across a rebuild. Because Standard public IPs are always statically allocated, disassociating one does not release the address back to the pool.
2. Public IP Prefixes
A Public IP Prefix reserves a contiguous block of Standard SKU public IPv4 addresses for your subscription. Addresses are drawn from the prefix as you create individual public IP resources.
| Prefix size | Usable public IP addresses |
|---|---|
/28 | 16 |
/29 | 8 |
/30 | 4 |
/31 | 2 |
When a Public IP Prefix is the right answer
The exam distinguishes having public IPs from needing them to be contiguous and predictable. Choose a Public IP Prefix when:
- A third party must allowlist you. A banking partner, a SaaS provider, or a regulator's firewall accepts one CIDR entry instead of a dozen unrelated addresses, and the entry does not need editing when you scale.
- The addresses must not change. Addresses drawn from a prefix are stable for the life of the prefix, which matters for DNS records, licence bindings, and reputation-sensitive egress such as SMTP.
- You are pre-allocating outbound SNAT capacity. A NAT Gateway or a Standard Load Balancer outbound rule that consumes a
/28prefix gets 16 × 64,512 SNAT ports rather than the ports of a single address — the standard remedy for SNAT port exhaustion.
[!NOTE] A Public IP Prefix contains Standard SKU addresses only, and the addresses inside it are not usable until you create individual public IP resources from the prefix. Reserving a
/28does not by itself put 16 addresses onto anything.
3. Custom IP Address Prefix (BYOIP)
A custom IP address prefix lets you bring a public range that you already own into Azure. The range stays under your ownership; you authorise Microsoft to advertise it. This preserves an established IP reputation and keeps you inside externally controlled allowlists that would be expensive or slow to change.
The three-phase onboarding process
| Phase | What happens | Reachability |
|---|---|---|
| 1. Validation | You prove you own the range at a Routing Internet Registry (ARIN, RIPE, and so on) and authorise Microsoft to advertise it. Ownership of the range and its association with your Azure subscription are verified. Some steps happen outside Azure. | Not in Azure yet |
| 2. Provision | The range is created as a custom IP prefix resource in your subscription. You can now derive public IP prefixes and public IPs from it and attach those to resources. | Provisioned but not advertised — not reachable |
| 3. Commission | You issue the command to advertise the range. It is advertised first from the Azure region hosting the custom IP prefix, then by Microsoft's Wide Area Network to the internet. | Reachable |
[!CAUTION] The exam's favourite BYOIP scenario is a range that is provisioned, has IPs derived and attached to a load balancer, and still receives no traffic. The missing step is commissioning. Provisioning creates the resource; commissioning starts the BGP advertisement.
Default prefix size rules
| Prefix type | Default allowed size |
|---|---|
| Unified custom IPv4 prefix | /21 to /24 |
| Global (parent) custom IPv4 prefix | /21 to /24 |
| Regional (child) custom IPv4 prefix | /22 to /26, and at least one level smaller than its parent |
| Global (parent) custom IPv6 prefix | /48 |
| Regional (child) custom IPv6 prefix | /64 |
By default you can bring a maximum of five custom IP prefixes per region; this limit can be raised on request.
Documented limitations worth memorising
- A custom IP address prefix cannot be attached directly to a resource. You derive public IP prefixes and Standard SKU public IPs from it, and attach those.
- In regions with availability zones, a custom IPv4 prefix (or a regional custom prefix) must be declared zone-redundant or assigned to a specific zone — it cannot be created with no zone — and all IPs from the prefix share the same zonal property.
- Advertising IPs from a custom IP prefix over ExpressRoute Microsoft peering is not supported.
- Custom IP prefixes do not support Internet Routing Preference or the Global Tier used for cross-region load balancing.
- Reverse DNS against Azure-owned zones is not provided; you must onboard your own reverse zones to Azure DNS.
- Once provisioned, a custom IP prefix cannot be moved to another subscription or between resource groups, and derived public IP prefixes cannot be moved either.
- There is no charge to provision or use custom IP prefixes, or for the public IPs derived from them; traffic is billed at the normal internet egress rate.
4. Choosing Between the Three
| Requirement in the scenario | Correct resource |
|---|---|
| "Attach a stable internet-facing address to this firewall" | Standard SKU public IP address |
| "Our partner's firewall team will only accept one CIDR entry, and we need 16 addresses that never change" | Public IP Prefix (/28) |
| "Our SMTP reputation and our customers' allowlists are built on 203.0.113.0/24, which we own, and we are migrating to Azure" | Custom IP address prefix (BYOIP) |
| "Backend VMs are dropping outbound connections at peak; we need far more SNAT ports" | NAT Gateway with a Public IP Prefix attached |
A payments company owns 198.51.100.0/24, registered with their Regional Internet Registry, and is migrating workloads to Azure. Their merchant partners allowlist that range and will not update their firewalls. The team completes validation, provisions the custom IP prefix, derives a public IP prefix and several Standard SKU public IPs, and attaches them to a Standard Load Balancer frontend. External merchants still cannot reach the service. What is the most likely cause?
An enterprise runs a NAT Gateway for outbound connectivity from a large application subnet. During month-end batch processing, outbound connections begin failing intermittently while inbound traffic is unaffected. The team wants a design change that both increases available SNAT ports and gives their banking partner a single CIDR entry to allowlist. Which change meets both requirements?
A network engineer is planning a BYOIP onboarding in an Azure region that supports availability zones. Which statement reflects a documented constraint on custom IPv4 prefixes?