What is Azure Resource Manager?

Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that helps you to create, update, and delete resources in your Azure account. You use management features like access control, locks, and tags to secure and organize your resources after deployment.

The following video covers basic Resource Manager concepts:

Consistent management layer

When you send a request through any of the Azure APIs, tools, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request before forwarding it to the appropriate Azure service. Because all requests are handled through the same API, you see consistent results and capabilities in all the different tools.

The following diagram shows the role that Resource Manager plays during Azure requests:

Open diagram: Diagram that shows the role of Resource Manager during Azure requests.

All capabilities that are available in the Azure portal are also available through PowerShell, the Azure CLI, REST APIs, and client SDKs. When APIs introduce new functionality, this reflects in the portal within 180 days of initial release.

Important

Resource Manager will stop supporting protocols older than TLS 1.2 on March 1, 2025. For more information, see Migrating to TLS 1.2 for Azure Resource Manager.

Terminology

If you're new to Resource Manager, you might not be familiar the following terms:

• resource - A manageable item that's available through Azure. Examples of resources include virtual machines, storage accounts, web apps, databases, and virtual networks. Resource groups, subscriptions, management groups, and tags are also 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 which resources belong in a resource group based on what makes the most sense for your organization. See What is a resource group?

• 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 Azure resource providers and types.

• declarative syntax - Syntax that lets you state, "Here's what I intend to create," without having to write the sequence of programming commands to create it. ARM templates and Bicep files are examples of declarative syntax. In those files, you define the properties for the infrastructure to deploy to Azure.

• ARM template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group, subscription, management group, or tenant. Use the template to deploy the resources consistently and repeatedly. See What are ARM templates? for an overview of how to deploy templates.

• Bicep file - A file for declaratively deploying Azure resources. Bicep is a language that was designed to provide the best authoring experience for infrastructure-as-code solutions in Azure. See What is Bicep? to learn more about Bicep.

• extension resource - A resource that adds to another resource's capabilities. For example, a role assignment is an extension resource. You apply a role assignment to any other resource to specify access. See Extension resources.

For more Azure terminology definitions, see Azure fundamental concepts.

The benefits of using Resource Manager

With Resource Manager, you can:

• Manage your infrastructure through declarative templates rather than scripts.

• Deploy, manage, and monitor all the resources for your solution as a group, rather than handling these resources individually.

• Redeploy your solution throughout the development lifecycle and have confidence your resources are deployed in a consistent state.

• Define the dependencies between resources so they're deployed in the correct order.

• Apply access control to all services because Azure role-based access control (Azure RBAC) is natively integrated into the management platform.

• Apply tags to resources to logically organize all the resources in your subscription.

• Clarify your organization's billing by viewing costs for a group of resources that share the same tag.

Understand scope

Azure provides four levels of management scope: management groups, subscriptions, resource groups, and resources. The following diagram visualizes these layers:

Open diagram: Diagram that illustrates the four levels of scope in Azure: management groups, subscriptions, resource groups, and resources.

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 to the resource group and all its resources. However, another resource group doesn't have that policy assignment.

See What is Microsoft Entra ID? to learn more about managing identities and access in Azure.

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

What is a resource group?

A resource group is a container that you use to manage related resources for an Azure solution. Using a resource group can help you to coordinate changes between resources that are related. For example, you can deploy an update to the resource group and have confidence that the resources are updated in a coordinated operation. Or, when you're finished with the solution, you can delete the resource group and know that all of the resources are deleted.

There are some important considerations when defining your resource group:

• All resources in your resource group should share the same lifecycle. You deploy, update, and delete them together. For example, a server is one resource. If it needs to exist on a different deployment cycle, it should be in another resource group.

• Each resource can exist in only 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 Azure resources to new resource group or subscription.

• The resources in a resource group can be located in different regions than the resource group, but we recommend that you use the same location. See What location should I use for my resource group?

• A resource group can be used to scope access control for administrative actions. You can use Azure policies, roles, or resource locks to manage a resource group.

• You can apply tags to a resource group. The resources in the resource group don't inherit those tags.

• A resource can connect to resources in other resource groups. This scenario is common when the two resources are related but don't share the same lifecycle. For example, you can have a web app that connects to a database in a different resource group.

• When you delete a resource group, all resources in the resource group are also deleted. For information about how Resource Manager orchestrates those deletions, see Azure Resource Manager resource group and resource deletion.

• You can deploy up to 800 instances of a resource type in each resource group. Some resource types are exempt from the 800 instance limit. For more information, see resource group limits.

• Some resources can exist outside of a resource group. These resources are deployed to the subscription, management group, or tenant. Only specific resource types are supported at these scopes.

• To create a resource group, use the Azure portal, PowerShell, the Azure CLI, or an ARM template.

Which location should I use for my resource group?

When you create a resource group, you need to provide a location for that resource group. You might wonder why a resource group needs a location and why the resource group location matters if resources can have locations outside of a resource group.

The resource group stores metadata about resources. When you specify a location for the resource group, you're also specifying where that metadata is stored. For compliance reasons, you might need to ensure that your data is stored in a particular region.

Routing control plane operations that target resources in the resource group through the resource group's location helps the resource group remain in a consistent state. When you select a resource group location, select a location close to where your control operations originate - typically the location closest to you. This routing requirement applies only to ARM control plane operations (such as creating, updating, or deleting resources via the Azure Resource Manager API). It doesn't affect data plane requests sent directly to your resource endpoints, such as HTTP requests to a web app or read/write operations to a storage account.

If a resource group's region is temporarily unavailable, Azure Resource Manager automatically reroutes ARM control plane requests to a backup region. This failover is transparent - you use the same API endpoints without any changes. However, this failover covers only ARM control plane operations routed through the resource group. It doesn't cover data plane access to the resources themselves. If the region where a resource is deployed is also unavailable, data plane access to that resource is affected regardless of where its resource group is located. To reduce the impact of regional outages, locate your resources and resource group in the same region. See the Azure Resource Graph table and resource type reference list to view the resources and metadata that Resource Manager manages.

ARM control plane high availability for resource groups is maintained as long as at least one of the resource group's primary or backup regions remains available. For details about how Resource Manager achieves this across regions and availability zones, see Resiliency of Resource Manager.

For more information about backup regions, see Azure region pairs and nonpaired regions.

For more information about building reliable applications, see the Resiliency checklist for specific Azure services.

Resiliency of Resource Manager

Resource Manager is designed for resiliency and continuous availability. Resource Manager and control plane operations (requests sent to management.azure.com) in the REST API:

• Distribute across regions. Resource Manager has a separate instance in each Azure region, meaning that if a Resource Manager instance fails in one region, this doesn't affect the service's availability in another region; the same applies to other Azure services. Although Resource Manager is distributed across regions, some services are regional. This distinction means that while the initial handling of the control plane operation is resilient, the request might be susceptible to regional outages when forwarded to the service.

• Distribute across availability zones (and regions) in locations that have multiple availability zones. This distribution ensures that when a region loses one or more zones, Resource Manager can fail over to another zone or region. It continues to provide control plane capability for the resources.

• Do not depend on one logical datacenter.

• Are not taken down for maintenance activities.

This resiliency applies to services that receive requests through Resource Manager. Azure Key Vault is one service that benefits from this consistency.

Using the global endpoint management.azure.com is recommended for Azure Resource Manager routing because it enables DNS-based traffic distribution, automatic failover, and optimal routing to the closest or healthiest region, which improves latency and reliability for users worldwide. Global endpoints typically result in faster response times, as users are directed to the nearest available region, reducing network hops and delays.

Resolve concurrent operations

Concurrent resource updates can cause unexpected results. When two or more operations try to update the same resource at the same time, Resource Manager detects the conflict, allows only one operation to complete successfully, blocks the other operations, and returns an error. This resolution ensures that your updates are conclusive and reliable. You know the status of your resources and avoid any inconsistency or data loss.

For example, if you have two requests (A and B) that try to update the same resource at the same time and request A finishes before request B, then request A succeeds and request B fails. Request B returns the 409 error. After getting that error code, you can get the updated status of the resource and determine if you want to send request B again.