Azure Managed vs Unmanaged disks : The choice

Hi folks,

Recently (few months) , a new feature was announced to bring a new capability to Azure Virtual Machines : Azure Managed Disks.

Many blog posts explain well the purpose of managed disks, and how they bring enhancements to Azure IaaS virtual machines. I recommend the following readings :

The latter post shows the advantages of using Azure Managed disks, which I agree and confirm. But on the meanwhile, there is some ‘inflexible’ properties of managed disks, that may not be suitable for your or for your expectations. This is the purpose of this post : What is the model that fits my requirements , Managed or unmanaged disks.

1- The main difference between Managed disks and Storage Accounts based disks

There are some main differences between managed and unmanaged disks :


Managed disks

Unmanaged disks


Is an ARM (Azure Resource Manager) object (resource) Is not an ARM resource, but a file (.vhd) residing on a Azure Storage Account. The latter is an ARM  object


The managed disks sizes are fixed (and can be resized). Which means that you cannot choose a custom size. You will need to pick up from a list. See (1) You can choose the disk size during the provisioning (and can be resized) when using Standard Storage. See (2)


You will pay :

·       Standard Storage :

o   A fixed price per disk size (Per month), whatever the disk usage is

o   Operations cost*

·       Premium Storage

o   A fixed price per disk size whatever the disk usage is

See (1)

You will pay :

·       Standard Storage :

o   The GB / month disk usage. You pay only what you consume

o   Operations cost*

·       Premium Storage

o   A fixed price per disk size whatever the disk usage is

See (3) and (4)


A managed disk have a predictable performance, with Standard storage (500 IOPS) or Premium storage (Depends on the disk). Only premium storage disks have a predictable performance (depends on the disk). Standard storage have a predictable performance (500 IOPS) unless they are impacted by the Storage Account performance limits (A maximum of 40 disks per standard storage account is recommended, otherwise disks can be throttled). See (5)


When placing VMs using managed disks under an Availability Set, disks are placed on different fault domains in order to achieve the better SLA (The Availability Set SLA is only for compute) When placing VMs using unmanaged disks under an Availability Set, there is no guarantee that the disks are placed on different fault domains, even if they are on different Storage Accounts.




ADE, SSE (Coming soon) ADE, SSE

* Operations cost means : Replication data transfer cost (In case of GRS) + Storage operations costs


2- Are managed disks more expensive that unmanaged disks ?

The answer is : It depends, but except in some cases, managed disks are always more expensive than unmanaged disks. Let’s prove it :

Standard Storage managed disk cost per month

  • Managed disk cost = Fixed Cost (Per disk size) + Operations cost
  • Unmanaged disk cost = Storage_Usage_In_GB * CostperGB + Operations cost

Because the Operations cost is the same for both models, we will omit them during calculation. Because the managed disk pricing model is not per usage, we will calculate the Disk size equity* value, to be able to compare with unmanaged disk :

Managed disk type

Size (GB) Price Cost per GB Standard Storage price per GB Disk size equity*


32 1.3 0.040625 0.0422 31
















S30 1024 34.56



* If you use less than the given size, then Unmanaged disks will cost less than managed disks. If you use more, then managed disks cost will be less than unmanaged disks. The €/GB will be greater as long you consume less storage space.

NB : New disk sizes have been announced (6) that finally make and end for the 1 TB disk size limit, with 2 and 4 TB for managed disks, and up to 4 TB for unmanaged disks. The service started on the West US Central region and will be generalized for the remaining regions during the coming months

3- Do I really need managed disks ?

This is a good question, but the answer is very relative to your needs. As you probably have read on the posts I mentioned earlier in this post, there are many benefits of using managed disks:

  • Disk snapshots
  • Predictable performance
  • Distribution in different fault domains when associated with Availability Sets
  • ARM object

Some workarounds may be used to have similar properties with unmanaged disks:


Unmanaged disk workaround

Disk snapshots


No workarounds

Predictable performance


Place less than 40 disks per Storage Account

Distribution in different fault domains when associated with Availability Sets


No Workaround. There is no way to know if the disks are place on different pools even if they are on different Storage Accounts

ARM object


Place each disk on its own Storage Account. Look if this will fit your needs  (Do not forget quotas)


4- Verdict

As you can see, managed disks brought new experience and features to Azure VM storage that permits better controlling the VM storage. Personally, I would recommend using managed disks, even if the ‘Pay as you consume’ model is not adopted there. But the features and the simplicity is worth the ‘little’ difference we can see with pricing.  Continue reading


Azure Backup with Azure Recovery Services : Features and limitations

Hi all,

It has been  days since Microsoft announced the Public Preview of Azure Backup via Azure Recovery Services. In this post I will enumerate the different features and limitations of the service, to help you decide if it fits your needs.

NB : This post is only related to IaaS part of Azure Backup

The following is the agenda of this post :

Introduction to Azure Backup via Recovery Services

Azure Backup for Azure IaaS features (Current and Coming)

Azure Backup for Azure IaaS  limitations

1- Introduction to Azure Backup via Recovery Services

Azure Backup was released first time under Azure Backup vaults, and it was only supporting classic Azure IaaS (Azure Service Management ie IaaS v1). With the GA of the Azure Resource Manager stack on summer 2015, IaaS V2 users were not able to use Azure Backup to protect their V2 virtual machines. This was the first blocker of the ARM stack adoption and one of the most wanted feature regarding the ARM platform.


After 10 months of struggle, Microsoft announced the Public Preview of Azure Backup supporting IaaS V2 virtual machines. It’s a real alleviation for Azure IaaS V2 users, but also for all Azure users planning to use Azure backup features. The main difference is that Azure Backup is now part of Azure Recovery Services vaults, and no longer Azure Backup vaults. Azure Backup vaults still exist under the ASM stack, but it’s clear that sooner or later, all will be integrated to Azure Recovery Services.

Azure Recovery Services include both Azure Backup and Azure Site Recovery supporting both ASM and ARM stacks. This is what we call great news:

  • Azure Recovery Services is integrated to the new portal (Ibiza portal)
  • Azure Backup and ASR under Recovery Services vaults support both ASM and ARM stacks

Azure Backup under Recovery Services vaults support the 4 backup scenarios:

  • Azure Backup Server or Agent based:
    • Azure Backup Agent to Azure –> Backup files and foders to Azure Storage
    • Azure Backup with System Center Data Protection Manager –> Backup Hyper-V VMs, SQL server, SharePoint, files and folders to Azure Storage
    • Azure Backup with Azure Backup Server (MABS, code name Venus) –> Backup Hyper-V VMs, SQL server, SharePoint, files and folders to Azure Storage
  • Azure Backup on the Azure Service Fabric :
    • Azure Backup for IaaS VMs –> Backup Classic and ARM Azure Virtual Machines


This post will only detail Azure Backup for IaaS virtual machines

2- Azure Backup for Azure IaaS features (Current and Coming)

Azure Recovery Services is currently under Public Preview. The following are the features of Azure Backup and the expected features that will come with GA:

  • Backup and Restore ARM and ASM Azure virtual machines (V1 and V2)
  • Based on backup policies : Two backup schedules exist : Daily and Weekly. This way you can define backups which occur daily or weekly
  • Azure Backup provides different retention periods possibility : Daily, Weekly, Monthly and yearly. Microsoft officially stated a maximum retention period of 99 years, however, thanks to Azure Backup flexibility, you can have unlimited retention period, up to 9999 years. This way, you can achieve long term retention using the same policy and mechanism (9999 days for daily backups, 9999 weeks for weekly backups,9999 months for monthly retentions ,9999 years for yearly retention)
  • Azure Backup provides 3 recovery point consistency types : Application, File and Crash consistent recovery points. You can consult the documentation to get the requirements and prerequisites for each type
  • The Backup Vault’s Storage redundancy can be GRS or LRS. GRS is more secure (Data is replicated between two regions) but more expensive (LRS *2), LRS is less secure (Locally Redundant) but cheaper. As per my experience, because the Azure Backup pricing is per protected instance (And the price is relatively high), you will notice that the Storage cost is a small fraction of the Azure Backup instances cost, so using GRS will not really impact the bill.
  • Azure Backup use incremental backups : The first recovery point is a full backup, the next ones are incremental backups : This reduce the consumed backup storage. Due to the Azure Backup design and mechanism, incremental backups will not impact the restore time.
  • Simple pricing model : The cost of Azure Backup is like the following : Total Cost = Instance Cost + Consumed Storage. If you know the daily change or growth of your data, than you can easily predict the backup cost. See this link for Azure Backup pricing :
  • A backup operation consist of two phases : Snapshot phase and Data transfer phase. The snapshot phase occur when the scheduled moment comes. The data transfer he backup vault begins just after the snapshot completion. This operation lay take up to 8 hours during rush hours but will always completes before 24 hours.
  • Azure Backup provides 99,99 availability SLA for Backup and Restore, monthly based. This is only applicable for the GA product.
  • Currently, two restore options are available
    • To a Virtual Machine : A new Virtual Machine is created
    • To a Storage Account : VHDs can be restored to a Storage Account
  • I expect some features to come with and post GA, but this my own thoughts, since this is what actually implemented with DPM and MABS :
    • Backup/Restore of Files and folders from a VM recovery point
    • Backup/Restore SQL or/and MySQL databases directly from a VM

3- Azure Backup for Azure IaaS limitations

  • Azure Backup does not currently support Premium Storage virtual machines. This feature will released probably during the GA
  • Currently, the daily backup supports 1 recovery point per day ie you cannot backup a Virtual Machine more than once time a day. To achieve this, use the ‘manual backup’ to schedule more than one backup a day. Keep in mind that two simultaneous backups are not supported, so you will need to wait for the first once to compete before triggering the next one.
  • The Azure VM agent and the Backup extension are required to achieve Application or File consistent recovery points. Otherwise, the recovery point will be crash consistent. Be careful of the Azure VM and Backup agents network requirements 
  • The ‘Backup now’ operation does not replace a ‘Snapshot’ mechanism if you want to rapidly restore a VM (The recovery point may take up to 8 hours to be available)
  • Currently, the Restore to a VM is not very customizable : You cannot choose a number of properties like Storage Container, VHDs names, NIC names … To have control of the created VM, you can restore the VHDs to a storage account and use a script or template to create a VM with the configuration of your choice.
  • There is no notification system built-in with Azure backup. So you can’t at this stage configure notifications for the backup jobs statuses. However, there possible alternate methods to do it : When Powershell will be supported, you can create automation scripts which get the Backup jobs statuses and make the notifications. You can also use the Azure Audit logs since the Backup operations are logged within them
  • No Powershell support, but will be released with GA
  • You cannot edit en exiting policy. If you want to change a policy, you will need to create a new one and change the VM’s assignment. Things will change by GA, so no worry
  • You cannot change the vault Redundancy type once you configured at least one backup. You need to change the redundancy  before any data is being transferred to the vault
  • There some limitations about the backup / restore possibilities, I will rephrase here the documentation
    • Backing up virtual machines with more than 16 data disks is not supported.Backing up virtual machines with a reserved IP address and no defined endpoint is not supported.
    • Backing up virtual machines by using the Azure Backup service is supported only for select operating system versions:
      • Linux: See the list of distributions that are endorsed by Azure. Other Bring-Your-Own-Linux distributions also should work as long as the VM agent is available on the virtual machine.
      • Windows Server: Versions older than Windows Server 2008 R2 are not supported.
    • Restoring a domain controller (DC) VM that is part of a multi-DC configuration is not supported.
    • For classic VMs, restore is supported to only new cloud services.
    • Restoring virtual machines that have the following special network configurations is supported through restoring disks to a desired storage account and using PowerShell to attach restored disks to VM configuration of choice. To learn more, see Restoring VMs with special network configurations.
      • Virtual machines under load balancer configuration (internal and external)
      • Virtual machines with multiple reserved IP addresses
      • Virtual machines with multiple network adapters

Azure Backup for Iaas V2 released on Public Preview

Update 2 : MS just confirmed me (but not published) that Azure Site Recovery is supported via the new portal, via Recovery Services

Update : MS released the official documents, I was just announcing here Smile

Great news for Azure IaaS V2 users (ARM). Yesterday, Microsoft announced the release of the Public Preview of Azure Backup for IaaS V2 via ‘Recovery Services Vaults’

This is a quick step be step to rapidly configure your VMs backup

NB : Azure Backup via Recovery Services Vaults will let you backup V1 and V2 VMs (Classic and ARM). It’s recommended that you will use it just to get your hands on and not for Production, since it’s not covered by any SLA or commitment (Preview). MS has not published guides to migrate existing Backup vaults to Recovery Services Vaults, but I think this is planned.

Let’s start:

Login to the Azure Portal ( Go to Browse –> Recovery Services vaults


Click the Add + button


Type a Name for the RS vault, choose a Subscription, a Resource Group and a Region. You need to know that the Recovery Services vault in tied to a Region. you cannot Backup/Restore resources to/from a different region.


After the vault creation. you can discover the different options available. Just for Information : Recovery Services Vaults include Azure Backup services (VMs, Files, SCDPM) and ASR (Azure Site Recovery). ASR is currently on Private Preview and is not yet released. File and SCDP support we come soon too.

To configure a Backup, click on Backup +


Select the Backup type. As mentioned, only Azure Virtual Machine Backup is supported by now


You will now choose the Backup Policy. You can select an existing policy or create a new one.


The policy have the following options:

Name : Type a Name for your policy (Class1, Class2, Class3). Just a recommendation, Do not make naming like ‘Daily’ or ‘weekly’ since the retention may differ for two ‘daily’ based policies

Backup Frequency : There are only two options and a start hour. You can make Daily Backups or Weekly backups

Retention : This is great about Azure Backup since on the same policy you can configure your retention and  long term retention (Daily, Weekly, Monthly and Yearly!!)


Once the Policy is selected, you can choose which Virtual Machines to backup with this Policy. Note that Classic VMs and ARM VMs can be backed up with the same policy.


You can verify that the VMs selected are under the Backup Items blade, in addition to some other information like the Last Backup status, the Policy…


On the Backup Jobs Blade, you can find all the Backup Jobs of all VMs. You can change the period using the Filter Button


This just a teaser, more is coming, try it, you can ask me question on the comments, but as a reminder:

  • Do not use on Production, wait for the GA (Maybe 2 months)
  • ASR is not supported yet
  • A lot of enhancements are coming (User Experience mainly), stay tuned

Move Azure (ARM) VM between Storage Accounts and beyond

Hi all,

One of the hardest operations which I’m actually encountering when working with Azure virtual machines is to move a Virtual Machine from a location to another.

Moving a VM from a location includes :

  • Change the VM’s Storage Account
  • Change the VM’s Storage Container
  • Change from  subscription
  • Change the VM location/Region
  • Change the Virtual Network

You may also want to :

  • Change the VM name
  • Change the VM’s availability set
  • Pass from single NIC VM to multiple NIC VM

or any combination of them.

Today, I’m publishing the first version of the ‘Move-ArmVM’ powershell script which is intended to provide a simple way to move/recreate an Azure Resource Manager VM (Or VMs), covering different move scenarios. The script will  create a copy of the Source VM. The Source VM will only be stopped, no change will affect it.

Move-ArmVM v1.0


  • Move a VM to a different Storage Account
  • Move a VM to a different Storage Container
  • Move a VM to a different Virtual Network
  • Move a VM to another location
  • Move a VM to a different Subscription
  • Change the VM Name during the move
  • Change the VM’s resource Group during the move
  • Change the VM’s availability Set  during the move
  • Pass from single NIC VM to multiple NICs VM ( Annex 1- How to configure the parameter file to have  multiple VNICs on the target VM)

* This script supports moving one or more VMs (Annex  2- How to configure the parameter file to move multiple VMs)

Release Notes

This version does not support moving/creating the next items. You should create them manually after the move:

  • VNIC’s Public IP
  • Tags
  • Load Balancer Configurations
  • Anything not mentioned on the Features section

Download Link

Version 1.0 Preview :

How To use it ?

I highly recommend you to download this JSON editor. It’s free, simple and will help you visualize and edit  JSON files : JSONedit

1- Fill the parameter file

This script uses a Parameters file, you should first fill the required parameters. The parameter file name is hardcoded, do not change its naming and location (the same location than the script). A ‘Logs’ folder will be created on the working directory. The log files will be created under this folder.







The source Subscription Name SamirSub


The source VM Name (The name of the VM to be moved) ADFS01


The source VM Resource Group ADFSRG


The destination Subscription Name
  • BuildSub


  • Set this value to 0 if you don’t want to place the VM in a availability Set
  • Type the name of the target availability set. If the AS does not exist, it will be created
  • 0
  • AdfsAS


  • Set this value to 1 if you want to use the same source VM Name
  • Type another Name if you want that the moved VM have another name
  • 1
  • ADFSVM01


  • Type a name of the resource group when to place the target VM. If the Resource Group does not exist, it will be created under the same region where the VM will be created


  • Set this value to 1 if you want to use the same source VmSize
  • Type a new VM Size (Standard_A1, Standard_A2, Standard_D1…)
  • 1
  • Standard_D1


  • Type the name of the target Storage Account. This Storage Account must already exist
  • vhdsa


  • Type the name of the target storage container, if the container does not exist, it will be created
  • vhd


  • Type 0 if you don’t want to attach an NSG to this NIC
  • Type the name of destination Network Security Group to attach to this VNIC
  • 0
  • ADFSnsg


  • Type the NSG’s resource Group. If the NSG is set to 0, this parameter will be ignored


  • Type the Virtual Network name for this VNIC


  • Type the Virtual Network Resource Group


  • Type the Subnet name for this VNIC


  • Type the IP address if this VNIC

* The value of this parameter is not monitored, if the value is wrong (Inexistent Vnet, erroned IP…), the script will fail. The error can be checked  on the log file

** You can choose to have multiple VNICs on the target VM. Check the Annex for the how to. The VM size must support the VNICs count

2- Run the script

After the configuration of the parameter file, run the script file. You will be prompted for your Azure credentials. The Parameter file name and location are hardcoded and can’t be changed. The parameter file have to be located on the location than the script file

1- How to configure the parameter file to have  multiple VNICs on the target VM

  • Open the parameter file on a text editor
  • Copy the Section between the two brackets, on the VNICs section


  • Paste it just after the closing bracket of the first VNIC (paste it too many times than the VNICs count). On the example, I will paste it two times because  I want to have 3 VNICs on the target VM


  • Add a comma (,) after all the VNICs closing brackets except the last one


2- How to configure the parameter file to move multiple VMs

  • Open the parameter file on a text editor
  • Copy the Section between the two brackets, on the Virtual Machines section


  • Paste it just after the closing bracket of the previous Virtual Machine (paste it too many times than the VMs count). On the example, I will paste it only one time because  I want to move 2 VMs. Add a comma (,) after all the VMs closing brackets except the last one


Add or change an ARM Virtual Machine’s Availability Set

Hi all,

One of the limitations we may encounter when dealing with Azure ARM Virtual Machines is the ability to manipulate the VM’s availability Set configuration after the VM deployment. In fact :

  • You can’t change the VM’s Availability Set once the VM is created
  • You can’t add an Azure VM to an Availability Set once the VM is created
  • You can’t remove a VM from an Availability Set

This is a big limitation since we may need such feature, in different cases:

  • We need to add an existing VM to a highly available pool
  • We want to change the Availability Set name
  • We messed up with the Availability Set  naming

I think this feature will come in the future, but the far or the near future, I have no idea. Maybe by the end of the year (Q4 !)

Till that time, I wrote this Powershell script, which will enable you to manage an ARM VM’s availability Set


  • Add a VM to an Availability Set
  • Change a VM’s Availability Set
  • Remove a VM from an Availability Set

How it works ?

The script will:

  1. Get the VM configuration
  2. Save it to a local location (If something goes wrong, we can recreate the VM)
  3. Remove the VM (Only the configuration, all related objects are kept)
  4. Create a new  VM configuration with the AS config (Add AS, Remove AS, Change AS)
  5. Recreate the VM

How to use it ?

1- Download the script and save it to local location

2- Run it and provide the requested parameters


2- ./Set-ArmVmAvailabilitySet.ps1 –VmName ‘The VM Name’ –ResourceGroup ‘Resource Group’ –AvailabilitySetName ‘As Name’ –SubscriptionName  ‘The Subscription name’


To remove a VM from an AvailabilitySet:

./Set-ArmVmAvailabilitySet.ps1 –VmName ‘The VM Name’ –ResourceGroup ‘Resource Group’ –AvailabilitySetName 0 –SubscriptionName  ‘The Subscription name’



Download Link

Version 1.01 :

Version 1.0 : (Retired)

How to create a Multiple NIC Azure Virtual Machine (ARM)

Hi all,

A lot of people asked me to write a short post of how to create an Azure Virtual Machine with multiple NICs. After some googling an binging, I was not able to find a blog or an article which explains how to achieve it in a simple manner. And here we are !

I- Considerations and requirements

To be able to create a multiple NIC ARM virtual machine, the next requirements should be respected :

  • Not all the virtual machines sizes support multiple NICs. Check if your VM size is supported (
  • The Virtual NICs must be connected to Subnets within the same VNET. You cannot deploy a VM on multiple VNETs
  • You can use Azure CLI, Azure API or Powershell to make this operation. The portal does not provide a way to deploy multiple NIC VM
  • In this post I’m using Azure Powershell 1.0. If you are using the 0.9.8 or prior, remove the ‘Rm’ suffix from your commands and change the mode to ResourceManager. It highly recommended to update to Azure Powershell 1.0 or later
  • To add a NIC to a existing VM, use this post instead

II- Create a Multiple NIC Virtual Machine

Use the  ‘sample’ Powershell script  to create a multic NIC VM. This script will deploy a Windows Server 2012 R2 Virtual Machine from the gallery. Adjust it to deploy other Operating Systems or to add extra configurations like Availability Set, Static IP, Public IP…

The most important step are :

  • The creation of the VNIC resource before the VM creation. 

$VNIC01 = New-AzureRmNetworkInterface -Name $NIC01Name -ResourceGroupName $RGName -Location $Region -SubnetId $SUBNET01.Id
$VNIC02 = New-AzureRmNetworkInterface -Name $NIC02Name -ResourceGroupName $RGName -Location $Region -SubnetId $SUBNET02.Id

  • Adding the VNICs to the VM configuration object. You must set one VNIC as Primary

$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $VNIC01.Id -Primary
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $VNIC02.Id

Download LINK :

How to access an ARM Azure virtual machine from Internet

Hi readers,

Lack of documentation ! This is my starting point for this post. I’m a regular answerer of the Microsoft TechNet forum, and I noticed a repeatable question, or an issue related to the same subject : How to access an Azure Resource Manager virtual machine (RDP, SSH, publish a port…). To avoid repeating the same answer each time I decided to write a post instead. This way, I can just do the  easy Copy/paste (Ctrl c/ Ctrl v)

So what is the goal of this post:

  1. Understand the ways you can access a virtual machine in Microsoft Azure (Azure Service Management vs Azure resource Manager)
  2. Show you how to implement it for Azure Resource Manager virtual machines
  3. Show you how to assign static Public IP addresses to Azure VMs

Before continuing : In this post, I will only talk about accessing an Azure virtual machine from the public network, internet. Accessing a VM from a private network (S2S VPN, P2S VPN, ExpressRoute…) is out of the scope of this reading as it’s considered as an internal access, just like you access a server from your corporate network (The VM is directly exposed to you unless you have a firewall or an NSG)

Suppose you created an virtual machine on Azure. Now you want to access it and you wonder how it’s happening.

I- Azure Service Management (Classic)

With the classic deployment model (which is accessible from both the classic portal and the new portal), when you create a virtual machine, you are forced to deploy it within a cloud service. A cloud service is a container of your VM or VMs like depicted on Picture 1 (You can deploy multiple VMs within the same cloud service).


Picture 1 : VMs and Cloud Services


There are two ways to access a virtual machine in this case (Picture 2) :

  1. We can access a VM by assigning a Public IP address to the Virtual Machine. This IP called PIP belongs to the Virtual Machine  itself
  2. We can access a VM by accessing it through a public IP address assigned to the Cloud Service.This IP called VIP belongs to the Cloud Service and can be used to access all the VMs within the Cloud Service


Picture 2 : VMs, Cloud Services, VIP and PIP

What is the difference between accessing a VM using a PIP or the VIP ?

Using the PIP

It’s clear, the PIP belongs to the Virtual Machine itself, so when you try to access a VM using this IP, your packets will land directly on the VM (Picture 3, Left). The only obstacle between you and the VM is :

  • The VM’s firewall : you have to allow the inbound traffic for the ports you want to access the VM from (Example : 3389 for RDP or 21 for SSH or an application port)
  • A Network Security Group applied to the VM or to the subnet : You have to allow the inbound traffic for the ports wherever you are using NSG
  • ACL : If you are using ACLs, you have to allow the access to the VM also

–> If you are using nothing of the things above, then you can access the VM on any opened port. Look to this link to know how to assign a Public IP address (PIP also called ILPIP) to an Azure VM

Using the VIP

As explained above, the VIP belongs to the Cloud Service, so if you want to access a VM using the VIP, you have to tell Azure about your need. You have to tell Azure for example that if it receives a packet on the VIPx on port Y, it have to redirect it to a VM  (which belongs the cloud service) on port Z. It’s simply NAT. This is achieved using VM Endpoints (Picture 3, right). Like the link explains, you have to configure a VM endpoint each time you want to access a VM on a specific port using it’s VIP. The VM endpoint is simply a NAT rule that Azure adds to the cloud service’s configuration. It’s important to keep in mind that VM endpoints are configured at the VM level but they are related to the cloud service’s Virtual IP (VIP). As you can notice, you cannot access two VMs belonging to the same Cloud Service using the same external port.

PS : Do not forget that the Internal port used when configuring an Endpoint must be allowed (if any) at the VM’s firewall level, NSG or ACL.


Access VIP PIP

Picture 3 : VMs, Cloud Services, VIP and PIP

II- Azure Resource Manager

With Azure Resource Manager, things changed. And the big change concerning us is : No more Cloud Services. So the question is how to access a VM in this case!

There are two ways to access a virtual machine in the ARM case (Picture 4 ) :

  1. We can access a VM by assigning a Public IP address to the Virtual Machine. This IP called PIP belongs to the Virtual Machine  itself*. It’s the same thing than the Classic mode
  2. We can access a VM by using  NAT rules added to a Load Balancer.  This is new in comparison with the classic mode which require an explanation.

* The VM’s network configuration in Azure Resource Manager differs from the classic mode.  The network configuration for a classic VM is hold by the VM itself, which means for our case that the Public IP is hold by the VM. In ARM, things changed. For each VM’s object, a virtual NIC is created and then attached to the VM. This VNIC will hold the Network configuration like the VNET/Subnet, the internal IP and the Public IP address. A VM with multiple addresses (like A3 VMs) will have multiple VNICs attached.


Picture 4 : Access an ARM VM (PIP or Azure LB)

II.1- Using the Public IP address

You can assign a Public IP address to the VM’s VNIC. You can choose to create a new Public IP address or use an existing one.

Via the Azure Portal

Go to the Azure Portal –> Virtual Machines –> Your VM –> All Settings –> Network Interfaces –> VNIC –> All Settings –> IP Addresses –> Public Ip Address Settings. Click on Enable and choose to create or use an existing IP address


Via the Azure Powershell

The following Azure Powershell commands will allow you to create a Public IP Address and assign it the first VM’s VNIC

Function Create-PublicIP ($IPName, $RG, $Region, $AllocMethod, $DomainLabel)


        $publicIP = New-AzureRmPublicIpAddress -Name $IPName -ResourceGroupName $RG -Location $Region –AllocationMethod $AllocMethod -DomainNameLabel $DomainLabel.ToLower()

        return $publicIP


$ELBPublicIPName = Read-host ‘Public IP Address Name’
    $AllocMethod = Read-host ‘Allocation Method (Static/Dynamic)’
    $DomainLabel = Read-host ‘Domain Label’
    $RG = Read-host ‘Resource Group’
    $Region = Read-host ‘Region/Location’
    $VMName = Read-host ‘VM Name’

     # 1- Create the Public IP for the Load balancer

    $ELBPublicIP = Create-PublicIP -IPName $ELBPublicIPName -RG $RG -Region $Region -AllocMethod $AllocMethod -DomainLabel $DomainLabel

    #2- Assign the IP to the VM first IP
    $VM = Get-AzureRmVM | where {$_.Name -eq $VMname }
    $VNIC = Get-AzureRmNetworkInterface | where {$_.Id -eq $VM.NetworkInterfaceIDs[0] }
    $EIPPublicIP = Get-AzureRmPublicIpAddress | where {$_.Name -eq $EIPName}

    $VNIC.IpConfigurations[0].PublicIPAddress = $ELBPublicIP
    Set-AzureRmNetworkInterface -NetworkInterface $VNIC

II.2- Using the Azure Load Balancer

Why it’s so complicated, and why do we need to create a Load Balancer and then create NAT rules :/

To be honest, it’s not complicated and Microsoft did not change anything, they just change  names, and give you more customization. We have to thank them for this. Let me explain the steps to access a VM using this method:

  1. Create the Azure Load Balancer
  2. Create a Backend pool and associate it with the Load Balancer
  3. Create a NAT rule
  4. Associate a NAT rule to a VM’s NIC (VNIC)

II.2.1- Create the Azure Load Balancer

Microsoft provides at no extra cost the ability to deploy Load Balancers which provide load balancing features. More about the Azure Load Balancer here. Keep in mind that he goal of deploying a Load Balancer in our case is to create NAT rules and not load balancing rules. In addition, in our case, we want to create an Internet Facing Load Balancer because we aim to access internal resources from the public internet. This link is the official Microsoft link of how to create an Internet facing Load Balancer.

The following are the steps to create an Internet Facing Load Balancer:

  1. Create a Public IP address resource (If not already created) : In this step, you will create a Public IP address Resource. You can choose between a Static IP (Reserved) or a Dynamic IP, which is subject to change over time. This Public IP will be used to access the Load Balancer, and it’s used on the next step
  2. Create the Front End IP : The Front End IP is the frontal IP for the load balancer. It’s a configuration to which we will associate the Public IP address
  3. Create the Load Balancer resource

The following is a Powershell code to create an Internet Facing LB


$IPName : The Name for the Public IP resource

$RG : The resource Group name where the resources will be created

$Region : Thee location where to deploy the resource (north europe…)

$AllocMethod : The IP allocation method, there are two possible values : Dynamic or Static

$DomainLabel : The DNS prefix for the Public IP. The public IP address will have a  DNS record associated to it of the form : $

$FEName : The name of the Front End configuration

$ELBName : The name of the Load Balancer resource

# 1- Create the Public IP for the Load balancer

   $PublicIP = New-AzureRmPublicIpAddress -Name $IPName -ResourceGroupName $RG -Location $Region –AllocationMethod $AllocMethod -DomainNameLabel $DomainLabel.ToLower()

   # 2- Create the front End IP for the Load balancer using the created Public IP

   $FEConfig =  New-AzureRmLoadBalancerFrontendIpConfig -Name $FEName -PublicIpAddress $PublicIP

   # 3- Create LB
   $ELB = New-AzureRmLoadBalancer -ResourceGroupName $RG -Name $ELBName -Location $Region -FrontendIpConfiguration $FEConfig


II.2.2- Create the BackEnd Address pool

The Backend Address pool will contain the target objects (IPs) targeted by the Load Balancer. If you want to redirect (via NAT) a packet using the Load Balancer to a VM , The VM’s NIC should be part of Backend pool

The following is a Powershell code to create a Backend Address Pool


$BEPoolName : The name of the Backend Address Pool

1# Create the Backend Address Pool

New-AzureRmLoadBalancerBackendAddressPoolConfig -Name $BEPoolName

2# Add the Backend Address pool to the created Load Balancer

Add-AzureRmLoadBalancerBackendAddressPoolConfig -LoadBalancer $ELB -Name $BEPoolName |  Set-AzureRmLoadBalancer


II.2.3- Create a NAT rule

A NAT rule is a very simple and logic rule :

  • Frontal Port or External port : This is the port on which the Load Balancer will listen to incoming requests. It’s the port you will send packets to, when you are connecting from the external.
  • Frontal IP : This is the IP (Public IP) on which the Load Balancer will listen. In fact, this is mandatory since a Load Balancer can have multiple Front End IPs. This is the FrontEnd configuration of the Load Balancer
  • Protcol : tcp or udp
  • Backend Port : This is the Private port on which the service is really listening, and to which the Load Balancer will redirect the traffic

The following is a Powershell code to create a NAT rule and associate it to the Load Balancer


$NATName : The name of the NAT rule

$Prot : tcp or udp

$FEport : The frontal port o the public port

$BEPort : The Backend port or the Private port

# Create and add a NAT rule to the Load Balancer

$ELB | Add-AzureRmLoadBalancerInboundNatRuleConfig -Name $NATName -FrontendIpConfiguration $FEconfig -FrontendPort $FEport  -BackendPort $BEPort -Protocol $Prot

$ELB | Set-AzureRmLoadBalancer

II.2.4- Associate a VNIC with a NAT rule

This is the final step. You can notice that during all the previous step, the Backend IP was not set. The Backend IP is the IP of the VM. With Azure Resource Manager, it actually means the VNIC.

The following is a Powershell code to get a VNIC resource, add it to the Backend address pool and add it as a target of the NAT rule

$VNIC = Get-AzureRmNetworkInterface –id ‘VNIC id’

$VNIC.IpConfigurations[0].LoadBalancerBackendAddressPools = $BEPool

$VNIC.IpConfigurations[0].LoadBalancerInboundNatRules = $NATRule

$SetVNIC = Set-AzureRmNetworkInterface -NetworkInterface $VNIC


As a BONUS, I uploaded here a ‘preview’ script containing all the previous commands. This script is interactive, and will let you create an End to End NAT rule using an Azure Load Balancer or assign a Public IP address to a VM’s NIC

Download it and just run it –>

NB : Please, read the release note of the script