Understanding key difference between Azure ASM and Azure ARM


Microsoft’s Cloud Platform, Azure, has been in market seven years now and has made a significant number of improvements and enhancements; some of which includes IaaS and Virtual Networking capabilities, per-minute costs for VMs, zero charges for stopped VMs etc.

One such improvement is the introduction of the new deployment model called Azure Resource Manager (ARM). Azure currently supports two deployment models, i.e. Azure Service Management (ASM) and Azure Resource Manager (ARM).

This guide will walk you through the key difference between both the deployment models (ASM and ARM), why ARM was introduced, what are its benefits, and how to deploy VMs in both ASM and ARM.


ASM stands for Azure Service Management. This is usually termed as Classic Deployment model. The classic resources can be provisioned and managed using Azure Classic portal, which can be reached at https://manage.windowsazure.com.

Azure was announced back in October 2008, with its first released in February 2010. The original project name for Azure was Project Red Dog. The classic portal was also known as RDFE (Red Dog Frontend). ASM provides Cloud Service for IaaS workload and few specific PaaS workloads.

Cloud Service and VMs

Cloud Service is an ambiguous term. Cloud Service in Azure is a PaaS offering that allows you to host highly available and scalable applications. However, VM (IaaS) deployed in ASM should be inside a virtual container called Cloud Service. Thus, one can have multiple VMs inside of a single wrapper called Cloud Service. Along with this ambiguity, there are a number of terminologies which are important in understanding the underlying architecture.

A typical Cloud Service comprises of Web role and Worker role. In the backend, a Web role is nothing but a VM with IIS role installed and enabled, whereas Worker role is a VM with IIS role not installed. The Cloud Service can be accessed from the internet using a Virtual IP (VIP), which will be a Public IP assigned to Cloud Service. The default URL for any cloud service deployed in ASM will be of the form `<your-desired-name>.cloudapp.net`.

The simple Cloud Service (PaaS) can be represented as shown below:


In ASM, VMs can be deployed in two ways:

  • Quick Create
  • Create from Gallery

Quick Create will quickly create and launch a VM with selected OS and size without any access to the Virtual Network and Subnets for that VM.

Create from Gallery will allow you to specify and customize all the required settings like Cloud Service name, VNet name and CIDR range, Availability Set, etc.

All VMs deployed under a cloud service will have a single VIP associated with a cloud service (wrapper). This approach was used to maintain the availability of the VMs and load balancing. The creation of cloud service provides implicit load balancer for all VMs deployed under it. To RDP into a particular VM, a combination of VIP and public port is used, which will allow you to uniquely RDP into a particular VM. Public port, since RDP will be assigned randomly while launching a VM.

Multiple VMs (IaaS) under a single cloud service (wrapper) can be represented as shown below:


Instance-Level Public IP (ILPIP) is a Public IP address that can be associated directly with a particular VM. An IP address can also be reserved in Azure to attach it to cloud service. This is called Reserved IP Address.

Virtual Network

Earlier in ASM, there was a concept of Affinity Groups, but it has been deprecated. Resources belonging to the same Affinity Groups will be grouped closest to each other. With the introduction of regional VNet, the idea of Affinity Group was deprecated. If you have any Affinity Groups that you created earlier, you can still select them while launching a VM, which disables the option to select the VNet.

The API set used by ASM are XML driven REST API. Deployment of resources in ASM is possible using command line tools like Xplat-CLI and Azure PowerShell. In ASM model, each resource existed independently of each other without any grouping between them.

Important security features, like Network Security Groups on VMs and Subnets, can be configured using Azure PowerShell.


ARM stands for Azure Resource Manager. This deployment model of Azure represents a different way to deploy and manage your Azure resources than in ASM model. Azure ARM portal can be reached at https://portal.azure.com. The codename for this project was Ibiza. Azure ARM portal is kicking and created not only to introduce new deployment model with improved features but also to bridge a gap between ASM and ARM deployment models. You can still manage your ASM resources from ARM portal. ASM resources will have a Classic tag in ARM portal. ARM uses JSON driven REST API which is a totally different set of API than ASM.

Why transition to ARM?

There are multiple reasons for this revision from ASM to ARM. The Classic portal was messy, and Microsoft was going nowhere to deliver a competitive alternative to other leading cloud service providers concerning user experience. Around May 2011, Scott Guthrie took over the Azure Application Platform team and redesigned Azure’s UI to a new lightweight HTML5 portal.

  • Management of resources was bit tedious and difficult as it lacks grouping of resources
  • ASM model is devoid of fine-grained access control on resources
  • Some of the important functionalities, like Network Security Groups, Load Balancers, DNS management, were not possible in ASM portal
Benefits of ARM

  • ARM portal has a logical container called Resource Group, which makes deployment, management, and monitoring of Azure resources easy and streamlined
  • In Classic Portal, there was no proper grouping of resources, which will lead the user to search for individual resources that make up his/her solution. In ARM portal, however, resources that make up a solution can be grouped together in a Resource Group for easy management.
  • Deletion of resources is easy in ARM portal compared to Classic portal since they are grouped
  • Azure Stack can be leveraged in your on-premises data center to create private Azure ARM portal
  • The resources deployed in ARM portal can be tagged to logically organize them in Azure Subscription
  • Fine-grained access control using RBAC on all resources in resource group is possible with ARM deployment model
  • Deployment using JSON based deployment templates is possible on ARM

VMs in ARM

Unlike ASM, VMs can’t be deployed without a Virtual Network in ARM. Each VM, or rather any resource in ARM, belongs to a Resource Group. The components that are required to deploy a VM in ARM are as follows: a VNet, a subnet, a NIC and Public IP Address (Static or Dynamic), a storage account, a VM itself, Scale Set (optional), and a Load Balancer (optional). However, VMs can be deployed without Public IP Address. In that case, VMs will have Private IP Address of the VNet and Subnet it belongs to.The overview of a VM in ARM is shown below:


In the above figure, we have a VM and VM Scale Set within a Virtual Network, the OS disk and Data disks of both the VMs are in a storage account. Load Balancer which will divide the load between available VMs and all the resources are residing under a single Resource Group.

Now that we know the differences between ASM and ARM, let’s get our hands dirty by deploying VMs in ASM and ARM through PowerShell.


Azure Subscription, Azure PowerShell, and a simple text editor are sufficient to get started. Azure ARM Module in PowerShell is required for ARM deployments. You can install Azure PowerShell from Microsoft Web PI. Once Azure PowerShell is installed, follow the steps below to work with ARM cmdlets.

1. Run your PowerShell with elevated privileges (Run as Administrator).

2. To install items from PowerShell Gallery, PowerShellGet module is required. Make sure you have an appropriate version of PowerShellGet installed. Run the following cmdlet to check.

Get-Module PowerShellGet -list | Select-Object Name,Version,Path

The above cmdlet should return:
 Name Version Path
---- ------- ----
PowerShellGet C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\\PowerShellGet.psd1

3. Run the following cmdlet to install Azure ARM module of PowerShell

Install-Module AzureRM

4. Once installed, import the AzureRM module using `Import-Module AzureRM` cmdlet

Provision VM in Classic Portal using PowerShell

1. To provision any resource using PowerShell, the first thing required is to connect to your Azure Account from command line. This can be done in two ways:

  1. Importing AzurePublishSettingsFile
  2. Adding Azure Account using `Add-AzureAccount` cmdlet

Option 1: AzurePublishSettingsFile contains settings and encoded certificate that provides management credentials to Azure Account. In Azure PowerShell run `Get-AzurePublishSettingsFile` cmdlet to download the file.

Once the file is downloaded, run the following cmdlet to import that file into your PowerShell session.

Import-AzurePublishSettingsFile –PublishSettingsFile "<location-of-file>"

Option 2: Run the following cmdlet and enter your Azure credentials when prompted


2. Run `Get-AzureSubscription` to get a list of Azure subscriptions in your account. We shall select the default subscription and storage account for all our deployments using PowerShell.

Set-AzureSubscription –SubscriptionName "Name-of-Azure-Subscription" –CurrentStorageAccountName "Storage-account-in-that-subscription"

NOTE: If the storage account is not present, the above cmdlet will throw an error. Make sure the storage account is created in mentioned subscription. Use the below cmdlet to create a Storage Account:

New-AzureStorageAccount –StorageAccountName "name-of-SA" –Location "location"

3. We shall launch Ubuntu based VM in Azure. To get the list of images available, we can use `Get-AzureVMImage` cmdlet. We will pass some additional parameters with this to sort out the list based on the image name, publish date, etc. Take note of the Image Name for further use.

Get-AzureVMImage | Select-Object -Property ImageFamily, ImageName, PublishedDate | Where-Object { $_.ImageFamily -like 'Ubuntu Server*' } | Sort-Object -Property PublishedDate -Descending | Select-Object -First 1 | Format-List

4. Now that we have image name, we shall set VM configuration and VM provisioning configuration properties to create a VM with the specified configuration.

$image = "<image-name-retrieved-in-step-3>"
$username = "<Admin-username-to-login-to-VM>"
$password = "P@ssw0rdL@”
$StorageAccount = "<Storage-account-name-(step-2)>"
$ServiceName = "<Desired-Cloud-Service-Name>"
$location = "<any-location>"

New-AzureVMConfig –Name $ServiceName –InstanceSize Small –ImageName $image | Add-AzureVMProvisioningConfig –Linux –LinuxUser $username –Password $password | New-AzureVM –ServiceName $ServiceName –Location $location
Provision VM in ARM using PowerShell

In ARM, VM can be provisioned using PowerShell in two ways:

  • Using PowerShell cmdlets
  • Using JSON template

To login to your Azure Account from PowerShell, use `Login-AzureRmAccount` cmdlet.

1. To provision any resource in ARM portal, we need a resource group. The resource group can be created in the following way:

New-AzureRmResourceGroup –Name <Name-of-RG> –Location <location-of-RG>

2. The networking resources required to create a VM in ARM are VNet, Subnet, NIC, Public IP, and Network Security Group. Follow the steps below to create these resources.

#Subnet configuration
$subnetConfig = New-AzureRmVirtualNetworkSubnetConfig –Name SubnetName –AddressPrefix

#Create Virtual Network
$virtualnetwork = New-AzureRmVirtualNetwork –ResourceGroupname <name-of-RG-in-step-1> -Location <location-in-step-1> -Name VNetName –AddressPrefix –Subnet $subnetConfig

#Create Public IP Address
$pip = New-AzureRmPublicIPAddress –ResourceGroupName <name-of-RG-in-step-1> -Location <location-in-step-1> -AllocationMethod Dynamic –Name “publicdns$(Get-Random)”

#Create Inbound rule for NSG
$nsgSSH = New-AzureRmNetworkSecurityRuleConfig –Name allow-SSH –Protocol TCP –Direction Inbound –Priority 1000 –SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22 –Access Allow

#Create Network Security Group
$nsg = New-AzureRmSecurityGroup –ResourceGroupName <name-of-RG-in-step-1> -Location <location-in-step-1> -Name NSGName –SecurityRules $nsgSSH

3. Virtual Machine is connected to a subnet, network security group and public IP address using a network card. To create virtual network card using PowerShell, use the command below.

$nic = New-AzureRmNetworkInterface –Name NICName –ResourceGroupName <name-of-RG-in-step-1> –Location <location-in-step-1> –SubnetID $virtualnetwork.Subnets[0].Id –PublicIpAddressId $pip.Id –NetworkSecurityGroupId $nsg.Id

4. The resources required for a VM are now in place. We will now create a VM configuration and in turn, create a VM.

$cred = Get-Credential
$vmConfig = New-AzureRmVMConfig –VMName LinVM –VMSize Standard_D1_v2 | Set-AzureRmVMOperatingSystem –Linux –ComputerName LinVM –Credential $cred | Set-AzureRmVMSourceImage –PublisherName Canonical –Offer UbuntuServer –Skus 16.04-LTS –Version latest | Add-AzureRmVMNetworkInterface –Id $nic.Id

New-AzureRmVM -ResourceGroupName <name-of-RG-in-step-1> -Location <location-in-step-1> -VM $vmConfig

Thus, in this way, we can provision a VM using PowerShell.

To provision a VM using a JSON template, we can download JSON template from GitHub and pass runtime parameter values for `StorageAccountName`, `adminUsername`, `adminPassword`, `OS Version`, `DNS Name` for Public IP, etc. This can be done in the following way:

New-AzureRmResourceGroupDeployment -Name 'SimpleVMDeployment' -ResourceGroupName RGName -TemplateUri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/101-simple-windows-vm/azuredeploy.json -newStorageAccountname mypersonalstorage -adminUsername worlduser -adminPassword 'P@ssw0rd@z' –dnsNameForPublicIP 'linuxacaddns' –windowsOsVersion '2012-R2-Datacenter'

Azure also supports provisioning VMs from customized images in ASM and ARM. Azure lets you import and create VMs from custom sources such as GitHub or any other personal sources. Custom images from on-premises can be imported to Azure to create VMs. These images can be Generalized images or Specialised images. A generalized image will have an OS disk which will be generalized using SysPrep in Windows and WAAGent in Linux OS that will act as model to quickly provision similar VMs. A specialized image is more like a Snapshot i.e. this image is read-only and will be copied when deploying a new VM. Custom Vhds can be uploaded to Azure and attached to a new VM to be used as OS disk at the time of VM creation. The only thing to be sure for this is to have the OS disk in the same storage account as the VM will reside in.


Summarizing the differences of ASM and ARM in a single table:


I hope this guide gave you proper insight into ASM and ARM and has displayed all the key differences between both the deployment models in Azure. Microsoft recommends everyone to use ARM model for all further deployments, as ASM will be deprecated in future.

Where to go next?

Check out Linux Academy courses to deep dive into Azure Cloud Platform. Click here for the list of available courses on Azure.

Looking for team training?