Azure Resource Hierarchy

Azure provides four levels of management or four scope levels for organizing Azure resources?: Management groups, Subscriptions, Resource groups and Resources. The below image shows the relationship between these levels.

Azure AD Tenant: A tenant?represents an organization in Azure Active Directory. It's a reserved Azure AD service instance that an organization receives and owns when it signs up for a Microsoft cloud service such as Azure and M365.

Management Groups: Management Groups?help us to manage access, policy and compliance for multiple subscriptions. It allow you to structure your environment and manage it all at large (cloud) scale, which means you can assign Azure Policy objects, role (RBAC) assignments and Azure Blueprint definitions.

Subscriptions: Each subscription has limits or quotas on the amount of resources it can create and use.

Resource Groups: Resource groups?are logical containers where you can deploy and manage Azure resources like web apps, databases, and storage accounts.

Resources: Resources?are instances of services that you can create for example virtual machines, storage, or SQL databases etc.

Azure Purchasing Models Comparison:

Role-based Access Control (RBAC) : RBAC achieves the ability to grant users the least amount privilege to get their work done without affecting other aspects of an instance or subscription as set by the governance?plan.

Examples of Role Based Access Control (RBAC) :

• ?Allowing a user the ability to only manage virtual machines in a subscription and not the ability to manage virtual networks
• Allowing a user the ability to manage all resources,?such as virtual machines, websites, and subnets, within a specified resource group
• Allowing an app to access all resources in a resource group

Role Based Access Control (RBAC) vs Policies:

Both?Role Based Access Control (RBAC) and Polices in Azure play a vital role in a governance?strategy. Azure Policies focus on resource properties during deployment and for already existing resources.?As an example, a policy can be issued to ensure users can only deploy DS series VMs within a specified resource should the user have the permission to deploy the VMs.

Azure landing zone design: Azure landing zone design and implementation should consider foundational management group and subscription structure to avoid creating scaling constraints later. Azure landing zones are the output of a multisubscription Azure environment that accounts for scale, security governance, networking, and identity. Azure landing zones enable application migration, modernization, and innovation at enterprise-scale in Azure.

References:

[1] https://techcommunity.microsoft.com/t5/itops-talk-blog/governance-101-the-difference-between-rbac-and-policies/ba-p/1015556

[2] https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organizeresources#:~:text=Azure%20provides%20four%20levels%20of,%2C%20resource%20groups%2C%20and%20resources.

[3] Landing Zone https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/

[4] Landing Zone Design Areas: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas

[5] Landing zone implementation options: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options

[6] https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/view-all-accounts