Design Azure Private DNS Zones when using Private Links or any other scenario


Private Endpoints and Private Links are powerful services provided by Azure to allow you access PaaS services (Azure SQL, Azure Storage including Data Lake Gen2, Azure Web App…) via an IP address in your own network (your own Virtual Network).

See here an introduction of Private Endpoints / Private Links:

Supported Azure PaaS Services:

1- Is using Azure Private DNS a requirement ?

Unlike many are thinking, using Azure Private DNS is not required if you want to use PE/PL, but it’s recommended as it provides first party integration allowing your PE Private IP record to be automatically created in Private DNS zone, for future DNS resolution

2- What Zone name do i need to use for PE/PL ?

Microsoft is ‘weirdly’ recommending using a specific Zone name for PE/PL (The full list can be found here). The following table shows some DNS zones for some services:

Private Link resource typeSubresourceZone name
SQL DB (Microsoft.Sql/servers)Sql Server (sqlServer)
Azure Synapse Analytics (Microsoft.Sql/servers)Sql Server (sqlServer)
Storage Account (Microsoft.Storage/storageAccounts)Blob (blob, blob_secondary)
Storage Account (Microsoft.Storage/storageAccounts)Table (table, table_secondary)
Storage Account (Microsoft.Storage/storageAccounts)Queue (queue, queue_secondary)
Source: Microsoft

I’m saying ‘weirdly’ because we have found a scenario where this is unsupported.

The following picture shows:

  • Project Source: A VM deployed to VNET Source
  • Project A: A Storage Account SA1 with a PE/PL in VNET A and registered in the Private DNS Zone
  • Project B: A Storage Account SA2 with a PE/PL in VNET B and registered in another Private DNS Zone (In fact Project A and Project B are independent, and it’s supported to create multiple private dns zones with the same name


  • If VM in VNET source wants to solve SA1 PL, the solution is to link VNET Source to the prive DNS Project A –, so any resource in VNET Source can solve records
  • If VM in VNET source wants to solve SA2 PL, the solution is to link VNET Source to the prive DNS Project B –, so any resource in VNET Source can solve records –> This is not supported since a VNET cannot be linked to 2 Private Zones with the same name

-> Microsoft recommendation is not recommended in fact, because this will create future issues. It’s like creating VNETs with the same address space, and then to peer them : Unsupported

3- Design Azure Private DNS Zones

The design recommendation is simple: Each Project (The scope of how resources are managed by the same team) must have its own DNS Zone.

In order to achieve this, you can use the following rules:

  • Choose a base domain (root domain) to be used by all the company’s projects. For example, your company came is CLOUDCASE, your root domain can be
  • Ask each project to create a Private DNS Zone using the format {project name or project code}.RootDomain or *.{project name or project code}.RootDomain
    • Project Avalon (code AVAL) can only create Private DNS zones like
    • Project DEVON(code DEVO) can only create Private DNS zones like

That’s it. Now you are sure that all your proejcts have unique private dns zones. I highly recommend that you create Azure Policies that enforce your naming conventions


Creating a PE/PL via the Azure Portal currently only shows the Private DNS zones with the recommended names, which makes you believe that a different naming is not supported.

In order to ‘hijack’ this behavior, use different deployment method than the Portal (ARM templates), or continue with the wizard and stop in the last step (do not deploy).

  • Click Download a template for automation
  • Click Deploy
  • Go to Private Dns Name and type a existing Private DNS Zone and the Resource Group. Then click Purchase

How to deploy a Resource via ARM Templates even if it’s not documented ?


Recently, i tried to enable the Update Management Service in Azure Automation via ARM template. Not very complicated, many blog posts and examples can be found over the www.

But what i have not found anywhere is how to to create an Update Deployment Configuration via ARM template (what you see in the picture)

After about 10 minutes of searching the net, i decided to to it myself. But the question is : if it’s undocumented, how can i guess the ARM template json definition?

Two questions arose:

1- Is this supported via ARM templates?

2- How to do it in case it’s supported?

Since no documentation can be found, question 1 answer can be hard to find, but if i answer question 2 and test it, i can answer my question 1.

1- What are ARM templates after all?

Long story short, all ARM deployments are basically Rest API calls, so any ‘operation’ is supported through Rest API. ARM templates are just the Rest API content (the Body of the Rest call, for POST Requests).

So when you write an ARM template, you create the BODY of the Rest call and you send it to Azure. Azure will use it under the hood to create the Rest calls and bingo.

NB: i’m not sure whether the Template to Rest is made at client side (powershell, cli) or at server side, but this is not important in our case.

So the KEY here is that: If you can get the Rest Call Body, you can ‘probably’ get the ARM template JSON definition.

NB: Before continuing, try first to export the ARM template of your resource or resource group and look if you find the JSON definition of your resource. If you don't find it, go to section 2

2- How to get the Rest API Body content?

There are many ways to get this:

  • You can use ARMclient
  • You can use dev tools in the Azure Portal
  • You can use any tool that can unwrap a http request and let you see inside (your favorite tool)

3- Getting the Body Content using the Azure Portal

In my example above, my goal is to create an Update Management Deployment via ARM template, so i started like the following:

1- Go to the Azure Portal and use the wizard to create the UMD, but before submitting the creation b(Create Button) , make step 2

2- Use the Dev Tools (F12 in chrome and Firefox) and start recording a session

3- Submit the creation (Click Create in my case)

4- Stop the recording

5- Find the request that contains the Rest call for your operation

6- Take the following information:

  • Resource Type: It’s contained in the Request URL. In my example it’s Microsoft.Automation/automationAccounts/softwareUpdateConfigurations
  • api-version
  • Body: It’s contained in the Request Paylaod. You can use the ‘view source’ to get the Json definition directly. It contains the name of the resource and the Properties

4- Authoring your ARM template

I will not go through the ARM template Authoring, but you know, prepare a basic ARM Template with parameters and Resources at least (resources is the only needed part actually)

A resource json definition in an ARM template has usually the following format

	"$schema" : "",
	"contentVersion" : "",
	"parameters" : {},
	"variables" : {},
	"resources" : [
			"type" : "",
			"dependsOn" : [],
			"apiVersion" : "",
			"name" : "",
			"location" : "",
			"properties" : {}

Here the view with Json Edit (

Now, you guess it, fill the blanks:

That’s it, you achieved 95% of the ARM template, now you need to adapt it to your context (add parameters, variables, concat, functions if needed…)

5- Deploying the ARM template

Now, you can deploy your ARM template and have the answer to question 1 (in fact, we are not yet sure that this is supported through ARM templates, even if it’s supported via Rest API)

I don’t have the screenshot, but the deployment was successful, and i was able to author an ARM template even if no documentation is provided. This is great!

Introduction to Azure Private Endpoints

Azure Private Links and Endpoints have been recently announced in Public Preview after months of Private Preview and testing. Private Link/Endpoint is a huge step in Azure Networking as it allows to make private any internet facing public service (Like PaaS services: Azure SQL, Azure Storage…), and provides a unified way to expose and consume services between tenants, partners or even within the same customer.

This post is an introduction of Private Endpoints

1- Concept

There are two terms that should be memorized:

  • Private Link: See my next blog post
  • Private Endpoint: Is an association (couple) of a supported resource (ex: azure sql server) and a Subnet in your virtual network so it can be assigned a private IP address

2- Example Scenario

2.1- Need

One of the easiest/most requested scenario is the ability to each an Azure SQL Database privately from a Virtual Network, without exposing it to Internet, or using its Public IP address.

The following picture shows a Virtual Machine (SQLClient) deployed to a VNET/Subnet (VNETEastUS/VM), and an Azure SQL DB (azuresqlprivatedb01) deployed within an Azure SQL server (azuresqlpriavte).

The goal is that the VM (SQLClient) reaches the azuresqlprivate over a private connection, and not via internet (we will not allow any IP to consume the Azure SQL server through the firewall): The dotted line in orange is the goal

2.2- Solution via Private Endpoints

The solution is to create a Private Endpoint that will expose the Azure SQL server via a Private IP address on a Subnet. The following picture shows a Private Endpoint (PE) that is using an IP address from the Subnet Privatesubnet and connected to azuresqlprivate

2.3- Deploy the Solution via the Azure Portal

1- Go to the Private Link Center –> Private endpoints –> Add

2- Type the required information like the Subscription, RG, Location…

3- Choose the resource that you want to create a Private Endpoint for (In my case, it’s the azuresqlprivate Azure SQL server

4- Choose a VNET/Subnet that will enable the access to your resource. Under the hood, a Network Interface (NIC) will be created, assigned an IP address and assigned to your resource. You can optionally integrate the resource with an Azure Private DNS Zone in order that you can call the private endpoint using a DNS name. This is not required as you can create your own DNS record on your own DNS service (A record)

5- After the deployment, you will notice the following:

  • The Private Endpoint is created an the Connection State is Approved*

* Approved means that the Azure SQL party has approved the Private Endpoint, this is useful when both parties are not from the same Team/Tenant, where the requester can ask for the Private Endpoint connection, and waits for the owner to approve it. In addition, you can Reject the connection at any time

  • A NIC has been created and deployed to the Subnet
  • A DNS record has been created (in case you have enabled private DNS option)

2.4- Test the Private Endpoint

On the SQLClient Virtual Machine, you can install SQL Server Management Studio and test the access to the DB

Note that the Private IP is resloved

2.5- Secure the access to the Private Endpoint

Now that we have private access to a PaaS Service, there amy ways to secure the access to it:

  • Use Network Security Groups for the PE Inbound: You can create an NSG and apply it to the Subnet NIC or the Private Endpoint NIC, and filter Inbound rules like any other NSG –> Looks like this not yet supported on the Public Preview
    • Applying a NSG to the NIC is not supported
    • Applying an NSG to the Subnet is without any affect on Private ENdpoints
  • Use Use Network Security Groups for the Outbound: You can filter outbound traffic from your sources to your Private Endpoints: This is supported but not convenient, since it’s better to filter at the destination and not a the source, when securing access from a Destination standpoint (The picture shows a rule that blocks access to the private IP of the private endpoint, and applied to the SQLClient VM)
  • Since the IP address of the Private Endpoint is within your VNET, you can filter access to it on your perimeter Firewalls, like Azure Firewall or your own Firewall

3- Private Links

The next blog post will introduce the Private Link concept, which is a service that allows your external customers/partners to securely access your services via a private connection, and using an Approval Process.


Delete Azure Backup Restore Points collections error : InternalOperationError goal seeking tasks failed


During an operation to move Azure resources between Subscriptions (Or resource groups), we were obliged to delete the “Microsoft.Compute/restorePointCollections” in order to be able to move VMs protected by a Backup policy, as described here

Unfortunately, when deleting the
“Microsoft.Compute/restorePointCollections” resources, we were hit by the following error.

 {X} goal seeking tasks failed. 

It took us time to figure out that trying to delete the same resources multiple times ends by a successful operations. But because each operation took about 1 minute, it will be a waste of time of doing it by hand.

So today, i’m sharing with you a Powershell script that will allow you to make all the deletion operations, in parallel!!

Go here

Get Azure Datacenter IP ranges via API V2


In my previous post, I showed how to create a light-weight Azure function that allows you to request the Azure Datacenter IP ranges via API. You can rapidly test it by following the instructions on the section 3- Try it before deploying
it here :

The feedback was positive, but a lot have asked for a way to see if there were updates compared to the last version, and what the updates are if any.

In this post, I will publish the second version of the API (with the how-to), that allows you to :

  • Get the current Azure Datacenter IP ranges
  • Get the current Azure Datacenter IP ranges for a specific region
  • Get region names (since, unfortunately, the region names published by Microsoft are not exactly the same used by the Microsoft Azure services)
  • New : Get the current version ID of the Azure Datacenter IP ranges
  • New : Get the previous version ID of the Azure Datacenter IP ranges
  • New : Get the difference between the current and the previous version for all regions
  • New : Get the difference between the current and the previous version for a specific region

The new features will allow you an easy integration with your environment, and simplify the update of your Firewall rules within your infrastructure.

  • 1- How to request the API ?

The API supports only POST requests. You can make the following API requests using the following body construction.

Here the examples using Powershell, but you can use any tool to request the API using the same body content


#Get the current Azure IP address ranges of all region

$body = @{“region”=“all”;“request”=“dcip”} | ConvertTo-Json

#Get the current Azure IP address ranges of a specific region, example europewest

$body = @{“region”=“europewest”;“request”=“dcip”} |ConvertTo-Json

#Get the azure regions names, that we can request IPs for

$body= @{“request”=“dcnames”} |ConvertTo-Json

#Post the request

$webrequest=Invoke-WebRequest -Method “POST” -uri ` -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

#New in V2

#Get the (added and/or removed) IP address ranges updates of a specific region

$body = @{“request”=“getupdates”;“region”=“asiaeast”} | ConvertTo-Json

#Get the (added and/or removed) IP address ranges updates of all regions

$body = @{“request”=“getupdates”;“region”=“all”} | ConvertTo-Json

#Get the current Azure DC IP ranges version ID

$body = @{“request”=“currentversion”} | ConvertTo-Json

#Get the previous Azure DC IP ranges version ID

$body = @{“request”=“previousversion”} | ConvertTo-Json

#Post the request

$webrequest Invoke-WebRequest -Method “POST” -uri ` -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

  • 2- How to build the solution ?

2.1- Solutions components

The V2 version is still using only Azure Functions, but unlike V1, it uses multiple functions within the Function App:

  • 1 Function App
    • Function 1
    • Function 2
    • Function 3
    • Proxy1
    • Proxy2
    • Storage Account

The following table details each component configuration. If you want to create the solution within your environment, create the same components using the given configuration:

Function App



App Service Plan

azuredcip This Function App will host the entire solution. It will include 3 functions, 1 Storage Account and two Proxies Shared or greater. Use at least a Basic Tier to benefit from SSL, Custom Names and backup







azuredcipranges This function will return you the V1 information.
HttpTrigger – Powershell
Allowed HTTP Methods : POST
Authorization level : Anonymous
You can add Function Keys if you want to secure the API Access. In my case, my API still Public (anonymous) to continue support my V1







azuredciprangesupdater This function will do the following :
– Get the current Azure DC IP ranges version and store it to the storage account

– Always keep the previous Azure DC IP ranges version file in the storage account

– Create and store a file containing the current and previous files difference and store it to the storage account

– Return the mentioned information based on the API request body

HttpTrigger – Powershell
  1. Inputs (Type : Azure Blob Storage)
Name Path SA connection
vnowinblob azuredcipfiles/vnow.json AzureWebJobDashboard
vpreviousinblob azuredcipfiles/vprevious.json AzureWebJobDashboard
vcompareinblob azuredcipfiles/vcompare.json AzureWebJobDashboard
  1. Outputs (Type : Azure Blob Storage)
Name Path SA connection
vnowoutblob azuredcipfiles/vnow.json AzureWebJobDashboard
vpreviousoutblob azuredcipfiles/vprevious.json AzureWebJobDashboard
vcompareoutblob azuredcipfiles/vcompare.json AzureWebJobDashboard

Keep the default http output

Allowed HTTP Methods : POST

Authorization level : Function

You can use the default function key or generate an new key. This API will not be directly exposed, so you can protect it with a key





triggerazdciprangesupdate This function will trigger the azuredciprangesupdater weekly to update the current and previous version TimerTrigger – Powershell
Schedule : 0 0 0 * * 3

(Each Wednesday, but you can choose any day of the week, as Microsoft will not apply the updates before one week of their publication)

Proxy 1



Root template

Allowed HTTP methods

Backend URL

getazuredcipranges This proxy will relay requests to azuredcipranges /getazuredcipranges POST
(add the key if you have secured it)

Proxy 2



Root template

Allowed HTTP methods

Backend URL

getazuredcipupdates This proxy will relay requests to azuredcipranges /getazuredcipupdates POST

Storage Account






This is the storage account automatically created with the Function app (it can have any other name) azuredcipfiles Upload the following files:
– vnow.json

– vprevious.json

NB : These files are fake files. During the first API update request, the vnow content will be copied to the vprevious file. The vnow content will be then replaced by the real current version. At this moment, you can only request the current version. After one week, a new version of the file will be published by MS, so another cycle will set the vnow and the vprevious to real 2 consecutive versions, so you can benefit from the update and comparison feature.

2.2- Download the files

You can download the needed files here, you will find the powershell code for each function (function1, function2, function3) and the two json files (vnow.json and vprevious.json).

NB : As mentioned before, after the first request to the API (getupdates), you will have a valid vnow version, but the previous version will be the version uploaded now. You need to wait at least 1 week to have the valid version.


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

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


Azure Virtual Machines introduction

This post aims to introduce Microsoft Azure IaaS (Virtual Machines service) to folks who were not involved from the beginning with Azure and who would like to rapidly understand how it works, and if it can convince them start or even think use it. In this post, I will not detail the IaaS features in Microsoft Azure, since we have hundreds of them, and there is books and long articles describing in details the Azure fundamentals.

This post is divided like below:

  1. Introduction : I will rapidly introduce the Azure Virtual Machines service (IaaS)
  2. Components : This is the principal part of this post, I will detail the components and bricks of the Azure Virtual Machines services. It will help you understand how the Azure IaaS can be used and what to consider before deciding to go with the Azure Virtual Machines service.
  3. Networking : I will explain the networking concept in Azure
  4. Storage : I will explain the storage concept in Azure
  5. Pricing : I will explain how the Azure pricing works
  6. Design considerations : I will put some design considerations and must-remember points
  7. Further Reading : I will post some interesting resources and readings to go deep and dive into Azure.


Azure Virtual Machines is one of the central features of Azure’s IaaS capabilities. Azure Virtual Machines supports the deployment of Windows Server or Linux virtual machines (VMs) in a Microsoft Azure datacenter. You have total control over the configuration of the VM. You are responsible for all server software installation, configuration, and maintenance, as well as operating system patches. All the resources are running within the Microsoft Datacenters, the only link to them will be networking. Think of it like you have your own datacenter in another location or region from you on-premise. You create all your workloads there and you access them remotely. The only difference here is :

– The Datacenter belongs to Microsoft

– All the underlying management, updates, maintenance are  Microsoft’s responsibility (Hardware, Networking, Cooling, Power…)

– The physical security are Microsoft responsibility

The result is : Microsoft offers you a feature ( A service) that enables you to create virtual machines and use them freely, just like they were yours, and they are yours.

I would loved to continue introducing the Azure Virtual machines feature, because it’s amazing and very interesting. I will dedicate a full post just for discussing the ‘what and why ‘about Public Cloud Platforms (Iaas Offer) and is it reasonable to go forward toward this new concept.



The compute component is the heart of Azure VM. Compute mean  the virtual machine resources : CPU, Memory and Operating System

When you create a virtual machine in Azure, you will choose first the VM configuration : Hardware and Software (Example : I want to deploy a Windows Server 2012 R2 Datacenter VM with 4 GB of RAM and 2 CPU). Look that I’m not mentioning the storage configuration (OS disk size, number and size of data disks). This is intentionally and will be explained further.

Azure does not give you the possibility of freely choosing the hardware configuration. In fact, Azure exposes predefined templates to choose from. These templates are classified into Virtual Machine series and sizes. The complete Virtual Machine sizes list can be found here and it’s regularly updated by Microsoft in case of a change. LINK1 : Azure Virtual Machine Series and Sizes

The Virtual Machines in Azure can be classified by :


The tier is a categorization of the virtual machine type. There are two Tier types in Azure : Basic tier and Standard tier. Basic tier VMs are generally used for test/dev and less important VMs. Basic Tier VMs are spreadly used for production environment. The difference resides in the following things:

– Basic Tier VMs do not support Azure load balancing capabilities (you cannot load balance traffic between two basic VMs using the Azure load balancing feature)

– Basic Tier VMs do not support the Azure ‘Autoscale’ feature. ‘Autoscale’ allows Azure to automatically scale the number of virtual machines to meet resource requirements (CPU usage for example) and then scale down by shutting down VMs when scale conditions are no longer crossed

– Not all the hardware configurations are given with the Azure Basic tier VMs. Advanced hardware configurations (more and faster CPU, more and faster memory, more disks, faster temporary disks,  more performance…) are just provided with Standard tier VMs

– Basic VMs data disks IOPS is capped a 300 IOPS per disk, less than the 500 IOPS for the standard tier ( storage will explained in details  later in this article)


The series is classification to help the customer rapidly find and choose between tens of virtual machines types. It’s like the classification that we find in car vendors : Mercedes Class A, B, C, E and S or BMW  Series 1, 3, 5 and 7 Smile. Till today, there are 4 Azure Virtual Machines Series : The A-Series, D-Series, DS-Series and G-Series:

  • A-series: A-Series presents ‘normal’ and ‘classic’ virtual machine class. They are intended to the majority of workloads. Only the A-Series provide the Basic tier classification
  • D-Series: D-Series presents enhanced VM’s underlying hardware. VMs are provisioned on  top of better physical servers using faster processors, faster disk cache and more storage support. They provide also the capability of using offloading network technologies to communicate over a low latency, high throughput network in Azure.    LINK2 : D-Series Virtual Machines Sizes
  • DS-series: DS-series is the only Azure VM series that let you benefit form the Azure Premium Storage (Storage in Azure will be discussed later). It mainly intended for workloads that need high performance and low latency  storage.
  • G-series: This is the last announced Azure Series, it provides powerful VM’s hardware configurations (High specifications). Underlying hardware  uses better CPU and memory brands. It is mainly intended for giant workloads (can provide hundreds of GB of RAM). LINK 3 : G-Series Virtual Machines Sizes


The Size of a virtual machine means its hardware configuration. In Azure, the hardware configuration counts 4 elements :

CPU : The virtual processor count

Memory : The amount of RAM allocate do the virtual machine

Temporary or Local storage : The size of a temporary storage allocated to the virtual machine. It’s an attached disk that can be used for storing temporary (volatile) data during the virtual machine running time. The content is lost in any case the virtual machine is stopped (Planned or unplanned)

Number of supported data disks : Each virtual machine size has a maximum data disk count. For example, you can attach a maximum of 4 data disks (Data VHDs) to a Standard A2 VM while you can attach 16 to a A4 VM. This is very important since the maximum size of a data disk is 1 TB (1023 MB), for example you cannot have have a 5 TB volume using an A2 VM (4 disks of 1 TB with stripping will give you a maximum of 4 TB volume)

Operating system

Microsoft provides a wide range of operating system images. Both Windows and Linux are supported. In addition, pre-configured images can be found like Windows + SQL or Linux + Apache. Images can be found on the Azure VM ‘Library’ or on the VM depot. Moreover, Azure allows you to bring your VMs and run them in Azure. You can upload VHDs to Azure and then use and deploy them (Of course, the VM OS need to be supported by Azure). There is no maintained link that list the supported operating systems in Azure. However, till the writing time of this article, here the actual supported OS :

Cloud Service

When you create a virtual machine in Azure, this virtual machine is provisioned as part of a cloud service. Several virtual machines can be part of the same cloud service, this will let you create load balanced services between virtual machines. You will not be able to use Azure ILB (Internal Load Balancing) if your VMs are not within the same cloud service and the same virtual network

Important notice : With the introduction of Azure Resource Manager that goes GA on  June 30 (ARM GA Announcement) for a set of Azure features, Cloud Services are no longer needed if you use the ARM stack for your VM deployments.

Load Balancing

Azure provides load balancing features for its virtual machines services. You can  use the load balancing features to distribute traffic between VMs whether these VMs are internet facing or not. The load balancing features can load balance level 4 traffic and support only tcp and udp traffic. As discussed earlier, the load balancing is only supported on VMs part of the same cloud service. The following link gives a good description of the Azure Load Balancing feature LINK 5 : Azure load balancing

Important notice : With the introduction of Azure Resource Manager that goes GA on  June 30 (ARM GA Announcement) for a set of Azure features, Cloud Services are no longer needed if you use the ARM stack for your VM deployments.

Affinity groups

Affinity groups are a way to point to a fixed set of physical servers located near each other in the same region. In the past, affinity groups were a requirement for creating virtual networks (VNets). At the time, the network manager service that managed VNets could only work within a set of physical servers or scale unit. Recent architectural improvements have increased the scope of network management to a region. As a result of these architectural improvements, affinity groups are no longer recommended or required for virtual networks. The use of affinity groups for VNets is being replaced by regions. Virtual networks that are associated with regions are called regional VNets. Affinity groups are deprecated, this is why I will not explain their usability.

Availability Set

There are two types of Azure platform events that can affect the availability of the virtual machines: planned maintenance and unplanned maintenance. Planned maintenance does not generally affect the availability of the Azure virtual machines, but my sometimes require you to reboot your VMs. Unplanned maintenance may not be referred to maintenance but to unplanned service disruption caused generally by the underlying hardware failure. To guarantee the Azure SLA (actually 99.95 % service time), it’s highly recommended to always create highly available workloads that can be achieved by redundant services. Clustering, Built-in clustering and Load balancing are sort of high availability paths. However, it’s important to guarantee, that at a given time, a set of highly available VMs (clustered, Load balanced…) are not under the same fault domain (A fault domain is a set of resources that share the same Single-point-of-failure), this is why the Availability Set configuration was provided. Two or more VMs under the same ‘availability set’ will be placed on different fault domains. In case of planned or unplanned maintenance, at least one VM is guaranteed to be kept up and running. VMs must be under the same cloud service to be able to join an availability set configuration. More information can be found here LINK 6 : Azure virtual machines high availability

To resume

When you plan to create a virtual machine in Azure, you need to know the target virtual machine specification and then choose between the different Tier/Series/Size. Keep in mind the following points:

  • You can at anytime change the virtual machine type. You can scale up or scale down (from a hardware configuration perspective) the configuration at any time. But you need to respect the target VM’s type requirements. For example, you cannot change from a DS-Series to another series if you are using Premium Storage or you cannot pass from an A4 VM with 16 disks to an A3 VM, because A3 supports a maximum of 8 data disks. You can rarely encounter issues with the VM configuration changes, you can refer to this post for more information LINK 5 : Azure VMs sizes considerations
  • Only few Azure VMs support more than one network adapter : [ 4 NICs : A4, A7, A9, D4, D13, G4] [2 NICS : A3, A6, A8, D3, D12, G3]
  • VM pricing depends on the three classification: Tier, Series and Size. The more the configuration and options are better, the more the VM is expensive (Pricing will be discussed later in this post)
  • Notice that the storage usage and network throughput is not part of the VMs classification, and hence on pricing. Storage and network usage are billed separately
  • For all your ‘normal’ virtual machines that do not require load balancing and special performance, use the Basic tier VMs : It’s more affordable



Virtual Networks

Virtual networks (VNets) are used in Azure to provide a layer of security and isolation to your services. VMs and services that are part of the same virtual network can access each other. By default, services outside the virtual network cannot connect to services within the virtual network. You can, however, configure the network to allow access to external services:

  • A virtual network is a closed logical network boundary ( It’s like a network in a physical network architecture)
  • 2 virtual networks cannot natively communicates even if they are within the same region. A Vnet to Vnet connection must be configured to let they communicate (Using VPN)
  • All traffic within the same virtual network is by default permitted. However, Azure provides a security layer that let you configure ACLs between virtual machines or  subnets (will be discussed later)
  • VLANs are not supported nor understood by virtual networks, in fact Azure virtual networks are layer 3 networks for the tenant perspective.
  • Only tcp, udp and icmp protocols are supported within Azure virtual networks
  • Virtual networks support cross premises connection : You will be able to connect you on-premises network to an Azure virtual network for example
  • Virtual Networks are regional scoped, and hence, your virtual network can span all the datacenters within the same region (In the past, Virtual Network are datacenter scoped, and you can be in the situation when you want to provision a virtual machine on the same region but you can’t connect it to a virtual network, even if it created on the same region)

You can read the TechNet FAQ for more information: LINK 6 : Azure Virtual Networks FAQ


When creating a virtual network the following information should be provided :

– Location [Mandatory] : In which region the virtual network will be created

– DNS Servers [Optional] : Azure will be responsible for assigning the IP addresses for your VMs (Of course it will pick up IP addresses from a pool that you provide). You can hence provide the DNS servers that will be configured for this virtual network and that the VMs within it will use. DNS servers are configured per virtual network.

– Address Space [Mandatory] : Each created virtual network must be configured with at least one virtual network address space. The virtual network address spaces contain the IP addresses fields that this virtual network  provides. You cannot assign a virtual machine, an IP address that is not included in the virtual network address spaces ranges (Imagine like you are defining a network on your switch where you assign it a network address)

– Subnet [Mandatory] : The Address Space range cannot be used directly by Azure. At least one subnet must be defined per Address Space. You can choose to divide the address space into several subnets or use a single subnet per address space (a subnet range that will fit the entire virtual space).

NB: Azure Virtual Networks support both Public and Private IP addresses ranges (CIDR notation), this will permit you to bypass the RFC-1918 limitation. However, cross-premises virtual networks (that will be connected to on-premise or to another virtual network using VPN or Express route) must respect the RFC1918 IP ranges. In other words, only the Cloud-Only virtual networks can use non RFC-1918 IP addresses

When creating a virtual machine, you can choose to connect it to a virtual network, and choose which subnet will be used to pick up an IP address from. Azure will configure this IP address for your VM, and it will appear as a static IP address on your guest OS (Not a DHCP_reservation-like). On the same time this IP address is not static, that means it can be cases where the IP address will change. Discussing the cases and how to fix  permanently and IP address will be discussed later in the Design considerations

Cross-Premise connection

Azure provides different ways for interconnecting the Azure virtual network to the local on-premise network. The following are the actual options provided by Microsoft:

  • Site-to-Site VPN : S2S VPNs can be established between an Azure Virtual Network and an On-premise network (called Local Network). The S2S VPN is established between two parties, between an Azure Gateway and on-premise VPN device. Establishing a site to site VPN will allow your on-premise resources to communicate with your Azure resources. Actually, Microsoft provides 3 Azure gateways that offer different features and different prices. On-premises VPN devices should  respect the minimum gateway requirements presented here. Microsoft also maintain a lit of known compatible devices
  • Point-to-Site VPN : Azure supports establishing VPNs from a client perspective. A Point to Site VPN will allow individual clients to connect from anywhere to the Azure resources. actually, only Windows clients can establish a point to site VPN to Azure
  • ExpressRoute: Azure ExpressRoute enables you to create private connections between Azure datacenters and infrastructure that’s on  premises. ExpressRoute do not use public internet to transmit  data. Unlike VPNs, ExpressRoute uses a private circuit. ExpressRoute offers many benefits specially  speed and SLA. For additional information, you can read more here LINK7 : Azure ExpessRoute

Security in Azure Networking

Azure provides different options to secure the inter and intra communication within the Azure virtual networks. However, there are many considerations to better chose which option to use :

  • When a virtual machine is created and connected to a virtual network, it is able to communicate with all the virtual machines within the same virtual network.
  • When a virtual machine is created and connected to a virtual network, external inbound connections (external to the virtual network) are not allowed except for two services (configured by default) : Remote Desktop Connection and Remote PowerShell. Allowing/Denying inbound traffic is conducted via two options :
    • Endpoint : An endpoint is a mapping relation between  two ports, a Public port and a Private Port. The Public port is the port on which the virtual machine will listen for traffic from external networks, the Private port is the port on which the service is really listening on the virtual machine. The Public/Private couple is a port redirection rule. Of course Public and Private ports can be the same.
    • ACL : When an Endpoint is configured for a virtual machine (Example :  Public Port A, Private Port A), an access rule is automatically added to the access rule list for that virtual machine allowing external communication on that Public port. To limit access from different external sources, access rules can be added to limit the inbound connection form defined sources.  Access rules can be explicit allow or explicit deny rules (Example : Allow only inbound connections on Public Port A from the external subnet and Deny inbound connections on Public Port A from the external subnet  ).

The following link shows how to set up endpoints for Azure virtual machines  LINK8 : Azure VM’s Endpoints. More information about Azure Virtual Machine’s security can also found here

There is another option that was added and that leverage more flexibility that the Endpoints and ACL concepts. In fact, as discussed, Endpoints are only applicable for external inbound traffic. The second feature allow you to create rules within the virtual network. It’s called Network Security Groups (NSG).

NSG is a powerful feature that allows you to :

  • Define security rules for a single virtual machine
  • Define security rules for a virtual network subnet

To resume, you can create ACLs using a 5   pattern (Source IP, Source port, Destination IP, Destination port, protocol) and apply them to a single virtual machine or to an entire subnet. This is similar to rules that you define for an inter-VLAN communications. This permits the creation of different security zones within the same virtual network (like a DMZ zone). NSG is supported with the local networks (On-Premise networks). The following link describes better the Azure Network Security Groups feature. LINK 9 : Azure Network Security Groups


By default, any virtual machine that is connected to a virtual network can access Internet. If you do not specify DNS server names on your virtual network configuration, default Azure DNS servers will be configured to permit name resolution. If your virtual network uses custom DNS servers, those DNS servers should resolve internet names if internet access is desired. If you want to restrict internet connection on your virtual network, you can use Network Security Groups to set per VM or per subnet denying rules.


Storage is the third key component  in the Azure IaaS infrastructure. Storage includes any sort of service where we can store data (Tenant data). There are many storage services in Azure (Look here for the complete documentation)  but for an Iaas perspective only one or two services are involved : Blob storage and File storage.

Blob Storage

To avoid reinventing the wheel, I picked up the following introduction from this link. Azure Blob storage is a service for storing large amounts of unstructured data, such as text or binary data, that can be accessed from anywhere in the world via HTTP or HTTPS. You can use Blob storage to expose data publicly to the world, or to store application data privately.

Common uses of Blob storage include:

  • Serving images or documents directly to a browser
  • Storing files for distributed access
  • Streaming video and audio
  • Performing secure backup and disaster recovery
  • Storing data for analysis by an on-premises or Azure-hosted service

There are tow types o Blob storage:

  • Block blob storage : For streaming and storing documents, videos, pictures, backups, and other unstructured text or binary data.
  • Page blob storage : Optimized for random read and write operations, page blobs are ideal for VHD images. This blob type is used for the virtual machine storage and will be discussed on this section

Page Blob storage is commonly used to store Azure virtual machine files including operating system disks and data disks. There are two types of storage provided for virtual machines today : The Standard Storage and the Premium Storage. The difference between the two types is performance.

  • To be able to use the storage, a storage account need to be created. The storage account is just an account that permits you access the Azure storage. Each storage type (Standard or Premium) needs a different storage account. So to be able to use both storage types, two storage accounts should be owned. You can have more than one storage account per subscription and the maximum is 100.
  • Like any Azure resource, the storage account is region limited. You can’t provision a VM in a region and its storage resource in another region
  • Azure storage offers different redundancy options categorized into 4 variants : LRS, ZRS, GRS and RA-GRS. The following Link provides description for each variant. The minimum redundancy in Azure is LRS which creates 3 copies of the data on the same facility.
  • Standard Storage : Storage performance is limited in term of IOPS an throughput. The reference IO UNIT size is 8 KB. The maximum IOPS per disk (VHD) is 300 for a basic tier and 500 for a standard tier, the maximum throughput is 60 MB/s. Of course higher IOPS and throughput can be achieved using disk aggregation (stripping). This link explains more the IOPS and throughput for Azure storage. LINK10 : Azure Storage IOPS and throughput
  • Premium Storage : Storage performance is the main key of this storage type that let you achieve 64.000 IOPS an more than 512 MB/s  per virtual machine. More detailed information can be found on the following link LINK 11 : Azure Premium Storage overview
  • Blob storage can be accessed via the Azure PowerShell or Azure Storage APIs for common management tasks.

File Storage

File storage is a new Azure storage service (In preview till the writing time of this post). File storage offers shared storage for applications using the standard SMB 2.1 protocol. Microsoft Azure virtual machines and cloud services can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API. Applications running in Azure virtual machines or cloud services can mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the File storage share simultaneously. Since a File storage share is a standard SMB 2.1 file share, applications running in Azure can access data in the share via file I/O APIs. Developers can therefore leverage their existing code and skills to migrate existing applications. IT Pros can use PowerShell cmdlets to create, mount, and manage File storage shares as part of the administration of Azure applications. This guide will show examples of both.

Common uses of File storage include:

  • Migrating on-premises applications that rely on file shares to run on Azure virtual machines or cloud services, without expensive rewrites
  • Storing shared application settings, for example in configuration files
  • Storing diagnostic data such as logs, metrics, and crash dumps in a shared location
  • Storing tools and utilities needed for developing or administering Azure virtual machines or cloud services

More information can be found here LINK 12 : Azure File storage overview


This section describes the pricing basics for the Azure IaaS components. Pricing is a very important when designing the Azure platform, since in the Azure model, the components granularity can let you create different similar designs with different costs. You should be aware of every components that you will include in your design, to perfectly estimate the total platform cost.

Compute Pricing

  • Each virtual machine type has a cost. The cost is for compute resources (Not storage and Network) and depends on the 3-Tuple : (Tier, Series, Size). Check the following link for the most recent Virtual Machine pricing LINK 13 : Azure Virtual Machines price list
  • The consumption is calculated in a per-minute usage. So if you use you VM for 1 hour, you will be charged for 60 minutes, if you use it for 30 seconds, you will be charged for 1 minute
  • Prices are different from a region to another. In general, the most expensive is in the Australia and Brazil regions
  • A virtual machine is always billed unless it’s deleted or Deallocated (stopped and deallocated)
  • Storage and network resources are billed separately.  The temporary storage shipped with the virtual machine is however free.
  • There are taxes applied to the virtual machine usage. These taxes are not included in the Azure virtual machine prices, and are added separately to the bill. I have no idea how these taxes are calculated. I will be glad if someone leave me a comment with this precious, hidden information
  • For the Azure virtual machine pricing details, follow this link. LINK 13 : Azure virtual machine pricing

Storage Pricing

  • Virtual machine storage (except the temporary disk) is  billed in a per GB/Month basis. For example, if you use 100 GB in the first 15 days, and 0 GB in the second 15 days, you will be billed for the usage of 50 GB per month. Every day, Azure will pick up a value of the consumed storage for that day. By the end of the month, these value will be used to calculate the monthly usage value ( DAY1 + DAY2 + … + DAY30)/30
  • Storage cost depends on the location (Region) and the redundancy type. The more the storage is redundant, the more it’s expensive ( LRS > ZRS > GRS < RA-GRS)
  • The storage cost decrease with storage consumption. The more you use storage, the cheaper the GB/month pricing unit will be
  • Only really consumed storage is billed. For example, if you create a 200 GB vhd, with only 50 GB content, only 50 GB will be billed by the end of the month.
  • Storage transactions are billed. Every write/read operation is charged. The actual price is a fixed amount per 100.000 transactions. The question is why ? The answer is : Imagine a person copying 50 GB of data to a location, and leaving it till the end of the month, and another person, copying 50 GB of data to a location, but everyday, it replaces them by 50 GB of new data. At the end of the month, the two persons used 50 GB of data, but it’s clearly that the second one was continuously soliciting the storage subsystem, and hence, amortizing the system. It’s obvious to charge it a way more than the first one.
  • Premium storage billing is different from the standard storage billing, you should be aware of the difference :

For the Azure storage pricing details, follow this link. LINK 15 : Azure storage pricing

Network Pricing

  • Network traffic and data transfer inside the same Azure region is free (Intra-VNET, Inter-VNET in the same region)
  • Microsoft will charge outbound data transfers(Egress data), that means that data leaving the Azure datacenters will be charged. Inbound data (Data uploaded to Azure) is free. The first outbound 5 GB of data is free.
  • Like the other pricing models, prices decrease with usage increase.
  • Prices are different from one zone to another. Prices in Zone1 are lower than Zone 2, which prices are lower than Zone 3. Of course, things can change on the future, and it will change.
  • In addition to the data transfer charge, there are charges applied to the IP addresses that may be assigned to virtual machines and related services (Per hour basis)
      • PIP : PIP addresses are not free, and are charged per hour basis (however, one PIP costs around 3 Euros per month, per VM)
      • VIP : VIP is free. But if you want to have multiple VIP for the same cloud service (up to 5 VIP), you can have them at a nominal charge, at the same cost then PIP.
      • Reserved IP: If you want to reserve the VIP address (set it to static), the first 5 will be free and additional reserved VIP will be charged. Even unused reserved IP addresses will be charged too (For example you reserve an IP and you don’t use it for a service)
      • Address remap : Address remap is free if you remap up to 100 address per month. If you cross this limit, a fee will be applied per additional remap (remap mean that you assign an IP already assigned to a cloud service to another cloud service)
  • When you establish a cross-premise connection using VPN or a Vnet-to-Vnet connection, an Azure gateway is used. There are many Azure gateway types that offer different performances and scalability values and with different costs. The following link shows the Azure gateway types. Pricing can be found in this link
  • Express Route : Azure ExpressRoute enables you to create private connections between Azure datacenters and infrastructure that’s on your premises or in a colocation environment. ExpressRoute connections do not go over the public Internet, and offer more reliability, faster speeds, lower latencies and higher security than typical connections over the Internet. Express route has many advantages:
    • Detected circuit between Azure and on-premise
    • Private circuit that do not go through internet
    • SLA (Availability and performances)
  • There is a hidden information that is not exposed to Azure users, but will add a little dollars to you bill. It’s the tax cost. In fact, a tax applyes when using Azure (or in genral any service). The tax cost is not included in the features or services pricing and added later to the bill. Unfortunately, Microsoft do not provide information about how much this tax is really is. (Look for this TechNet thread)

Express route pricing can be found here

For the Azure network pricing details (Data transfers), follow this link. LINK 16 : Azure data transfers pricing

For the Azure network pricing  details (IP addresses), follow this link. LINK 17 : Azure IP addresses pricing

Design Consideration ad recommendations

This section will describe some design considerations and recommendations when planning to use Azure IaaS and specially Virtual Machines.

Design Consideration:


  • There are 3 virtual machine states: Running, Stopped (Allocated) and Stopped (Unallocated)
      • Running: This is when the virtual machine is up and running : All the virtual machine resources are billed —-> Compute, Network and Storage
      • Stopped (Allocated) : This is when the virtual machine is stopped using the operating system (The machine is stopped from inside the operating system) —-> All the virtual machine resources are billed : Compute, Network and Storage
      • Stopped (Unallocated) : This when the virtual machine is stopped using the Azure portal shutdown button or Azure PowerShell/API —-> Only the storage used by the VM is billed
  • Always start with the minimal virtual machine size that fit your needs. You can upgrade the virtual machine configuration, later needed
  • High availability (fault domain and upgrade e domain to achieve SLA)


  • By default, a dynamic IP address is picked from  the virtual network’s IP pool is assigned to any provisioned virtual machine. This IP address is dynamic, that means it ‘may’ change in some conditions (Look HERE). Its’ recommended to set the IP address to static via the following option:
      • Set the IP address to static during the virtual machine provisioning : Only with PowerShell on the Azure management portal or via the portal in the Azure Preview portal
      • Set the IP address to static after the virtual machine creation : Only with PowerShell on the Azure management portal or via the portal in the Azure Preview portal (You can use the following script to fix an IP address for a single virtual machine or this one for a group of virtual machines)
  • If you  plan to use cross-premises connection with Azure, the address space and subnets of your virtual network must be within the RC1918 IP addresses ranges
  • Network security groups is the best option for creating security zones in your virtual networks. Security groups allow you to create ACL rules inter and intra-subnet. NSG and Endpoints are not supported together, you should use either one or the other.
  • You should carefully prepare your virtual network design, in fact, changing the network design of an existing Azure platform is not straight forward and require downtime.
  • You cannot change the IP address of a Virtual Machine without downtime (VM reboot)
  • You can move a VM within the same virtual network between subnets (Require reboot). But you cannot change the virtual network without rebuilding the virtual machine (You should delete the virtual machine and rebuild it using its VHDs)
  • For cross-premises connection using VPN, if you plan (And I think it always will be) to connect more than one site or P2S clients, you must use dynamic routing, that means your on-premise VPN devises must support dynamic routing.
  • Azure virtual machines do not support acting as Layer 3 (IP) gateways or routers. You cannot for example use a 2-NIC virtual machine as a software router. Read here more about Multi-NIC Azure VMs
  • There are different IP addresses types in Azure, you should be aware of them
      • Internal IP address : Also known as DIP, This is the private internal IP address of the virtual machine, this is the local IP address assigned to a virtual machine from the VNet’s address space pool. This IP address cannot be reached from the external network. This IP address is by default dynamic unless you set it to static (See below)
      • Internal virtual IP address  : Also know as LIB. When we say virtual, we say load balancer. The internal virtual IP address is an IP address assigned by the Azure Internal load balancer to be used by internal services to access load balanced workloads. Look to the Load Balance feature described earlier in this post. Internal virtual IP address  is not reachable from external network
      • External virtual IP address : Also know as VIP. This is the IP address of load balanced services that can be accessed from the external network, and can only target the same cloud service. This VIP is dynamic but since it’s public, it’s highly recommended to set it to static. Microsoft allows you to reserve up to 5 VIP by subscription, we call them reserved VIP.
      • Instance level IP : Also know as PIP. This is a public IP that can be directly be assigned to a virtual machine. This will permit you to directly access a virtual machine from the external network without the need of configuring endpoints. Microsoft allows you to reserve up to 5 PIP by subscription


  • To obtain the desired IOPS/Throughput on the data disks, you can use disks stripping. Today, Microsoft recommends using Storage Spaces inside an Azure virtual machine for disk aggregation.
  • Using and managing Premium storage is only possible via the Azure preview portal. If you want to deploy DS-Series, you should use the Azure preview portal
  • As discussed below (Storage section), to obtain the desired IOPS/Throughput with the Premium storage, you should select the adequate VM_Size/P_Disk couple, otherwise you will not achieve the desired performance. Do not forget that each virtual machine size (DS-Series) has a maximum IOPS/Throughput limit. In addition, each P-disk type has also a maximum IOPS/Throughput


Managing Azure and specially Azure virtual machines is today possible via the Azure management portals:

  • Azure Management portal ( : This is the classic portal, where you can make almost all the management tasks. There are many actions and features that you can’t do/use via this portal. You will have to use the second portal
  • Azure portal ( : This is the new metro-style portal. Even if it’s actually in preview, you can make all the management tasks using it.

–> I personally use and recommend using the new Azure portal since (surprisingly unlike the community), since :

  • The classic management portal will be deprecated with time, and one day, you will use it anyway. So it’s a good idea to start and take the habitude and the hand on it.
  • It’s more oriented to touch screen, tablets and phones.
  • Many features are only possible via this portal : DS-Series virtual machines, resetting VM passwords, RBAC…
  • IaaS V2 (ARM objects) can only be shown and used on the new portal
  • I personally like colorful portals Smile

Azure service Quota and limits :

Further reading

We live in the internet Era, and thanks to search engines like Bing and Google, nothing cannot be not found. If you want to learn more about Azure, where to go:

  1. There is two Microsoft free eBooks that you can download right here : The first to read is Microsoft Azure Essentials: Fundamentals of Azure. The second  is Introducing Windows Azure for IT Professionals. Although the latter dates from October 2013, it contains many useful labs to begin manipulating Azure
  2. Microsoft Azure blog :  For whom who want to be stay always tuned about the last Azure updates and news, this is the official Microsoft Azure blog
  3. You favorite search engine + the Key word : This is my preferred and  most used learning method


The goal of this post is to demystify the Azure virtual machines service and Ito explain the different relayed features and components. The information provided are just a start point, and may become deprecated on few months (some of them of course). Azure is under continuous enhancements and fast features growth. I highly recommend you to always check the Microsoft links for the last updates and news. Do not hesitate at asking your questions via the comments, I will be glad to answer, wherever I have the answer.

Azure : Powershell Script to fix IP addresses of a group of Virtual Machine

Hi all,

In my previous post, I posted a script that allow you to fix an Azure virtual machine IP address. But what will you do if you created or have 20 VMs with dynamic IP addresses ? What if you want to set a static IP address for 50 VMs? No worry, I wrote this script that will let you fix IP addresses on a bunch of Azure virtual machines. 

How it works

  • The script use a CSV file that contains the needed information to fix IP addresses for a group of virtual machine. You must provide a valid CSV file as an input. The file is 4 columns separated CSV file : the columns are Name, ServiceName, IpAddress and VirtualNetworkName. You can download and edit this sample CSV file HERE
  • Filling a CSV file can be time consuming and error prone (Specially if we are dealing with tens of VMs). So i added a sweet feature to the script that connect to your Azure subscription and generate a file containing all the VM’s information. you will just edit this CSV file by removing the extra VMs and choosing the right IP addresses


  • Download and install  the Azure Powershell modules HERE
  • Copy the script to a local location (Example : C:\Scripts)
  • Run an elevated Powershell window
  • change the powershell script execution policy to unrestricted (Set-ExecutionPolicy Unrestricted)


  • Browse the folder where the script resides and run it using the following syntax
    • If you want to generate a csv file, you will only provide the Azure Subscription Name as an input, a csv file named AzureVMlist.csv will be generated on the same script folder  

.\SetAzureVMStaticIPfromCSV.ps1 -SubscriptionName ‘SubscriptionName

    • If your CSV file is already created, use the following syntax to run the script

.\SetAzureVMStaticIPfromCSV.ps1 -SubscriptionName ‘SubscriptionName‘ -csvpath csvfilepath


  1. To Generate a CSV file
    .\SetAzureVMStaticIPfromCSV.ps1 -SubscriptionName ‘BuildWindows – SAMIR FARHAT’
  2. Using a CSV file
    .\SetAzureVMStaticIPfromCSV.ps1 -SubscriptionName ‘BuildWindows – SAMIR FARHAT’ -csvpath .\Azurevmlist.csv


  • This script will only work on VMs with one single NIC. I will soon post another script that support fixing IP addresses for VMs with multiple NICs
  • Azure will restart your machines to apply the modifications, so be aware of it

You can download the script here