Understanding Azure Resource Manager


Azure & Azure Stack are comprised of several technologies in multiple layers to make them as a single platform. All these technologies like UI or Physical Infrastructure can be controlled by Azure Resource Manager (ARM). ARM is responsible for all communication between Resource Providers like Databases to Cloud Operators, Cloud Administrators and DevOps and vice versa.

All interactions with the resource providers that power the functions of Azure and Azure Stack occur through the ARM layer. This layer exposes itself using REST APIs that are based on HTTPS communication. Each API has several versions and it is must to append API version while interacting with it. The API version is critical to understand the functionality offered by Resource Provider.  An example of API URL extended with version. 

https://management.local.azurestack.external/subscriptions/{subscriptionId}/{resourceprovider request}?api-version={API date}

All the interactions that we do using Portal, Azure Power Shell, Azure CLI and dev tools like Visual Studio or Github are through ARM APIs.

ARM Application Management
In general applications are based on two tiers or more and have dependencies between these tiers & components like databases, storage, Virtual machines etc.. All these components are often seen as a single entity that forms an application with resources that depend on one another to form the application. DevOps practice is to ensure that all these resources/components are deployed, managed & monitored as one entity. ARM enables you to manage these resources as a group. ARM templates help you to do all these actions in a single coordinated way. These templates are reusable and consistent to be used in Dev, Stage & Prod environments. Let’s quickly familiarize ourselves with the terminology used in ARM.

Term Description
Resource A resource is a single manageable item available through Azure or Azure Stack, like a virtual machine, a database, and a virtual network.
Resource Group This is a logical entity into which resources are deployed. Each
subscription can have a number of resource groups, with each resource group having several resources. Typically, you use a resource group for application life cycle management. Therefore, the resources required for the application are deployed into the same resource group.
Resource Provider This is a service that supplies resources, and you can deploy and manage them through the ARM interface. Each resource provider is solely responsible for the resources it can provide although it can work with other resource providers. For example, the Microsoft.Compute resource provider is responsible for virtual machines and this works with the
Microsoft.Storage resource provider to allocate storage and create the required blobs for a virtual machine. The resource providers communicate with each other through the REST APIs they expose through ARM.
Resource Manager Template These are also known as Azure Resource Manager templates. A Resource Manager template is a JSON file that contains the definition of one or more resources to be deployed into a single resource group. It defines any dependencies between resources. For example, it defines that a virtual machine requires a virtual network and a storage account. You can use a template to deploy resources consistently as many times as required.
Declarative Syntax Unlike other processes, the Resource Manager template states what it wants to achieve but not how to achieve it. The template informs Azure Resource Manager what it wants to create and Azure Resource Manager can then determine the correct order of processing to ensure that an entity such as a virtual machine has a storage account and virtual network to use before it deploys the virtual machine.

Use ARM to apply Role based access control (RBAC) to resources so that certain users / groups are allowed only to take actions. Apply tags to resources so that you can organize them as per your choice. These tags can be used to collate billing for all resources as single solution.

Considerations while creating Resource Groups

  • Create the Resource Groups based on the resources which shares the same life cycle, it means you can deploy, update and delete them at same time. If one of the resource such as Virtual Network has a different lifecycle, it should be deployed to different resource group.
  • A resource (such as virtual machine) can be assigned to one resource group at a time.
  • You can add or remove resources from Resource group when required.
  • You can move resources between resource groups however there are some resources that can’t be moved such as: VPN Gateway, Recovery Service vault (Azure) , Virtual Machines with certificate stored in key vault (Azure).
  • Although a resource group can have resources that reside in different regions, the resource group itself as a logical entity, must reside in a single region. This is because the resource group contains metadata about all the resources it contains and by defining the resource group location you are defining where the metadata is stored.
  • Administrative access can be granted through RBAC.
  • A resource in one resource group can interact with a resource in different resource group. For example For example, a virtual network can be one resource group and the virtual machines that are deployed into that virtual network are associated with another resource group.


RBAC allows for the granular control of actions over resources. It is natively integrated into the management platform and applies the access control to all services in a resource group. You must understand two main components when you work with RBAC:

• Role definition: This defines a set of permissions that you can undertake. You create role definitions at the subscription level and you can reuse them.
• Role assignment: This associates a role definition with an identity, be that a user or a group, for a specific scope. You can scope to a subscription, a resource group, or resource. Role assignments are inherited by lower scopes. For example, if you assign a role definition to a resource group, all the resources within the resource group inherit that role definition.

Azure Resource Manager provides several predefined role definitions. Some are defined at the subscription level, while others are assigned at the resource group or resource level. You can create your own role definitions in Azure Resource Manager based on the actions exposed by each resource provider. You can assign more than one role definition to an Azure Active Directory (Azure AD) identity. Designing RBAC for subscriptions, resource groups, and resources is the responsibility of the Cloud Administrator.

Cloud administrators can create customized policies using ARM for controlling the deployed resources in their subscriptions.  These policies could help applying organization specific constraints like Naming Conventions, Quotas etc.. Policies are defined as JSON and they can be applied to entire subscription or a resource group. The difference between RBAC & Policies is that RBAC can define what users/groups are permitted to do, it does not enforce restrictions on them as policies can.
An example of policy could be to ensure that only allowed Operating system versions can be deployed on Virtual machines.

Summary: Azure Resource Manager is the single interface between the end user, which could be Azure Stack Cloud Operators or Cloud Administrators/DevOps, and the underlying resource providers. By utilizing a common API set, Azure Resource Manager simplifies the development of solutions in Azure-based environments, whether it is Azure or Azure Stack.




Choosing between Azure Stack & Windows Azure Pack (WAP)

In my previous post we compared Azure & Azure Stack. Today we will compare Windows Azure Pack & Azure Stack.

Windows Azure Pack is another product offered by Microsoft, to provide cloud services for data center that delivers cloud services for end users and customers but its limited to private cloud only.  Both Azure Stack & Windows Azure Pack (WAP) have some similarities however they also have significant differences that we will discuss in this blog post.

What is WAP ?  It was first introduced in 2012 with the launch of Windows Server 2012 at no extra cost. It is based on SQL Server, Windows Server & Microsoft System Center suite, offering customers Self Services, multi tenant Cloud services  (SaaS & PaaS) such as Virtual Machines, Websites & Databases.  Some of the key features of WAP is listed below.

WAP Features Description
Tenant Portal To provision and manage services such as Virtual machines & Websites by Tenants.
Admin Portal  For services administrators to manage resources that they made available for tenants. They can configure quotas or User accounts.
Service Management API  REST API provides the ability to extend functions to tenants and admins such as creating users , managing subscriptions etc..
Virtual Machine Cloud Services  IaaS services of WAP provides the ability to provision Windows and Linux machines. Dependent on Ms System Center components (Service Provider Foundation & Virtual Machine Manager VMM).
WAP Web Sites  Provide the ability to provision scalable web applications based on ASP.NET, PHP & Node.js.
Service Bus  Distributed applications can communicate reliably using messaging services.
SQL and MySQL Services Ms SQL & MySQL services provides database provisioning to be used with other services such as WAP Websites
Automation  Automate tasks in WAP using System Center Services Management Automation.
International Language Support WAP Supports following languages: English, German, Spanish, French, Italian, Japanese, Chinese, Brazilian, Portuguese, Korean & Russian.

Complete features of WAP can be found here.

WAP utilizes Windows Server & System Center for its infrastructure to deliver the services. WAP now supports Windows Server 2016 & System Center 2016.

POC of WAP can be done by installing Express Edition of WAP on single VM or Physical Machine however for production minimum of 8 machines are needed (VM or Physical).

Feature comparison between two products:

Azure Stack features which may (not) available in WAP

Azure Stack Features Available in WAP
Provisioning Virtual Machines Yes
Creating Storage Accounts No
Azure Resource Manager Templates No
Managing Networking Yes
Azure Stack Marketplace Yes (Gallery Items)
Custom Virtual Machine Images Yes (although not tenant defined images)
Billing & Chargeback Yes
Azure Stack Resource Providers No
App Service Yes
Microsoft Azure Consistency No

WAP features which may (not) available in Azure Stack

WAP Features Available in Azure Stack
Tenant Portal Yes
Admin Portal Yes
Service Management API No
Virtual Machine Clouds Service Yes
Windows Azure Pack Web Sites Yes (through App Services)
Service Bus Clouds service No
SQL and MySQL Services Yes(Using Resource Providers)
Automation No

Some possible challenges with WAP:
You may face some challenges while deploying WAP to your datacenter such as (but not limited to):

Challenge WAP Azure Stack
Infrastructure  POC with Express Edition Single VM/Physical

Production minimum 8 VMs/Physical

High availability needs more infrastructure and manual configuration

 High availability is configured automatically
in Azure Stack. For example, when you deploy a 4-node Azure Stack installation, then the Active Directory domain controllers, network controllers, and so on, are automatically deployed and configured for high availability. This dramatically reduces the overhead when you deploy a highly available Azure Stack
System Center Dependency Highly dependent on System center components to provide features such as VM Automation, and usage data. Virtual Machine Manager, Operations manager, Service Provider Foundation & Service Management Automation are Specifically needed. No dependency on System Center for mentioned features however some of them are not available to date.
Hybrid Cloud with Azure WAP is based on completely different API set which cannot be used with Azure. Azure Stack & Azure uses same API sets therefore applications and services can be moved back & forth using same templates.
Azure Resource Manager Not available in WAP, therefore if you already knows Azure templates, you still need to learn how to work with WAP. Azure Stack uses ARM templates, therefore same deployment templates can be used in interchangeably in both Azure & Azure Stack.


Deciding whether Azure Stack or Windows Azure Pack is the most suitable cloud service product for your organization depends on several different factors (but not limited to below):

Factor  WAP Azure Stack
Cost  No cost solution but requires substantial amount of infrastructure especially when high availability is needed. You can add additional cost of System center if you don’t have already. You must purchase Integrated system (hardware) from Dell EMC, Lenovo, HPE etc…
Flexibility Primarily a private cloud solution.

WAP offers features such as Shielded VMs and third party management tools for partner products which are currently not available in Azure Stack.

Azure Stack is true hybrid cloud solution providing flexibility of hosting & moving apps / services between on-prem to the public cloud (Azure).
Automation WAP includes an Automation feature that you can use to automate tasks such as applying
a policy to a newly created virtual machine by a tenant.
Not available at this moment.
Multi-tier app support You would need to
deploy each tier separately, and then configure integration between them as a separate task.
Using ARM & ARM Templates, it is possible to define sequence & deployment of different roles like Back end SQL , Middle Tier Application Server & Front end web servers making deployments faster and less error prone.
System center integration WAP uses System center components like SCVMM, SCOM etc.. When VM is provisioned through WAP, it is actually handed over to SCVMM. This simplifies the rest of VM management tasks. Azure Stack does not integrate with System center.

WAP offers cloud services your end users and customers in a private cloud environment whereas Azure Stack does same but additionally provides integration with Azure thus creating a true Hybrid cloud environment. Since Azure Stack is a new product comparing to WAP, but Microsoft is working to expand its features over time including the features which currently available in Azure only. Windows Azure Pack running on Windows Server 2012 R2 will be moving into extended support on July 11th 2017, and Windows Azure Pack running on Windows Server 2016 will moving into extended support on January 11th 2022.