Get Azure Datacenter IP ranges via API V2

Hi,

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 : https://buildwindows.wordpress.com/2017/11/19/get-azure-datacenter-ip-ranges-via-api/

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

#V1

#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 ` https://azuredcip.azurewebsites.net/getazuredcipranges -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 ` https://azuredcip.azurewebsites.net/getazuredcipupdates -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

Name

Description

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

Function1

Name

Description

Language

Integrate

Manage

azuredcipranges This function will return you the V1 information.
https://buildwindows.wordpress.com/2017/11/19/get-azure-datacenter-ip-ranges-via-api/
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

Function2

Name

Description

Language

Integrate

Manage

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

Function3

Name

Description

Language

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

Name

Description

Root template

Allowed HTTP methods

Backend URL

getazuredcipranges This proxy will relay requests to azuredcipranges /getazuredcipranges POST https://azuredcip.azurewebsites.net/api/azuredcipranges
(add the key if you have secured it)

Proxy 2

Name

Description

Root template

Allowed HTTP methods

Backend URL

getazuredcipupdates This proxy will relay requests to azuredcipranges /getazuredcipupdates POST https://azuredcip.azurewebsites.net/api/azuredciprangesupdater?code=typethekeyhere

Storage Account

Name

Description

container

Files

azuredcipsa

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.

Enjoy!!

Advertisements

Create an Azure AD service principal (Based on Azure AD App) secured by a Certificate

When working with Azure, you may need to create an Azure AD Application, to act a Service Principal and use it to run operation on Azure resources. This post will show you how to register an Azure AD application secured by a Self-Signed Certificate, all via Powershell. You can modify the third script if you want to create the application using an existing certificate. The used scripts can be downloaded from here

1- Create a pfx certificate

In order to the Azure AD App to be secured, a certificate needs to be created. You can prepare the following information to create your certificate :

  • common name (cn)
  • A password to protect the private key

The files Create-SSCv1.ps1 (for Windows 2008 R2/7) and Create-SSCv2.ps1 (for Windows 2016 /10) are powershell scripts that allow you to create a self-signed certificate.

Example using Create-SSCv1.ps1 (the DNS name replaces the common name)

.\Create-SSCv1.ps1 -DNSName zookeeperazure -Password P@ssw0rdzook -PFXPath c:\-PFXName 
zookeeper

Example using Create-SSCv2.ps1 (More control over some options)

.\Create-SSCv2.ps1 -SubjectName zookeeper -Password P@ssw0rd -PFXPath C:\temp -PFXName 
zookeeper -MonthsValidity 24 -FriendlyName zookeepernva

2- Import the Certifictate the windows Certificates Store

The file Import-CertToStore.ps1 will import the certificate to the personal Store, in order to be used to create the Azure AD App later. Provide the password used on the previous step

.\Import-CertToStore.ps1 -Path C:\temp\zookeeper.pfx -Password P@ssw0rd

3- Create an Azure AD application to act as a Service Principal Name

Use the script file Create-azureadapp.ps1 to create the Azure AD application. The Azure Ad Application should have the same name than the certificate CN, so that the script can work. You will be prompted to login to Azure

.\Create-azureadapp.ps1 -ApplicationName zookeeper

You can see now that an new Application has been added to your Azure AD registered application. Azure Portal à Azure Active Directory à App registration


4- Add the application to an Azure Role

Now that your application has been created, you can assign it to any Azure RBAC role. For example, I assigned the created application (zookeeper) the Reader role on the resource group RG-Azure

Get Azure Datacenter IP address ranges via API

Hi folks,

One of the struggles that we may face when dealing with Azure services, is the network filtering. Today, we consume a lot of services provided by Azure, and some Azure services can consume services from our infrastructure. Microsoft is publishing an ‘xml’ file that contains the exhaustive list of the Azure Datacenter IP ranges for all its public regions (No gov). This ‘xml’ file is regularly updated by Microsoft to reflect the list updates as they can add or remove ranges.

The problem is that consuming an ‘xml’ file is not very convenient as we need to make many transformations to consume the content. Many of you have requested that Microsoft at least publishes this list via an API so it can be consumed by many sources, using Rest requests. Until Microsoft make it, I will show you today how to create a very lightweight web app on Azure (using Azure Functions) that will ‘magically’ do the job.

NB : The Azure Datacenter IP ranges include all the address space used by the Azure datacenters, including the customers address space

1- Why do we need these address ranges ?

If you want to consume Azure services or some Azure services want to consume your services, and you don’t want to allow all the “Internet” space, you can ‘reduce’ the allowed ranges to only the Azure DC address space. In addition, you can go further and select the address ranges by Azure region in case the Azure services are from a particular region.

Examples :

  • Some applications in your servers need to consume Azure Web Apps hosted on Azure. In a world without the Azure DC address space, you should allow them to access internet, which is a bad idea. You can configure your firewalls to only permit access to the Azure DC IP ranges
  • If you are using Network Virtual Appliances on Azure, and you want to allow the VM’s Azure agent to access the Azure services (storage accounts) in order to function properly, you can allow access only to the Azure DC IPs instead of internet.

2- The Solution

In order to consume the Azure Datacenter IPs via an API, I used the powerful and simple Azure functions to provide a very light weight ‘File’ to ‘JSON’ converter. The Azure function will do the following:

  • Accept only a POST request
  • Download the Azure Datacenter IP ranges xml file
  • Convert it to a JSON format
  • Return an output based on the request:
    • A POST request can accept a Body of the following format : { “region”: “regionname”, “request”: “requesttype” }.
      • The “request” “parameter can have the value of :
        • dcip : This will return the list of the Azure Datacenter IP ranges, depending on the “regionname”  parameter. “regionname” can be :
          • all : This will return a JSON output of all the Azure Datacenter IP ranges of all regions
          • regionname : This will return a JSON output of the regionname’s Azure Datacenter IP ranges
        • dcnames : This will return al list of the Azure Datacenter region’s names. The “regionname” parameter will be ignored in this case
      • In case of a bad region name or request value, an error will be returned

3- Try it before deploying it

If you want to see the result, you can make the following requests using your favorite tool, against an Azure function hosted on my platform. In my case, I’m using powershell and my function Uri is https://azuredcip.azurewebsites.net/api/azuredcipranges

3.1- Get the address ranges of all the Azure DCs regions

#Powershell code

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

$webrequestInvoke-WebRequest -Method “POST” -uri ` https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content


 3.2- Get the address ranges of the North Europe region

In this case, note that we must use europnorth
instead of northeurope

#Powershell code

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

$webrequest Invoke-WebRequest -Method “POST” -uri `
https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content


3.3- Get the region names

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

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

$webrequest Invoke-WebRequest -Method “POST” -uri `
https://azuredcip.azurewebsites.net/api/azuredcipranges -Body $body

ConvertFrom-Json -InputObject $webrequest.Content

4- How to deploy it to your system ?

In order to deploy this function within your infrastructure, you will need to create a Azure function (Section : Create a function app) within your infrastructure. You can use an existing Function App or App Service Plan.

NB : The App Service Plan OS must be Windows

After creating the Function App, do the following:

Step Screenshot
Go to your Function App and click the Create new (+)
In Language chose Powersell then select HttpTrigger – Powershell
Give a Name to your function and choose an Authorization level.

In my case, i set the Authorization to anonymous in order to make the steps simpler. We will see later how to secure the access to the function http trigger

Copy paste the following code on the function tab, then click Save

# POST method: $req

$requestBody = Get-Content $req -Raw | ConvertFrom-Json

$region = $requestBody.region

$request = $requestBody.request

#Main

if (-not$region) {$region=‘all’}

$URi = https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653”

$downloadPage = Invoke-WebRequest -Uri $URi -usebasicparsing

$xmlFileUri = ($downloadPage.RawContent.Split(‘”‘) -like https://*PublicIps*”)[0]

$response = Invoke-WebRequest -Uri $xmlFileUri -usebasicparsing

[xml]$xmlResponse = [System.Text.Encoding]::UTF8.GetString($response.Content)

$AzDcIpTab = @{}

if ($request -eq ‘dcip’)

{

foreach ($location
in
$xmlResponse.AzurePublicIpAddresses.Region)

{

if ($region -eq ‘all’) {$AzDcIpTab.Add($location.Name,$location.IpRange.Subnet)}

elseif ($region -eq $location.Name) {$AzDcIpTab.Add($location.Name,$location.IpRange.Subnet)}

}

if ($AzDcIpTab.Count -eq ‘0’) {$AzDcIpTab.Add(“error”,“the requested region does not exist”)}

}

elseif ($request -eq ‘dcnames’)

{

$AzDcIpTab = $xmlResponse.AzurePublicIpAddresses.Region.name

}

else

{$AzDcIpTab.Add(“error”,“the request parameter is not valid”)}

$AzDcIpJson = $AzDcIpTab | ConvertTo-Json

Out-File -Encoding Ascii -FilePath $res -inputObject $AzDcIpJson


Go to the integrate tab, and choose the following:

  • Allowed HTTP methods : Selected methods
  • Selected HTTP methods : Keep only POST

Click Save

It’s done !

To test the function, go back to the main blade and develop the Test tab

On the request body, type :

{

“region” : “europeewest”,

“request”: “dcnames”

}

Then click Run

You should see the results on the output, and the http Status 200 OK

Click Get function URL to get the URL of your function in order to query it via an external tool

 

5- Securing the access to the function URL

There are 3 options that let you secure the access to the Function URL:

5.1- Network IP Restrictions

I personally think that this is best option to secure the access to Function URL. IP Restrictions allows you allow only a set of Public IP addresses to access the Function URL. For example, if you have an automation script that requests the API and update a Firewall object or a database, you can whitelist only the Public IP address used by this automation workflow, which is the outbound IP address. This feature is available for Basic Tier App Service Plans and greater. It’s not supported for free and shared sku. Start using it by following this tutorial : https://docs.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions.

NB : The Networking blade for a Function App can be found by clicking on the Function Name à Platform features à Networking

5.2- Function Key and Host Key

You can restrict the access to the Function URL by leveraging an Authorization feature, by protecting querying the URL  via a ‘Key’. There are two Key types : The Function Key which is defined per Function and a Host key which is defined and the same for all the functions within a Function App. In order to protect a function via a Function key, do the following :

Step Screenshot
Go to the Integrate blade, and change the Authorization level to Function
Go to the Manage blade. You can use the default generated key or Add a new function key. Generating a new key is provided for keys rotation
Now, you can access the ‘protected’ URL by clicking on the Get function URL on the main blade. You can select which key to use.

 

5.3- Authentication and authorization feature in Azure App Service

This feature allows you to secure your Function App by requesting the caller to authenticate to an Identity Provider and provide a token. You can use it against Azure Active Directory or Facebook for example. I will not detail the steps in this post, but here’s some materials :

Overview : https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service/app-service-authentication-overview.md

How to configure your App Service application to use Azure Active Directory login : https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service/app-service-mobile-how-to-configure-active-directory-authentication.md

 

Use the new Azure Services Tags preview

Hi all,

At Ignite 2017, MS announced a very so waited feature, which is Azure Services Endpoints Tags for Network Security Groups. The new additional Service Tags will permit you to allow/Deny access to and from Azure Datacenter IP addresses.

Why is this important ?

A lot of Azure Services, specially Services related to Azure IaaS rely on network access to Azure endpoints located on the Internet address space. For example, you cannot use Azure Backup for IaaS virtual machines if your virtual machines do not have network access to the Azure storage endpoints of the same region. This causes a lot of frustration, since if you are using NSGs, you cannot easily create and maintain rules for only the Azure IP addresses since the list is huge and dynamic (Azure Datacenter IP addresses). This results on all VMs to have access to Internet using HTTPS.

What is new ?

Additional Service tags have been added to some regions to allow filtering access to :

  • Azure Storage endpoints
  • Azure SQL

The feature is now in Preview, and other regions will be added on the future. Make a look to this article to have the last information : Azure Services Tags

How to use the feature ?

You just need to register to the new preview feature. Use the following powershell code against your subscription :

Register-AzureRmProviderFeature -FeatureName AllowAccessRuleExtendedProperties -ProviderNamespace Microsoft.Network
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

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 :

Category

Managed disks

Unmanaged disks

Management

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

Size

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)

Cost

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)

Performance

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)

Availability

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.

Redundancy

LRS LRS, GRS

Encryption

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*

S4

32 1.3 0.040625 0.0422 31

S6

64

2.54

0.0396875

60

S10

128

4.98

0.03890625

118

S20

512

18.36

0.035859375

435

S30 1024 34.56

0.03375

818

* 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:

Properties

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.

0960

https://feedback.azure.com/forums/258995-azure-backup-and-scdpm/suggestions/8369907-azure-backup-to-support-iaas-vm-v2

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

0962

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 :  https://azure.microsoft.com/en-us/pricing/details/backup/
  • 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

https://azure.microsoft.com/en-us/documentation/articles/backup-azure-vms-first-look-arm/

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 (https://portal.azure.com). Go to Browse –> Recovery Services vaults

0923

Click the Add + button

0924

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.

0925

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 +

0926

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

0927

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

0928

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!!)

0929

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.

0930

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…

0931

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

0932

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