Azure Resource Manager overview

Azure Resource Manager is the deployment and management service for Azure. It provides a consistent management layer that enables you to create, update, and delete resources in your Azure subscription. You can use its access control, auditing, and tagging features to secure and organize your resources after deployment.

When you take actions through the portal, PowerShell, Azure CLI, REST APIs, or client SDKs, the Azure Resource Manager API handles your request. Because all requests are handled through the same API, you see consistent results and capabilities in all the different tools. All capabilities that are available in the portal are also available through PowerShell, Azure CLI, REST APIs, and client SDKs. Functionality initially released through APIs will be represented in the portal within 180 days of initial release.

The following image shows how all the tools interact with the Azure Resource Manager API. The API passes requests to the Resource Manager service, which authenticates and authorizes the requests. Resource Manager then routes the requests to the appropriate service.

Resource Manager request model


If you're new to Azure Resource Manager, there are some terms you might not be familiar with.

  • resource - A manageable item that is available through Azure. Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources.
  • resource group - A container that holds related resources for an Azure solution. The resource group includes those resources that you want to manage as a group. You decide how to allocate resources to resource groups based on what makes the most sense for your organization. See Resource groups.
  • resource provider - A service that supplies Azure resources. For example, a common resource provider is Microsoft.Compute, which supplies the virtual machine resource. Microsoft.Storage is another common resource provider. See Resource providers.
  • Resource Manager template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group or subscription. The template can be used to deploy the resources consistently and repeatedly. See Template deployment.
  • declarative syntax - Syntax that lets you state "Here is what I intend to create" without having to write the sequence of programming commands to create it. The Resource Manager template is an example of declarative syntax. In the file, you define the properties for the infrastructure to deploy to Azure.

The benefits of using Resource Manager

Resource Manager provides several benefits:

  • You can deploy, manage, and monitor all the resources for your solution as a group, rather than handling these resources individually.
  • You can repeatedly deploy your solution throughout the development lifecycle and have confidence your resources are deployed in a consistent state.
  • You can manage your infrastructure through declarative templates rather than scripts.
  • You can define the dependencies between resources so they're deployed in the correct order.
  • You can apply access control to all services in your resource group because Role-Based Access Control (RBAC) is natively integrated into the management platform.
  • You can apply tags to resources to logically organize all the resources in your subscription.
  • You can clarify your organization's billing by viewing costs for a group of resources sharing the same tag.

Understand scope

Azure provides four levels of scope: management groups, subscriptions, resource groups, and resources. The following image shows an example of these layers.


You apply management settings at any of these levels of scope. The level you select determines how widely the setting is applied. Lower levels inherit settings from higher levels. For example, when you apply a policy to the subscription, the policy is applied to all resource groups and resources in your subscription. When you apply a policy on the resource group, that policy is applied the resource group and all its resources. However, another resource group doesn't have that policy assignment.

You can deploy templates to management groups, subscriptions, or resource groups.


The following suggestions help you take full advantage of Resource Manager when working with your solutions.

  • Define and deploy your infrastructure through the declarative syntax in Resource Manager templates, rather than through imperative commands.
  • Define all deployment and configuration steps in the template. You should have no manual steps for setting up your solution.
  • Run imperative commands to manage your resources, such as to start or stop an app or machine.
  • Arrange resources with the same lifecycle in a resource group. Use tags for all other organizing of resources.

For guidance on how enterprises can use Resource Manager to effectively manage subscriptions, see Azure enterprise scaffold - prescriptive subscription governance.

For recommendations on creating Resource Manager templates, see Azure Resource Manager template best practices.

Resource groups

There are some important factors to consider when defining your resource group:

  • All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
  • Each resource can only exist in one resource group.
  • You can add or remove a resource to a resource group at any time.
  • You can move a resource from one resource group to another group. For more information, see Move resources to new resource group or subscription.
  • A resource group can contain resources that are located in different regions.
  • A resource group can be used to scope access control for administrative actions.
  • A resource can interact with resources in other resource groups. This interaction is common when the two resources are related but don't share the same lifecycle (for example, web apps connecting to a database).

When creating a resource group, you need to provide a location for that resource group. You may be wondering, "Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?" The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you're specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.

If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them. For more information about building reliable applications, see Designing reliable Azure applications.

Resource providers

Each resource provider offers a set of resources and operations for working with those resources. For example, if you want to store keys and secrets, you work with the Microsoft.KeyVault resource provider. This resource provider offers a resource type called vaults for creating the key vault.

The name of a resource type is in the format: {resource-provider}/{resource-type}. The resource type for a key vault is Microsoft.KeyVault/vaults.

Before getting started with deploying your resources, you should gain an understanding of the available resource providers. Knowing the names of resource providers and resources helps you define resources you want to deploy to Azure. Also, you need to know the valid locations and API versions for each resource type. For more information, see Resource providers and types.

For all the operations offered by resource providers, see the Azure REST APIs.

Template deployment

With Resource Manager, you can create a template (in JSON format) that defines the infrastructure and configuration of your Azure solution. By using a template, you can repeatedly deploy your solution throughout its lifecycle and have confidence your resources are deployed in a consistent state.

To learn about the format of the template and how you construct it, see Understand the structure and syntax of Azure Resource Manager Templates. To view the JSON syntax for resources types, see Define resources in Azure Resource Manager templates.

Resource Manager processes the template like any other request. It parses the template and converts its syntax into REST API operations for the appropriate resource providers. For example, when Resource Manager receives a template with the following resource definition:

"resources": [
    "apiVersion": "2016-01-01",
    "type": "Microsoft.Storage/storageAccounts",
    "name": "mystorageaccount",
    "location": "westus",
    "sku": {
      "name": "Standard_LRS"
    "kind": "Storage",
    "properties": {

It converts the definition to the following REST API operation, which is sent to the Microsoft.Storage resource provider:

  "location": "westus",
  "properties": {
  "sku": {
    "name": "Standard_LRS"
  "kind": "Storage"

How you define templates and resource groups is entirely up to you and how you want to manage your solution. For example, you can deploy your three tier application through a single template to a single resource group.

three tier template

But, you don't have to define your entire infrastructure in a single template. Often, it makes sense to divide your deployment requirements into a set of targeted, purpose-specific templates. You can easily reuse these templates for different solutions. To deploy a particular solution, you create a master template that links all the required templates. The following image shows how to deploy a three tier solution through a parent template that includes three nested templates.

nested tier template

If you envision your tiers having separate lifecycles, you can deploy your three tiers to separate resource groups. Notice the resources can still be linked to resources in other resource groups.

tier template

For information about nested templates, see Using linked templates with Azure Resource Manager.

Azure Resource Manager analyzes dependencies to ensure resources are created in the correct order. If one resource relies on a value from another resource (such as a virtual machine needing a storage account for disks), you set a dependency. For more information, see Defining dependencies in Azure Resource Manager templates.

You can also use the template for updates to the infrastructure. For example, you can add a resource to your solution and add configuration rules for the resources that are already deployed. If the template defines a resource that already exists, Resource Manager updates the existing resource instead of creating a new one.

Resource Manager provides extensions for scenarios when you need additional operations such as installing particular software that isn't included in the setup. If you're already using a configuration management service, like DSC, Chef or Puppet, you can continue working with that service by using extensions. For information about virtual machine extensions, see About virtual machine extensions and features.

When you create a solution from the portal, the solution automatically includes a deployment template. You don't have to create your template from scratch because you can start with the template for your solution and customize it to meet your specific needs. For a sample, see Quickstart: Create and deploy Azure Resource Manager templates by using the Azure portal. You can also retrieve a template for an existing resource group by either exporting the current state of the resource group, or viewing the template used for a particular deployment. Viewing the exported template is a helpful way to learn about the template syntax.

Finally, the template becomes part of the source code for your app. You can check it in to your source code repository and update it as your app evolves. You can edit the template through Visual Studio.

After defining your template, you're ready to deploy the resources to Azure. To deploy the resources, see:

Safe deployment practices

When deploying a complex service to Azure, you might need to deploy your service to multiple regions, and check its health before proceeding to the next step. Use Azure Deployment Manager to coordinate a staged rollout of the service. By staging the rollout of your service, you can find potential problems before it has been deployed to all regions. If you don't need these precautions, the deployment operations in the preceding section are the better option.

Deployment Manager is currently in public preview.

Resiliency of Azure Resource Manager

The Azure Resource Manager service is designed for resiliency and continuous availability. Resource Manager and control plane operations (requests sent to in the REST API are:

  • Distributed across regions. Some services are regional.

  • Distributed across Availability Zones (as well regions) in locations that have multiple Availability Zones.

  • Not dependent on a single logical data center.

  • Never taken down for maintenance activities.

This resiliency applies to services that receive requests through Resource Manager. For example, Key Vault benefits from this resiliency.

Quickstarts and tutorials

Use the following quickstarts and tutorials to learn how to develop resource manager templates:

  • Quickstarts

    Title Description
    Use the Azure portal Generate a template using the portal, and understand the process of editing and deploying the template.
    Use Visual Studio Code Use Visual Studio Code to create and edit templates, and how to use the Azure Cloud shell to deploy templates.
    Use Visual Studio Use Visual Studio to create, edit, and deploy templates.
  • Tutorials

    Title Description
    Utilize template reference Utilize the template reference documentation to develop templates. In the tutorial, you find the storage account schema, and use the information to create an encrypted storage account.
    Create multiple instances Create multiple instances of Azure resources. In the tutorial, you create multiple instances of storage account.
    Set resource deployment order Define resource dependencies. In the tutorial, you create a virtual network, a virtual machine, and the dependent Azure resources. You learn how the dependencies are defined.
    Use conditions Deploy resources based on some parameter values. In the tutorial, you define a template to create a new storage account or use an existing storage account based on the value of a parameter.
    Integrate key vault Retrieve secrets/passwords from Azure Key Vault. In the tutorial, you create a virtual machine. The virtual machine administrator password is retrieved from a Key Vault.
    Create linked templates Modularize templates, and call other templates from a template. In the tutorial, you create a virtual network, a virtual machine, and the dependent resources. The dependent storage account is defined in a linked template.
    Deploy virtual machine extensions Perform post-deployment tasks by using extensions. In the tutorial, you deploy a customer script extension to install web server on the virtual machine.
    Deploy SQL extensions Perform post-deployment tasks by using extensions. In the tutorial, you deploy a customer script extension to install web server on the virtual machine.
    Secure artifacts Secure the artifacts needed to complete the deployments. In the tutorial, you learn how to secure the artifact used in the Deploy SQL extensions tutorial.
    Use safe deployment practices Use Azure Deployment manager.
    Tutorial: Troubleshoot Resource Manager template deployments Troubleshoot template deployment issues.

These tutorials can be used individually, or as a series to learn the major Resource Manager template development concepts.

Next steps

In this article, you learned how to use Azure Resource Manager for deployment, management, and access control of resources on Azure. Proceed to the next article to learn how to create your first Azure Resource Manager template.