November 5, 2021
Core Azure Resource Structures
By Kit Skinner
Why so many parts and pieces Azure?
When the Azure Resource Management (ARM) structure was implemented for Azure in 2014, a new management structure and platform was implemented to control & compartmentalized aspects of the Azure environment. These ensured that tasks were repeatable, control can be segregated based on roles & tasks, and consistent regardless of the tools utilized to manage the environment. Unfortunately, if you haven’t had the opportunity to work with it consistently, remembering which part performs which tasks and how to best utilize them can be difficult to track.
What are the core Azure structures?
For many who are just getting into Azure, it is difficult to keep track of all the different types of pieces of Azure and how they interact. Azure is designed with very specific structures of management, controls, and commands that can help unify the control of the environment. As you learn and understand these pieces, it can help simplify your use and management of the environments:
|Azure Resource Manager (ARM)||The unified & distributed interface for all control and monitoring of the Azure platform|
|Azure AD Tenant||Identity and access control mechanism for cloud platforms (not just Azure)|
|Subscriptions||Repository and boundary for resources running on the Azure platform|
|Resources||Any computational or storage structure for services running on the Azure Platform|
|Resource Groups||Organizational structures for storing Resources in|
|Templates||Structured files for telling Azure how to build and configure resources|
|Deployments||Jobs run in Azure to create Resources based on Templates|
|Permissions||Role Based Access Control (RBAC) that grant users in Azure AD access to Azure scopes|
|Policies||Restrictions and standards assigned to Azure scopes to limit activity and ensure consistency|
We will go over each of these in more detail in later articles as they all have deeper information available to them. However, here is some more summary about where and when you use them.
Azure Resource Manager (ARM)
Azure Resource Manager (ARM) is designed as a standardize, unified interface that all management and control calls must go through when working with Azure. This ensures that regardless of the tool or platform you use, it is always ensured to be the same experience for access, authorization, control, and features. This also ensures that there is a standardized repeatable process for do common or repetitive tasks.
Azure AD Tenants
Much like the Active Directory Domain Services (AD DS) introduced with Windows 2000, Azure Active Directory (Azure AD) provides authorization and management for security principals such as users and groups. While the Azure platform utilizes Azure AD for authentication as the name would imply, Azure AD can be used for user and group management of a multitude of cloud platforms including Office 365, Dynamics 365, etc as well as third party services or custom-built applications. It is not necessary to have anything in the Azure platform to utilize Azure AD, but anything managed by ARM (Subscriptions, Resources, etc) will all utilize Azure AD. An Azure AD Tenant is the repository and namespace for your organization to use within Azure AD. Depending on designs and needs, you may have multiple Tenants, but each Subscription will only be tied to a single Tenant.
All resources and services running on the Azure platform will be contained within a Subscription. A Subscription will have limits & management boundaries associated with it, and all resources will belong to one Subscription. While a Subscription will be created when you first sign up for Azure, you can potentially create thousands of Subscription for your Azure deployment depending on your needs and requirements.
Resources & Resource Groups
Any service that runs within Azure platform will be defined by Resources. Some examples of Resources in Azure are a Virtual Machine (VM), App Service Plan, Public IP Address, Storage Account, Firewall, etc. Some Resources will have sub-resources such as a Virtual Network (VNet) is a Resource, but the subnets within the VNet are sub-resources of the VNet.
Each Resource is contained in a single Resource Group (RG). RGs are a way to organize and manage your Resources. Many Resources can be moved between RGs as they are primarily for management purposes, but there are some restrictions. RGs can also be a scope for permissions and policies to allow inheritance to the Resources for consistent setup. RGs can also be a container for Resources that are created and deleted together sharing the same lifecycle.
Templates & Deployments
To define structures of Resources, ARM defines structured JSON files called Templates. These templates can define all the properties and settings of resources for repetition or consistency, as well as parameterization and outputs for flexibility and reuse.
A Deployment in Azure is when a Resource is deployed or updated via a template. Any Deployment can also export out its parameters & templates for reuse or diagnostics. Many resources can also be exported out of Azure template and utilized for deployments.
Permissions & Policies
Azure is based on a least-privilege access model meaning no one has access or permission to do anything unless it is assigned. Permissions are grouped together in Role definitions that grant the access and users or groups can be assigned the Role; this is called Role Based Access Control (RBAC). These roles can be assigned to specific scopes such as Subscription, Resource Groups, Resources, etc. Users can be assigned multiple Roles and will have access that is a summation of all the permissions of all the Roles they are assigned in a given scope.
While permissions are an additive process that grant a summation of permissions, Policies are utilized to define standards or limits on those permissions. If a deployment or configuration would violate a Policy that restricts the setting, Azure will deny the update even if someone has permissions to make the change and reports can be run on a Policy to verify compliance and standards. Also, a new Policy will not affect an existing resource, but a Policy can define remediation steps to correct a resource that is not in compliance with automated steps.
Where to next?
All of these pieces are just core building blocks of the parts of the Azure platform. They interact together to provide you a uniform and consistent management, control, and automatable platform for building your solutions on top of. We will continue to dive into these pieces individually in future articles to show you how you can better utilize them to your situations and maximize your investment in the Azure platform.
Kit Skinner - Cloud Architect