Core Azure Resource Structures

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. 

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.