Entra ID and Azure Taxonomy - Designing a clean cloud structure

Designing a clear Azure structure requires deciding which taxonomy level should enforce Azure Policy, RBAC, and isolation. This article presents the hierarchy from Entra ID Tenant down to Azure Resources, explains where to apply governance, and gives practical tips you can use to build a maintainable cloud structure.

As the diagram shows, the first takeaway is that Microsoft Entra ID is the identity management branch and Azure is the resource governance branch.

The hierarchy from top to bottom

1. Entra ID Tenant & Directory

TL;DR: The top-level security boundary in Microsoft Entra ID.

An Entra ID Tenant is the account that represents your organization in Microsoft’s identity system. It is where your directory settings, branding, and tenant-wide controls live. For most teams, one tenant per company keeps things simple: fewer admin boundaries, easier SSO, and less cross-tenant complexity. Only split tenants when you need strict legal, regulatory, or administrative isolation.

Entra Directory: Entra Directory: The catalog for identities such as users, groups, and devices. Each tenant contains a single directory; the terms Tenant and Directory are often used interchangeably.

2. Entra ID Objects (users, groups, devices, roles)

TL;DR: The building blocks of identity and access.

Users, groups, devices, and role assignments are the objects you manage inside the Tenant. Use groups and role assignments to grant access at scale, and prefer group-based role assignment over per-user RBAC where possible. Keep role definitions and privileged accounts tightly controlled.

3. Administrative units (AUs)

TL;DR: Scope identity administration without granting tenant-wide privileges.

Administrative units are directory-scoped containers that let you delegate identity administration to a subset of objects - for example, giving a regional first-level-support team rights to manage only EMEA users. AUs are about scoping who can manage which identities. AUs cannot be nested, but users/groups and devices can belong to multiple AUs.

4. Management Groups

TL;DR: Use Management Groups to assign Azure Policies and initiatives that inherit down to Subscriptions and Resources; avoid using RBAC at that level.

Management Groups sit above Subscriptions. It can contain multiple Subscriptions and child Management Groups. Use them to enforce company-wide governance (security baselines, naming rules, allowed regions) while letting teams operate inside their Subscriptions.

Keep the Management Group tree shallow. A practical layout to consider:

• Root: global policies and tenant-wide guardrails
• Platform: shared services, like logging, secrets, etc.
• Business Unit — one Management Group per major BU, for example finance, sales, etc.

5. Subscriptions

TL;DR: Use a Subscription for billing, quotas and isolation of environments.

Subscriptions are your billing and quota containers. They define billing boundaries and service limits, for example CPU cores or public IPs. Each Azure Subscription trusts a single tenant, and a tenant can have multiple Subscriptions.

Common Subscriptions patterns:

• One Prod Subscription per BU for strict isolation and clear billing.
• One or more Non‑Prod Subscription per BU for dev/test/staging, depending on scale and autonomy.
• One Subscription per product when a BU runs many independent products and needs separate quotas and billing.

Automate Subscription vending (self‑service with guardrails) so teams get subscriptions with pre‑applied policies, RBAC templates, and cost controls. Use Azure Blueprints or landing zone automation for repeatability.

6. Resource Groups and Resources

TL;DR: Use resource groups to group resources by lifecycle and ownership; place Resources in regions that meet latency and compliance needs.

Resource Groups are logical containers inside Subscriptions for Resources that share lifecycle, deployment cadence and ownership. Resources are the services you run (VMs, Storage Accounts, App Services). Do not use Resource Groups as billing boundaries.

Choose regions based on compliance, latency, and disaster recovery (DR). Place primary workloads in a primary region and replicate to a paired/secondary region for DR. Enforce allowed regions and DR requirements with Azure Policy assigned at the appropriate Management Group scope.

My tips on how to effectively use the hierarchy

1. Use a single Entra ID Tenant for the whole organization
2. Use consistent terminology. Tenant = Directory
3. Use Administrative Units to delegate identity administration for subsets of users, groups, or devices
4. Design a shallow Management Group tree first, based on governance tiers from root to Business Units
5. Prefer assigning Azure Policies at Management Group scope
6. Follow the rule “audit first, then deny” for existing infrastructure
7. Use Subscriptions and tags for cost management
8. Prefer assigning RBAC roles at Subscription or Resource Group level to limit the blast radius of elevated permissions
9. Decide Subscription boundaries by isolation needs:
   • Option A: For each BU, create a prod and a nonprod Subscription; nonprod contains resource groups for dev/test/preprod
   • Option B: Create a Subscription per environment (dev, test, preprod, prod) if you prefer strict environment separation
10. Use at least two regions for compliance and disaster recovery. Enforce this via an Azure Policy on the Management Group level
11. Define a global naming convention that includes:
    • Resource type abbreviation (vm, st, app, vnet)
    • Environment (dev, test, preprod) if you are following option A from previous point 6
    • Application or service name (stable identifier).
    • Put changeable metadata (owner, cost center, Management Group) in tags, not names.