You are here:   Blog
Register   |  Login

Blog Archive:

* Can be used in order to search for older blogs Entries

Search in blogs

Blog Categories:

* Can be used in order to search for blogs Entries by Categories

Blog Tags:

* Can be used in order to search for blogs by keywords


Awared MVP


Microsoft® Community Contributor 

Microsoft® Community Contributor

 Read this before you use the blog! Maximize

Recent Entries


Written by: ronen ariely
14/06/2020 01:51 RssIcon

Another great question in the Microsoft forum, and the result is another post in Ronen's blog...

Hi guys,

Let me start with some basic information about Networking in general, in order to cover the main terms, which we all must know, before we start to play with the powerful options that Azure Static Public IP service provides us.

 Table Of Content

 Background - introduction to network Requests and Azaure Public IP

   ◼ Azure Static Public IP

 Create Azure Public IP

 Associate Existing Static IP to a new Virtual Machine

 Associate Existing Static IP to Existing Virtual Machine

 Migrating public IP between Virtual Machines



   ◼ Appendix A: Migrating Classic Azure Reserved IP to ARM Static Public IP


Background - introduction to network Requests and Azaure Public IP

In order to communicate with a device connected to a computer network that uses the Internet Protocol, we use it’s “Internet Protocol address” or in short IP Address. An IP Address is a numerical label assigned to each device connected to a computer network that uses the Internet Protocol for communication. An IP address is used for identification and location of the device.

In order to host a public web service, we need to provide a simple way to find our machine in the internet. This can be done using the machine's current IP address. Since IP address are hard to remember and used by human, we are using “Domain name”, which is simply an identification string, which is mapped to an IP Address.

Note: for the sake of this post, I will use the phrase "Domain" for either top-level domains (TLDs), Second-level, or lower level domains (usually named sub-Domain).

To prevent conflict between domain names, the Internet Corporation for Assigned Names and Numbers (ICANN) was established. ICANN manages the top-level development and architecture of the Internet domain name space. It authorizes domain name registrars, through which domain names may be registered and reassigned.

Note! In the dark network there is no official organization, which is in-charged on managing the domain names. Therefore the same name can be configured to be used by multiple entities. It's very common that attempting to reach specific service (site) in the dark net, end up with reaching a totally different service. Sometimes it can be really challenging to actually reach the service which you want to. To help solve this issue there are some darknet search engines, which can help, but these are not guaranty anything since the data is very dynamic.

The registration of the domain names is usually administered by “Domain Name Registrars”, who sell their services to the public. The entire process of configuring the "use of Domain to reach our web service", starts with a Domain Registrar. The registrar is the first piece of the puzzle, because whenever a request for a domain is made, the registrar is the first place that gets referenced for information. The domain register defines nameservers (also called DNS servers), which the domain is pointed to.

The nameservers are handling queries regarding the location of a domain name’s various services. They are managing "DNS records", which maps the domain names to IP addresses. The Domain Name Servers are the Internet's equivalent of a phone book. They maintain a directory of domain names and translate them to Internet Protocol (IP) addresses. It is considered a best practice to have more than one nameserver for any domain.

When an entity looks up a domain name (for example a browser tries to get the information from a website), then it probably does not query the nameservers directly. There are millions of "local DNS servers" on the internet, which is the key to the system’s robustness. The local DNS servers used to locate the nameservers according to their clients’ needs and they cache the information locally.

In order to ensure that all the DNS servers have the same DNS records data, changes are always made only on one nameserver (typically called a Master). The other nameservers (typically called Slaves) periodically pull the updated data from the master. The local DNS servers will periodically check with the nameservers (Master or Slaves) to see if there have been any changes in the data hosted there. If they detect a change, then they will pull down the update information.

The frequency of this check is called the “Refresh interval for the domain”. Common refresh intervals are anywhere from 30 minutes to a couple of hours. This means that if an IP address is changed, then the mapped domain might lead the request to a wrong location. Therefore, the service which we host based on the domain, might not be available for few hours.

Obviously, this is not acceptable for most services like a website!

To prevent this from happening, there are two common solutions: We can use a service of Dynamic DNS server which update the information every few minutes, or (the professional way) we can use a static IP Address, which ensure that the IP address will never change.

So… In short: In order to reach a service, which we host in our machine, we usually use Domain names, which are mapped to the Machine’s current IP. Using static IP ensure that the requests to the domain will reach the right machine.

Internet Protocol Address -> Domain Names -> Domain Registrars -> domain’s nameservers / Domain Name Servers -> DNS records -> local Domain Name Servers -> Refresh interval for the domain -> Static Public IP…

Azure Static Public IP


Public IP addresses enable Azure resources to communicate to Internet. You can associate a public IP address with Azure virtual machines by assigning it to its network interface. This allow us to communicate with the Virtual Machine and services hosted by the Virtual machine. Public IP allows us to host public services (like email server, web server, and so on) based on the IP address. We can map domains to the Public IP address using DNS.

Azure public IPs support Static assignment of IP address. Using Static Public IP there is no need to update the DNS each time the IP changed, and this ensure us that there will not be any downtime to our services while the DNS servers need to update the DNS records.

We do not have a direct way to control the IP Address which is assigned to the resource. The resource is assigned an IP address at the time it's created and releases it when the resource is deleted or when the allocation method is changed from static to dynamic.

Let’s go over some case studies of using Static IP… It’s demo time!

Create Azure Public IP

To create public IP using the portal you can go the following blade:


Click on +Add and fill the form as shown below. Notice that you have option to select Dynamic IP or Static IP.

Associate Existing Static IP to a new Virtual Machine

Note! You can only associate public IP to a Network interface if it is in the same subscription and location. Make sure that your Public IP, Virtual Network, Network Interface, and Virtual Machine are all located in the same location and under the same subscription.

1. Create new Static Public IP, as explained above. Recommended to select a DNS name as well.

2. Create new Virtual Machine (you can use this direct link to the virtual machines blade)

2.1 When you get to the configuration of the Network, click on the public IP dropdown box and find the Static IP which we created in step 1. Notice that you can only see the IP which are not yet in used and are in the same subscription and location as the Virtual Machine.

3. Finish the wizard to create the Virtual Machine…

Associate Existing Static IP to Existing Virtual Machine

What we actually do is to associate the Public IP to a Network Interface. The Network Interface is associated to the virtual machine.

Therefore, if you do not have a Network Interface associated to the Virtual machine, which you want to use with the current Public IP, or you have Network Interface but other IP is already associate to it, then you first need to create new Network Interface, as we will do in step 1.

If you already have a Network interface associate to the Virtual Machine and there is no IP or load balance associated to it, then you can skip to step 2.

Note! Virtual machine can have one or more Network Interfaces. Each Network Interface can have only one IP or load Balance associated to it.

1 Create new Network Interface associated to the Virtual Machine

1.1. Navigate to the Virtual Machine Blade


1.2. Click on the Virtual Machine which you want to associate the Public IP

1.3. On the left menu under “setting”, click on “Networking”

1.4 Click on: “Attach network interface”

1.5 Click on: “Create and attach network interface”

1.6 Fill the form and select “Create”

By default, only a private IP is associated to the Network Interface.

2 Associate existing Public IP to existing Network Interface

2.1 Navigate to the Public IP Blade and find the IP which we want to use.


2.2 Click on the Public IP

Note: The public IP can be associate only to one network interface or a load balance. If it is already associated, then you will need to first Dissociate it.

2.3 Click on “Associate”

2.4 Fill the form

2.4.1 Select Resource type: network Interface

2.4.2 Select Network interface: find the network interface which you want to use.

Note: To find the Network Interface, which is already associate to the Virtual Machine, navigate to the Virtual machine, select Networking, and confirm that no other IP or load balance is already associated to the network Interface.

2.4.3 Click OK, and once it done you have finished to add the IP to the Virtual Machine.

Migrating public IP between Virtual Machines

Why? For example, we have a service which is hosted in a virtual machine and we want to migrate the service to a new virtual machine. Creating a new virtual machine and associate a new IP address to the service in the new VM, means that we will have to update the DNS servers. This means that the service which we host based on the domain, might not be available for few hours, according to the refresh interval for the domain.

Migrating the Static IP address to the new VM, allows us to migrate the service with zero offline time!

1. Dissociate the IP from the old machine

1.1. Navigate to the Virtual Machine Blade


1.2. Click on the old Virtual Machine

1.3. On the left menu under “setting”, click on “Networking”

1.4. Click on the “Network Interface” which the public IP is associated to.

1.5. Click on the “Public IP address”

1.6. Click on “Dissociate

2. Associate the Public IP to the new Virtual machine as explain in previous scenario


When we are using Static Public IP, then there is no need to update the DNS records in the DNS servers, each time the IP changed. This ensures us that there will be no downtime to our services, while the DNS servers are not updated yet.

The Azure public IP is a separate service, which we can associate to a new or existing Network Interface or to a load Balance. The Network Interface is associated to Virtual Machine. Therefore, if we are using a Static IP then we can migrate IP Address from one machine to another. This is a powerful option in cases that we need to migrate services between virtual machines.

In this post we spoke a bit about the theory, and we saw how we can work with create and manage Static IP in relation to Virtual Machines.


Appendix A: Migrating Classic Azure Reserved IP to ARM Static Public IP

Historically, before 2014 Azure services were provided via the following URL <https://manage.windowsazure.com/> using a management model called the ASM model. In 2015 Microsoft started a new model to managed the services based on Resource Group and the old services started to migrated to a new portal via the following URL <https://portal.azure.com/> using a management model called ARM model. From that time the old portal and management model became Known as the "Classic Portal". Even today when the old portal is not supported anymore for new services, people still consider it as the Classic Portal.

If you have a an old service of Azure Reserved IP from the Classic Model, then you can migrate it to Azure Static Public IP Service. I did not tested it myself, but I found this short tutorial on the task:


Appendix B: Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources