CH01-03: Azure Hierarchy and Why It Is Useful

Goal

The previous sections introduced Azure as a set of architecture responsibilities: identity, governance, organization, networking, workload services, and operations. This section focuses on one of the most important Azure organization models: the hierarchy from tenant to resources.

The goal is not to memorize an Azure org chart. The goal is to understand where Azure places important decisions:

Who can access Azure?
Which rules apply across many workloads?
Which boundary owns billing, quotas, and deployment?
Which resources belong together?
Where should permissions, policy, monitoring, and cost ownership be applied?

This hierarchy is valid and important, but it needs one nuance. The tenant is the identity foundation. Management groups, subscriptions, resource groups, and resources are Azure management scopes. Some controls, such as Azure role-based access control and Azure Policy, can be assigned at different scopes and inherited downward. Other settings are service-specific. So the hierarchy is a useful architecture model, not a promise that every Azure feature behaves identically at every layer.

The Short Version

Most Azure designs use this mental model:

Microsoft Entra Tenant
  |
  +-- Root Management Group
      |
      +-- Management Group
          |
          +-- Subscription
              |
              +-- Resource Group
                  |
                  +-- Resources

In simpler diagrams, you may see the root management group omitted:

Tenant
  |
  +-- Management Group
      |
      +-- Subscription
          |
          +-- Resource Group
              |
              +-- Resources

Both diagrams are useful. The detailed version shows that every Microsoft Entra tenant has a top-level root management group. The simplified version is easier to remember when you are first learning how Azure organizes responsibilities.

Use this table as a starting map:

Layer	Main Job	Architecture Question
Tenant	Identity foundation for users, groups, applications, and workload identities.	Who or what can authenticate?
Management group	Organizes subscriptions for governance at scale.	Which subscriptions should share rules and access patterns?
Subscription	Major boundary for billing, quotas, access control, policy, and workload separation.	Which team, environment, platform, or workload owns this boundary?
Resource group	Logical container for resources that often share ownership, lifecycle, deployment, or operations.	Which resources should be managed together?
Resource	The actual Azure service instance.	How should this service be configured, secured, monitored, and paid for?

Do not worry if some names still feel new. The important point is simple: Azure gives you different scopes for different kinds of decisions.

Tenant

A tenant represents an instance of Microsoft Entra ID. Microsoft Entra ID is Microsoft's cloud identity service for users, groups, applications, and workload identities.

In plain language, the tenant is the identity home for an organization in Azure. It helps answer questions such as:

Which users can sign in?
Which groups represent teams, administrators, developers, operators, or auditors?
Which applications and automation tools can authenticate?
Which identities are used by workloads running in Azure?
How should access be governed across many subscriptions?

The tenant is not where most application resources are deployed. A storage account, virtual machine, database, or web app is deployed into a subscription and resource group. The tenant matters because those resources still need identities to administer them, deploy them, connect to them, and use them.

For example, a company may have one Microsoft Entra tenant for its organization. Inside that tenant, it may have groups for platform administrators, network operators, security readers, finance application owners, and retail application developers. Those groups can then receive access at the right Azure scopes.

Architecturally, tenant design affects:

Authentication and sign-in.
Central identity governance.
User, group, and application identity management.
Cross-subscription access patterns.
How external users, partners, or automation identities are handled.

A useful question is:

Which identities need access to Azure, and at what scope should that access begin?

Management Groups

Management groups organize subscriptions. They are mainly used when an organization has multiple subscriptions and needs consistent governance across them.

A management group does not contain virtual machines, databases, or storage accounts directly. It contains child management groups and subscriptions. Its value is that Azure controls can be assigned above individual subscriptions and inherited by the subscriptions beneath it.

For example, a company might want all production subscriptions to follow stricter rules than development subscriptions. Instead of configuring each subscription one by one, the company can place production subscriptions under a production management group and assign common governance there.

Management groups are especially useful for:

Applying Azure Policy across many subscriptions.
Assigning access for central platform or security teams.
Separating business units, regions, environments, or workload categories.
Supporting enterprise landing zones.
Keeping governance consistent as the number of subscriptions grows.

A landing zone is a prepared Azure environment where workloads can be deployed with agreed identity, networking, security, governance, monitoring, and cost controls already in place. It is not a single Azure service. It is a designed foundation that helps application teams deploy workloads without rebuilding the basic platform controls each time.

This chapter only introduces the idea because landing zones depend on the hierarchy. The Azure Governance chapter will return to landing zones in more depth, especially how they work with Azure Policy, Azure RBAC, resource locks, tags, and enterprise governance.

Azure Policy is Azure's service for defining and enforcing rules about resources, such as allowed regions, required tags, or blocked public exposure. You do not need its details yet. For this section, remember that policy becomes much easier to manage when subscriptions are organized into meaningful management groups.

A useful question is:

Which subscriptions should inherit the same governance rules?

Subscriptions

A subscription is one of the most important Azure architecture boundaries. It is where Azure resources are deployed, billed, governed, and limited by quotas.

If you come from AWS, a subscription can feel somewhat like an AWS account. If you come from GCP, it can feel somewhat like a GCP project. Those comparisons are useful, but not exact. In Azure, the subscription works together with the tenant, management groups, resource groups, Azure RBAC, Azure Policy, and networking boundaries.

Subscriptions help separate concerns such as:

Production and non-production environments.
Platform services and application workloads.
Business units or product teams.
Regulated and non-regulated workloads.
Different cost centers or funding models.
Quota-heavy workloads that need their own limits.

This is why treating a subscription only as a billing container is a mistake. Billing matters, but the subscription also affects access control, policy assignment, resource provider registration, quotas, deployment organization, and operational ownership.

For example, a company might use separate subscriptions for:

Shared connectivity services.
Central monitoring and management.
Identity-related infrastructure.
Finance production workloads.
Finance non-production workloads.
Retail production workloads.
Retail non-production workloads.

This separation gives each boundary clearer ownership, cost visibility, policy control, and operational responsibility.

A useful question is:

Does this workload need its own subscription boundary, or can it safely share one with related workloads?

Resource Groups

A resource group is a logical container for Azure resources inside a subscription. Every Azure resource belongs to one resource group.

Resource groups are a visible and required part of Azure's operating model. They are not just folders for neatness. They help teams manage deployment, permissions, lifecycle, cost organization, cleanup, and operations.

The most useful rule of thumb is:

Put resources in the same resource group when they are managed together.

Managed together can mean several things:

They belong to the same application or component.
They are deployed by the same pipeline.
They are owned by the same team.
They have the same lifecycle.
They are monitored and operated together.
They should be cleaned up together.

For example, a small web application might have one resource group for non-production resources and one resource group for production resources. A larger system might split resource groups by component, such as app, data, networking, and observability, because those pieces have different owners, deployment cycles, or operational risks.

Resource groups are useful scopes for Azure RBAC, Azure Policy, resource locks, deployments, and cost analysis. Azure RBAC is Azure's role-based access control system. It lets teams assign permissions such as reader, contributor, or owner at different scopes. You do not need every role yet; the important point is that access can be assigned at the resource group when a team should manage a set of related resources.

There are two cautions:

A resource group is a management scope, not the strongest isolation boundary in Azure.
Deleting a resource group can delete the resources inside it, so lifecycle grouping matters.

A useful question is:

Which resources should share ownership, deployment, and lifecycle?

Resources

Resources are the actual Azure service instances that a team deploys and operates.

Examples include:

Virtual machines.
Storage accounts.
Virtual networks.
Databases.
App services.
Key vaults.
Monitoring workspaces.

Each resource belongs to a subscription and a resource group. Each resource also has service-specific settings. For example, a storage account has settings for replication, network access, encryption, containers, lifecycle rules, and diagnostics. A virtual network has address spaces, subnets, routing, and security controls. A database has compute size, backup settings, access rules, and availability choices.

The hierarchy helps place the resource, but the resource still needs thoughtful design.

For example, a storage account may inherit policy and access assignments from parent scopes, but the team still needs to decide whether public network access is allowed, whether private endpoints are required, which identities can read data, which logs are collected, and what retention rules apply.

A useful question is:

What does this specific resource need for security, networking, resilience, monitoring, and cost control?

How the Layers Work Together

The hierarchy is useful because different decisions belong at different scopes.

Decision	Common Scope	Why It Belongs There
Identity foundation	Tenant	Users, groups, applications, and workload identities are managed centrally.
Broad governance	Management group	Many subscriptions can inherit the same policy and access model.
Billing and major ownership	Subscription	Cost, quotas, workload boundaries, and platform ownership often start here.
Deployment and lifecycle	Resource group	Related resources can be deployed, operated, and retired together.
Service configuration	Resource	Each service has its own security, networking, scaling, and monitoring settings.

Inheritance is helpful, but it is not magic. Assigning a policy at a management group can influence child subscriptions. Assigning a role at a subscription can grant access across resource groups inside that subscription. But service-specific design still happens at the resource level.

A strong Azure design uses the hierarchy to avoid two extremes:

Managing everything one resource at a time.
Putting everything under broad permissions and hoping naming conventions will keep it clear.

The better approach is to choose scopes intentionally.

Example: Enterprise Landing Zone

A global enterprise may organize Azure like this:

Microsoft Entra Tenant
  |
  +-- Root Management Group
      |
      +-- Management Group: Corporate
          |
          +-- Management Group: Platform
          |   |
          |   +-- Subscription: Connectivity
          |   +-- Subscription: Identity Services
          |   +-- Subscription: Management
          |
          +-- Management Group: Landing Zones
              |
              +-- Management Group: Finance
              |   |
              |   +-- Subscription: Finance Production
              |   +-- Subscription: Finance Non-Production
              |
              +-- Management Group: Retail
                  |
                  +-- Subscription: Retail Production
                  +-- Subscription: Retail Non-Production

The exact names are less important than the separation of responsibilities.

In this example, the landing zone is the prepared place where business workloads can run. The organization is not giving each application team an empty subscription and asking them to invent networking, logging, security, access control, and policy from scratch. Instead, the platform team creates a governed structure that application teams can use consistently.

The platform subscriptions hold shared services such as connectivity, management, and identity-supporting infrastructure. These services support many workloads, so they are separated from individual application subscriptions. The workload subscriptions hold application systems owned by business or product teams. Production and non-production are separated so policies, access, cost, and operational risk can be managed differently.

A landing zone usually includes decisions such as:

Which management group the workload subscription belongs to.
Which policies are inherited by default.
Which identity groups receive access.
Which network pattern the workload should use.
Which logging, monitoring, and security settings are required.
Which tags and budgets are needed for ownership and cost reporting.

You do not need the full landing zone design method yet. For now, notice how the hierarchy gives the landing zone somewhere to live: management groups organize the subscriptions, subscriptions separate workloads and environments, and resource groups organize the resources inside each workload.

This kind of structure helps the organization answer practical questions:

Where should central security teams have read access?
Where should application teams have contributor access?
Which subscriptions must use approved regions?
Which subscriptions need stricter controls for production data?
Where should shared networking services live?
How should cost be reported by business unit or environment?

Without the hierarchy, these questions turn into one-off exceptions. With the hierarchy, many of them become repeatable design decisions.

Example: A Smaller Product Team

The hierarchy is not only for large enterprises. A smaller team can still use it simply.

Imagine a team building a customer portal. The organization may already have one tenant and a small management group structure. The product team might use two subscriptions:

Management Group: Product Workloads
  |
  +-- Subscription: Customer Portal Production
  |   |
  |   +-- Resource Group: rg-customer-portal-prod-app
  |   +-- Resource Group: rg-customer-portal-prod-data
  |
  +-- Subscription: Customer Portal Non-Production
      |
      +-- Resource Group: rg-customer-portal-dev
      +-- Resource Group: rg-customer-portal-test

This is not the only possible design. The point is that the hierarchy lets the team express important boundaries:

Production is separate from non-production.
Application resources and data resources can have different lifecycle and access needs.
Developers can receive broader access in non-production than in production.
Production cost and monitoring can be tracked more clearly.
Policies for production can be stricter than policies for development and test.

Even for a small workload, the hierarchy turns vague organization into explicit architecture choices.

Common Mistakes

Treating the hierarchy as naming only. Tenant, management groups, subscriptions, and resource groups are control points, not just labels.
Putting too many unrelated workloads into one subscription. This can make access, quotas, cost, policy, and operations harder to manage.
Creating a management group tree that mirrors the company chart too closely. Governance structure should support policy and ownership needs, not every reporting line.
Ignoring management groups until governance becomes messy. They are easier to introduce before there are many subscriptions with inconsistent rules.
Treating subscriptions only as billing containers. They also matter for access control, policy, quotas, deployment, and workload separation.
Using resource groups as junk drawers. A resource group should usually reflect ownership, lifecycle, deployment, or operational logic.
Assuming resource groups are strong isolation boundaries. They are useful management scopes, but subscriptions, networking, identity, and policy are often more important for isolation.
Assigning permissions directly to individual resources too often. Resource-level permissions are sometimes needed, but frequent one-off assignments become hard to audit.
Assuming inherited controls replace resource design. Parent-scope policy and RBAC help, but each resource still needs correct configuration.

If Someone Asks You

If someone asks, "Why does Azure have tenant, management groups, subscriptions, and resource groups?" a clear answer is:

Azure uses these layers to place different architecture responsibilities at the right scope. The tenant anchors identity. Management groups organize subscriptions for governance. Subscriptions provide major boundaries for billing, quotas, access, policy, and workload separation. Resource groups organize resources that share ownership, deployment, lifecycle, or operations. Resources are the actual services the team configures and runs.

This answer is more useful than reciting the hierarchy alone because it explains what each layer is for.

What You Should Remember

The Azure hierarchy is valid and worth learning because it is how Azure turns cloud resources into managed architecture.

The most important idea is this:

Azure hierarchy is not just where resources live. It is where responsibility is assigned.

Use the hierarchy to decide where identity, governance, billing, ownership, deployment, lifecycle, monitoring, and service configuration belong. When those scopes are clear, Azure architecture becomes much easier to explain and operate.

Questions to Check Your Understanding

What is the difference between a tenant and a subscription?
Why are management groups useful when an organization has many subscriptions?
Why should subscriptions not be treated only as billing containers?
What makes a good resource group boundary?
Why is inherited governance helpful but not enough by itself?
How would you organize production and non-production workloads in Azure, and why?