Microsoft Azure has a very strict hierarchy, but one that is crucial to understand in order to successfully deploy it.
The Azure tenant is at the top of the hierarchy. The tenant is most commonly at the organizational level, and most organizations will have a single global tenant providing the identity and authentication layer for their workforce. However, some larger businesses may utilize multiple tenants that serve distinct functions due to intentional separation of business areas, etc.
Azure Active Directory (AAD) sits within this tenant and allows admins to cascade permissions to the deeper level of their environment. However, it is important to note that permissions set at the tenant level do not propagate directly to the downstream subscriptions, which is where management groups can be useful.
Within the tenant, stratified management groups can be created to help manage various downstream features of the Azure environment. These management groups are most helpful when managing large, complex environments. They sit above subscriptions, meaning a single management group may be delegated to manage multiple subscriptions.
The subscription acts as the billing container for the resources in Azure. A single tenant may contain multiple subscriptions procured from various sources (Pay-As-You-Go, Enterprise Agreement, Cloud Service Provider (CSP). Resources within a subscription are billed in line with the agreement.
Subscriptions were introduced as a discreet billing instance, and still function as a billing container as described above. However, Microsoft now advises that the subscription should also be considered as the top-level management container for a logical collection of resources.
Resource groups are below the subscription level. They serve as a bucket for an associated collection of resources, and specific permissions can be set at this level to provide access to it and the resources contained.
Resource Groups contain corporate IaaS and PaaS services, and generally group these services in a logical manner. Administrators can also create policies at the resource group level to enforce requirements, such as restricting the locations where new resources can be created or mandating the inheritance of tags/object labels.
Resources sit at the bottom of the Azure tree. Resources are the actual objects that constitute corporate resources. VMs, SQL databases, firewalls and storage accounts, for example, are all resources that reside within the resource group.
Storage services within the resource group may employ geographical resilience. It is important to remember that this is not a disaster recovery (DR) solution but a data protection mechanism. If a business wants to include disaster recovery for their IaaS services, they should look into Azure Site Recovery (ASR).
Want to continue gaining Azure knowledge, and go more in-depth into specific components?
Download our free whitepaper: The Complete Azure-Native DaaS Guide: Azure Hierarchy, Azure Virtual Desktop, & Windows 365