Exploring Azure Resource Manager

We cannot start talking about Microsoft Azure without describing one of the most important available parts of its ecosystem, which is Azure Resource Manager (or its much simpler abbreviation, ARM). It’s a foundation of all services in Azure, which allows for provisioning new instances of resources and interacting with existing ones. It’s impossible to create a database, disk, or virtual machine without calling one of the available endpoints of this API.

Important note

Don’t confuse ARM being Azure’s management layer with the ARM processor architecture. For the sake of this book, if we at any point talk about both the API and the availability of ARM processors in Azure, we’ll make a clear distinction in that section.

Let’s take a deeper dive into the topic to see what benefits ARM grants and what kinds of functionalities we can leverage for our needs.

Architecture and terminology of ARM

Although ARM is one of the most important elements where Azure is concerned, it’s not as difficult to understand as many people suppose. Let’s look at the following architecture diagram:

Figure 1.1 – High-level architecture diagram of Azure Resource Manager

To get a better understanding, we need to explain all the presented components a little bit:

• Client layer – A layer that is available for each client using Azure. It consists of various SDKs, the Azure CLI, Azure PowerShell, REST API, and, of course, the Azure portal. It’s basically an access layer for anybody who wants to interact with cloud resources.
• Authentication – Components responsible for authenticating and authorizing requests coming to ARM. It involves Entra ID and RBAC/ABAC authorization. We’ll cover that topic a little later in the chapter.
• Resource providers – APIs responsible for provisioning, configuring, and managing resources in Azure. It’s a collection of REST operations that can be called and are given the responsibility to interact with a connected resource type.

For now, that’s all you need to know – of course, there’s still more to uncover, but we’ll get there later in the book. To complete the introduction, let’s briefly cover one more concept called Infrastructure as Code (IaC), which is connected to ARM.

There are lots of different methods when it comes to deploying resources in Azure. You can do it manually in the Azure portal, use the CLI (both the Azure CLI and Azure PowerShell), or download the SDK and write a simple application in your favorite language to provision something in the cloud. This list is already quite impressive, but it’s not yet complete.

The general idea of IaC is to use a text file(s) to automate and unify a way of creating and managing resources in the cloud. ARM natively supports two different tools:

• ARM templates (https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/overview)
• Azure Bicep (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/)

Both tools are officially supported by Microsoft and enable you to even work with not-yet-released features (which include private preview services and functionalities, for example). Using an SDK to define your infrastructure and manage it that way could also be considered IaC, but in this book, we’ll simplify that definition. We’ll talk more about IaC in Chapter 2.

Scopes

The second topic that is important to understand when talking about ARM is scopes. Scopes are crucial because they’re related to resources, policies, and role assignments. In other words, they define multiple layers of your cloud infrastructure and can be used for separating applications and security segmentation.

In Azure, there are five different scopes available:

• Tenant
• Management group
• Subscription
• Resource group
• Resource

All these scopes have the following dependencies on each other:

• Tenants can be deployed separately without an Azure subscription assigned
• Tenants can have multiple subscriptions assigned
• Management groups are optional and may contain zero or multiple Azure subscriptions
• Subscriptions are the main layer of separation for other resources and can be assigned to both tenants and management groups
• Resource groups are required for the deployment of resources that are scoped to resource groups
• Resources require a higher scope to be deployed

We can also visualize these dependencies with the following diagram:

Figure 1.2 – Dependencies between different ARM scopes

Let’s now talk a little bit about smaller details where scopes are concerned.

Target scope

Multiple resources can be scoped to a given parent scope. For instance, to deploy a subscription, you need a tenant. To deploy a resource group, you need a subscription. When talking about resources in general, you need to understand their scope before deployment.

Important note

In Azure, there are resources that can be deployed on multiple scopes, so there’s no exact target scope to select. These are called extension resources. An example would be role assignment – it can be deployed on the subscription, resource group, or resource level and works as an extension to the parent resource.

Most of the time, you don’t need to worry about the target scope as it’ll be automatically selected, or you’ll be given hints about the correct decision.

Extension resources

Some resources in Azure can extend other resources. This means that they don’t provide a typical child-to-parent relation and instead can be used as a form of adding functionality to other resources.

The simplest example of an extension resource is a resource lock. Once added to a resource level, it can prevent it from deletion or set it as read-only.

Tenants and subscriptions

A tenant can have zero, one, or multiple subscriptions assigned. You can move subscriptions between tenants. This works well if you want to limit access to a subscription to a limited number of people (it can be done via RBAC/ABAC, but there are scenarios in which separation must be much stricter). It can also be used to transfer ownership of a subscription to another company or client. The only thing to remember is that doing this doesn’t always transfer the financial details related to a subscription. In such cases, you may need to contact Azure Support.

Resource groups

While we’ll talk about tenants, subscriptions, management groups, and other concepts very often in this book, there’s one thing that is basically the bread and butter of Azure administration. That thing is a resource group.

Resource groups are the main deployment scope for most Azure services, though, from the perspective of administration, they become even more important because they’re also a target of various policies defining allowed resource types and configurations. Resource groups can be treated as metadata storage for resources and are often referred to as resource containers.

Important note

When a resource group is deployed, one needs to select its location. While it may be unintuitive in the beginning, you’ll quickly get used to it. Selecting a proper location may be important from the compliance point of view when you need to ensure that all the infrastructure-related data is stored within compliant locations.

As mentioned before, while lots of resources require a resource group to be deployed, being an Azure administrator requires a wider perspective, as lots of resources you’ll be interested in can be deployed on higher scopes. Still, most of the development of cloud infrastructure in Azure happens on the resource group level.

Resource groups are free and provide logical separation of resources in Azure. This means that resources from one resource group can connect to another without additional configuration. If you want to limit connectivity and apply network policies, you’ll need to use dedicated resources such as virtual networks, network security groups, and firewalls.

Tags

Many resources in Azure can be tagged. A tag is a simple label consisting of a key and a value, which can be applied on the resource level for grouping, metadata, or compliance reasons. Normally, resources don’t inherit tags from their parents, though there are exceptions (including managed resource groups created for resources such as Azure Kubernetes Service or Azure Databricks) that automatically get tags applied to a parent resource.

Remember that tags are stored as plain text. Don’t attempt to store any sensitive or secret value there.

Quotas and limits

In Azure, you cannot deploy resources without limits. This means that there are certain quotas, depending on the resource type, which will block deployment exceeding a limit. For example, you may initially have a quota of 10 vCores per virtual machine family, which is considered a soft limit. If you feel that you need more, you can manually increase it on your subscription level.

Besides soft limits, there are also hard limits. While soft limits can be increased, a hard limit is something you normally cannot exceed. Individual agreements, consulted on a per-scenario basis, are possible after reaching out to Azure Support.

With some basics of ARM covered, let’s now proceed to Entra ID – a service that is very closely related to ARM but serves a different purpose and can be used without having an Azure subscription.