Resource Manager - CodeForce2020/AZ-900-Microsoft-Azure-Fundamentals GitHub Wiki
Azure Resource Manager
Azure Resource Manager is a management layer in which resource groups and all the resources within it are created, configured, managed, and deleted. It provides a consistent management layer which allows you automate the deployment and configuration of resources using different automation and scripting tools, such as Microsoft Azure PowerShell, Azure Command-Line Interface (Azure CLI), Azure portal, REST API, and client SDKs.
With Azure Resource Manager, you can:
- Deploy Application resources. Update, manage, and delete all the resources for your solution in a single, coordinated operation.
- Organize resources. Manage your infrastructure through declarative templates rather than scripts. You can view which resources are linked by a dependency, and you can apply tags to resources to categorize them for management tasks, such as billing.
- Control access and resources. You can control who in your organization can perform actions on the resources. You manage permissions by defining roles, adding users or groups to the roles, and applying policies at resource group level. Examples of elements you may wish to control are: enforcing naming convention on resources, limiting which types and instances of resources can be deployed, or limiting which regions can host a type of resource.
What is Azure Resource Manager?
Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that enables 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.
To learn about Azure Resource Manager templates, see Template deployment overview.
Consistent management layer
When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the requested action. 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.
Terminology
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 groups, subscriptions, management groups, and tags are also 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 which resources belong in a resource group based on what makes the most sense for your organization.
-
Resource Provider - A service that supplies Azure resources. For example, a common resource provider:
- Microsoft.Compute: Which supplies the virtual machine resource.
- Microsoft.Storage: Another common resource provider. See Resource providers and types.
-
Resource Manager Template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group, subscription, management group, or tenant. The template can be used to deploy the resources consistently and repeatedly. See Template deployment overview.
-
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. See Template deployment overview.
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 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.
Management Levels:
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 tenants, management groups, subscriptions, or resource groups.
Resource groups
There are some important factors to consider when defining your resource group:
-
All the resources in your resource group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a server, 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 resources to new resource group or subscription.
-
The resources in a resource group can be located in different regions than the resource group.
-
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. 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.
-
A resource group can be used to scope access control for administrative actions. To manage a resource group, you can assign Azure Policies, Azure Roles, or Resource locks.
-
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 Azure 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.
-
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, you can use the Portal, PowerShell, Azure CLI, or an Azure Resource Manager (ARM) Template.
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 management.azure.com) 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.