Managing public IP prefixes in Azure using PowerShell

Azure public IP address prefixes is a new service, and in this post, I'll walk you through the steps of how to create and manage public IP prefixes using PowerShell.
Latest posts by Baki Onur Okutucu (see all)

Public IPs can be essential for services such as application gateways, firewalls, and virtual network gateways in Azure, especially when it comes to making these services accessible from the internet. Assigning a public IP address to a service in Azure is simple.

The trick is to decide whether you need to use a static or a dynamic public IP address. We need to be aware that not all Azure services support static public IPs. Here are some important points about the use of public IP addresses for some popular services in Azure:

  • You can assign either dynamic or static public IP addresses to load balancer frontends.
  • Virtual machines (VMs) can have either static or dynamic public IP addresses.
  • We can only assign dynamic public IP addresses to VPN gateways.
  • Application gateway frontends can only have dynamic public IP addresses.

Also, one of the things to keep in mind is that when we assign a static public IP to a service, we cannot specify the IP address on the public IP address resource. This is because Azure assigns the public IP addresses from available IP address pools based on the Azure locations the resources are created in.

Public IP address prefixes are reserved ranges of IP addresses Azure allocates depending on Azure regions and how many public IP addresses you want to use. Each Azure region has several IP ranges available. You can check available ranges in Azure regions via the regularly updated link.

With public IP address prefixes, you can reserve a certain number of consecutive public IP addresses in advance and use them whenever needed.

For instance, you may want to reserve four consecutive IP addresses for your VM farm without having to create your VMs first. In this way, you can easily configure your firewall exceptions or DNS hostname mappings in advance using the reserved range of public IP addresses. This is because you already know which public IP address Azure will assign to the next VM upon creation.

We can create a public IP address prefix in Azure by specifying an IP address prefix such as /30, which allocates four IP addresses from one of the IP ranges available in that region. Even though the IP addresses to allocate are contiguous, we don't know from which range Azure will assign the IP addresses.

Below are some limitations when using public IP prefixes in Azure.

  • You can't change the range once you've created the prefix.
  • There's only support for static public IP addresses with the Standard SKU.
  • You can't delete a prefix if any service in Azure is using any address from its pool.
  • There's no support for the classic deployment model or Azure Service Management (ASM).
  • There's no support for IPv6 addresses.
  • You must assign the IPs in the public IP prefixes to services in the same Azure region as the public IP prefixes.

Creating a new public IP prefix ^

We can look at the cmdlets available in PowerShell to manage public IP prefixes.

Available cmdlets to manage public IP prefixes

Available cmdlets to manage public IP prefixes

In my scenario, I will create a new public IP prefix with four contiguous IP addresses. To be able to have four IP addresses, I need to specify the prefix length of /30.

Creating a new public IP prefix

Creating a new public IP prefix

As you can see, Azure has automatically reserved the IPs from a range of When we create another public IP prefix in the same region (North Europe), Azure might create it from a different IP range in the same region based on availability. Let's see.

A second public IP prefix from a different range

A second public IP prefix from a different range

This time the IPs came from a different range as expected.

Creating public IPs from a public IP prefix ^

Now we can go back to the first prefix we've created and create a new public IP address from that, which is

Creating a second Public IP from the same Public IP Prefix

Creating a second Public IP from the same Public IP Prefix

We've now created the first public IP from our public IP prefix, the first IP of the reserved range If we create a second public IP from the same prefix, the IP should be Let's see if that's true.

Creating a second public IP from the same public IP prefix

Creating a second public IP from the same public IP prefix

Yes, it's definitely true! We can now check to see how many IPs within the prefix Azure has already allocated to public IP resources using the following command:

Public IPs from the prefix are in use

Public IPs from the prefix are in use

Because there are two IP addresses already in use, we cannot delete the prefix until we remove the IPs from it.

We can't remove a public IP prefix when any IP in it is in use

After removing the public IP address resources from the prefix, I can delete the prefix successfully.

Removing public IPs and prefixes

Removing public IPs and prefixes


Public IP address prefixes are useful when you need to reserve a certain number of public IP addresses within a certain IP range. You can use this feature for all Azure services that support static public IP addresses. This is a paid service in Azure.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads and for free by becoming a member!

1 Comment
  1. Just to emphasize on the Public IP Prefix cost-factor,

    If we already have an Azure setup with Basic Tier Public IP address, Prefixes cannot be used unless we perform a migration of IP address from Basic Tier to Standard Tier.

    If we are utilizing up to 5 public IP per region then the migration from Basic Tier to Standard Tier would result in more cost.

    But if we are utilizing more than 5 public IP per region then this process would result in less cost.

    Once we have an Azure setup with standard Tier Public IP address, using Public IP prefixes would bring additional costing(approx 20%).

    So overall 20% increase in Public IP cost is negligible when we look at the sophistication it brings to the table for NSG/Firewall rules management.


Leave a reply to Swapnil Kambli (Rank: Level 3)
Click here to cancel the reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account