Azure Networks for Architects

Azure Networks for Architects is a series of articles where I’ll go over some of the aspects of designing networks on Microsoft Azure. This series will have multiple blog posts and in each article, I’ll go over one aspect about networks on Azure. The series is aimed to cover from very trivial and small concept to important ones.

Though the title of this series says “Architects” this will be helpful for multiple category of poeple including developers, IT professionals, project managers, technical leads, consultants… who want to understand much fine aspects about networking which is much beyond “How to” aspects. In the articles you’ll also find that there are very small things that we tend to overlook but they play important roles in overall design for any enterprise level deployment.

The concepts presented in this series come from a wide variety of sources including my experience while working with hundreds of customers in Microsoft as a Sr. Consultant, my takeaway while working with customers in ComTec as Solution Architect, my learning from some very knowledgeable people in the industry, my mistakes and my little power of visualization and analysis.

Why Networks only? I’m aiming to cover multiple aspects on cloud computing and I’m only “starting” with networks. In future you’ll see other components of designing cloud solutions like “storage”, “communication”, “security” and so on.

Why starting with networks? Networks for the backbone of any solution. The first step in deploying any solution involves creating its underlying infrastructure upon which entire solution is built. As you’ll see in articles of this series, Network design dictates many things about your solution like performance, availability, scalability, security, maintainability and cost. I’ve not used these terms to impress, as you’ll see, these are indeed affected by network design. I’m ignoring about a small set of solutions which are built on PaaS or SaaS and may not need network as such.

Solution vs Application/Software: You’d have seen me using the term solution very often. My title with ComTec also says “Solution Architect”. This is also a buzzword that many people use as it sounds fancy and kind of “deep” and “better” than other terms. Some thin k “Solution” is very large and complex software application. However, I’ve tried to take utmost care about terms that I use (I may still have have used some terms without much thought). The term “Solution” refers to the “Answer” to a “Problem” that we are trying to address. Some times answer to a problem may be a software application but not always. As we move beyond this networking series, you’ll see that the articles are more abstract (farther from “how to”) … more “strategic” than implementation oriented. Even a decision to not use a software could be a solution to problem.

This series is also mirrored at The links in this article below will be updated as and when new articles are posted.

List of Series Articles:

  1. What are Networks
  2. Designing Networks – Part 1 – Performance/Latency

Stay Tuned! Subscribe

Rahul Gangwar

Azure IP Addresses


  • Virtual IP means an IP that is visible externally but it may not be actually assigned to actual resource. So for example, if I have a web farm with two nodes, I don’t want IP of actual resources. Instead, I need an IP that can be used to identify my farm (both the nodes/VMs). Since it is not the IP that is actually allocated to the node, it is called virtual IP.
  • VIPs are always external facing. They are never internal and never assigned to the actual VM.
  • VIPs are always associated with CloudService/Load Balancer. Documentation uses the term CS and Load Balancer interchangeably. For example this article is about VIP on CS but inside it also says that it is associated with Load Balancer. On a side note, from IaaS perspective, load balancer will be more accurate term while from PaaS perspective CS will be better to visualize.


  • Dynamic IP is the actual IP that a node/VM gets. These are actually assigned to the VM instance’s NIC card.
  • However, it is always internal. These IPs are assigned to the VM instance and are never available outside a CS/vNet within which the VM is present.
  • These are called Dynamic because by default, the IP that your VM gets can change if you deallocate.
  • In a typical scenario, let’s assume we have 10 VMs in a vNet, then each VM will get an internal IP (DIP) and “most of times” we don’t care even if it changes. Only in few scenarios we don’t want these internal IPs to change (say when your VM is hosting DNS). In that case, we would want this internal IP (DIP) to be static rather than dynamic. So, you could “reserve” these internal IPs as well. In a typical web farm scenario, you’d never care about reserving DIP.


  • Public Instance-level IP (earlier called PIP) is an IP that is visible to external world AND is actually assigned to the VM instance.
  • So, they are same as VIP except that unlike VIP, they are actually assigned to VM instance.
  • If you access a VM using its PIP, the traffic never goes through load balancer. That is the reason why you never configure/add/delete any public endpoint (http/https etc.) on cloud service when you are using PIP because endpoints never come into picture.
  • In most of scenarios, you’d never want to use PIP. Some scenarios (like passive FTP) may be eligible candidate for using PIP.
  • You’d never use PIP for web farm scenarios as you will definitely have more than one VMs in your farm and you’d want traffic to be routed via load balancer. So for web farms, you’d want to use VIPs only.

Reserved/Stable IP:

  • These are one and the same. When you reserve an IP it becomes stable… doesn’t change irrespective of your deallocation of resources etc…. though deletion does affect even reserved IPs.
  • You can reserve both VIP and DIP but not PIP (again unless something changed).

-Rahul Gangwar