Menu

    BLOG | BY KIT SKINNER

    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: 

    Structure 

    Purpose 

    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. 

    Subscriptions

    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. 

    Conditional Policies

    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 Lead

    Kit Skinner - Cloud Architect Lead

    Meet the author

    Kit is responsible for delivering instructor-led training​ and creating on-demand & hands-on training​. In addition, I am Infrastructure/Security SME for Microsoft Azure & Microsoft 365​.​

    Prior to joining Opsgility, I have spent over 6 years Azure cloud consulting for various industries including manufacturing, distribution, healthcare, and government sectors and over 15 years in direct IT roles designing, running, and managing infrastructure & security.​

    Kit has over 20 years' experience in the IT industry, in roles spanning networking, infrastructure, technical pre-sales and system architecture.​

    Questions? Ask The Experts!

    Contact a Microsoft Cloud Specialist Today For A Free Consultation!