Cloud Tenant and Resource Group Architecture Diagram

What this diagram shows

This diagram illustrates the hierarchical organisation of a cloud platform environment, typically Azure or similar multi-tenant systems. It shows how a single tenant (organisation or customer) is subdivided into subscriptions, which themselves contain resource groups that hold individual cloud resources. The flow moves from top-level tenant identity through subscription boundaries, into resource groups, and down to specific compute, storage, database, and networking resources. Role-Based Access Control (RBAC) assignments are shown at each level, demonstrating how permissions cascade and can be scoped to different granularities, allowing teams to manage access without granting blanket administrative rights.

Key components

• Tenant — Root identity container representing an organisation's complete cloud environment and Azure Active Directory instance.
• Subscription — Billing and access boundary within a tenant that isolates resource consumption and cost tracking.
• Resource Group — Logical container that groups related resources for lifecycle management, access control, and organisation.
• Resources — Individual cloud services such as virtual machines, storage accounts, databases, or app services deployed within a resource group.
• RBAC Roles — Permission sets assigned to users, groups, or service principals at tenant, subscription, or resource group scope.
• Management Groups — Optional hierarchical layer above subscriptions for applying policies and access controls across multiple subscriptions at once.
• Identity Provider — Azure Active Directory or equivalent system that authenticates users and issues tokens for access to resources.

When to use it

Use this diagram when designing cloud infrastructure governance, explaining access control strategy to stakeholders, or documenting organisational structure within a cloud platform. It is essential for multi-team environments where different departments or projects need isolated billing, separate resource management, and controlled permission escalation. It is also useful when implementing least-privilege access policies or when onboarding new teams to clarify resource ownership and responsibility boundaries.

Common mistakes

• Showing RBAC roles only at resource level and omitting subscription or tenant-level assignments, which misses critical inherited permissions and governance scope.
• Treating resource groups as identical to subscriptions or conflating their purposes, when subscriptions are billing and policy boundaries while resource groups are purely logical containers.
• Placing resources directly under subscriptions without resource groups, which loses the benefit of grouped lifecycle management and makes permission delegation unnecessarily complex.

Adapting it to your system

Identify your tenant and subscription structure within your cloud provider, then map your actual resource groups and the teams or projects they serve. Document which RBAC roles are assigned at each level, noting whether permissions are inherited downwards. If using management groups for policy enforcement, add them above subscriptions. For each resource type you deploy (VMs, databases, storage), position them within the appropriate resource group. Adjust labels to match your internal naming conventions and team structure, and consider adding a legend showing which roles grant what permissions for your specific use case.