Azure Fundamentals: Tenants, Subscriptions and Resource Groups
Understand how Azure tenants, management groups, subscriptions and resource groups fit together, and how to structure them for access control and billing.
Azure organizes everything through four nested scopes: a Microsoft Entra tenant, management groups, Azure subscriptions and resource groups. Getting this structure right early determines how easily you can control access, separate environments and understand your bill, and it is much harder to reorganize once production workloads are running.
The four layers, from top to bottom #
1. Microsoft Entra tenant: identity
A tenant is a dedicated instance of Microsoft Entra ID (formerly Azure Active Directory) that holds your users, groups, app registrations and service principals. It is created when an organization first signs up for a Microsoft cloud service such as Azure or Microsoft 365, and it usually maps to one company. Every subscription trusts exactly one tenant for authentication.
The tenant is about who someone is. It does not contain virtual machines or databases, and it is not itself a billing unit.
2. Management groups: governance at scale
Management groups sit above subscriptions and let you apply Azure Policy and role assignments to many subscriptions at once. Every tenant has a single root management group, and you can build a hierarchy beneath it (Microsoft documents support for up to six levels below the root). A typical layout separates platform subscriptions (networking, identity, shared logging) from application landing zones, and production from non-production.
3. Subscriptions: billing and scale boundary
An Azure subscription is a logical container for resources that is linked to a billing arrangement. It serves three purposes:
- Billing: costs are tracked per subscription and roll up to a billing account.
- Access boundary: role assignments at subscription scope apply to everything inside it.
- Limits: many service quotas, such as regional vCPU limits, apply per subscription.
Subscriptions are created under an agreement type. Common ones include pay-as-you-go (direct, card-based), the Microsoft Customer Agreement, Enterprise Agreements for large organizations, subscriptions provided through a Cloud Solution Provider partner, and Visual Studio subscriber benefits for development and testing. The agreement determines how invoices are structured and who can create new subscriptions.
4. Resource groups: lifecycle containers
A resource group holds related resources that share a lifecycle, such as a web app, its database, its storage account and its Key Vault. Rules worth memorizing:
- Every resource belongs to exactly one resource group.
- Resource groups cannot be nested.
- A resource group has a location, which is where its metadata is stored. The resources inside can be in other Regions.
- Deleting a resource group deletes every resource in it.
- Many resource types can be moved between resource groups or subscriptions, but not all, and moves can require downtime. Check the move support documentation before planning one.
An example layout #
Here is a small but realistic structure for a company running two applications. It follows the general shape recommended by Microsoft’s Cloud Adoption Framework without the full enterprise landing zone.
- Tenant:
contoso.onmicrosoft.com(plus a verified custom domain)- Root management group
- Management group: Platform
- Subscription:
sub-connectivity(hub virtual network, DNS, firewall) - Subscription:
sub-management(Log Analytics workspace, automation)
- Subscription:
- Management group: Production
- Subscription:
sub-shop-prodwith resource groupsrg-shop-web-prod,rg-shop-data-prod
- Subscription:
- Management group: NonProduction
- Subscription:
sub-shop-dev - Subscription:
sub-sandbox(with a tight budget and policy restrictions)
- Subscription:
- Management group: Platform
- Root management group
A single-person project does not need all of this. One subscription with resource groups per environment is a reasonable starting point. The important thing is to use consistent naming from the beginning, for example rg-<app>-<component>-<env>.
How permissions and policy flow through the scopes #
Azure role-based access control (RBAC) assignments and Azure Policy assignments are inherited downward. A role granted on a management group applies to every subscription, resource group and resource beneath it.
| Scope | Typical role assignment | Typical policy |
|---|---|---|
| Management group | Security reader for the security team | Allowed Regions, required diagnostic settings |
| Subscription | Contributor for the platform team | Require specific tags on resource groups |
| Resource group | Contributor for the app team that owns it | Allowed VM sizes |
| Resource | Specific data roles, such as Storage Blob Data Reader | Rarely assigned this low |
Note that Entra ID roles (such as Global Administrator) and Azure RBAC roles (such as Owner) are separate systems. A Global Administrator does not automatically have access to subscriptions, although they can elevate themselves to gain it, which is itself an auditable action.
Deciding how many subscriptions you need #
There is no single right number, but these signals suggest a new subscription:
- Different billing owner. A separate customer, department or cost center that needs its own invoice or budget.
- Different security posture. Production data that non-production teams should never touch.
- Quota pressure. Workloads large enough to hit per-subscription limits.
- Regulatory isolation. Workloads subject to specific compliance controls.
By contrast, a new resource group is the right answer when you just need to group resources that are deployed, updated and deleted together.
Common mistakes to avoid
- Everything in one resource group. A single giant group makes it hard to grant an app team access to its own resources without exposing everything else, and one accidental delete removes the lot.
- Subscriptions named after people. Name subscriptions after the workload and environment, since people change roles and leave.
- Owner granted too widely. Contributor is enough for most engineers; reserve Owner (which can change access) for a small group, and review assignments regularly.
- Ignoring the tenant boundary. Creating a second tenant by accident, for example by signing up with a different email, splits identities and subscriptions in ways that are tedious to merge later.
Tags, costs and resource providers #
Tags
Tags such as costCenter, environment and owner power cost reporting in Microsoft Cost Management. Tags on a resource group are not inherited by the resources inside it by default. Azure Policy includes built-in definitions that can add or inherit tags automatically, which is the reliable way to enforce them.
Budgets
Budgets can be created at subscription or resource group scope and send alerts at thresholds you choose. Like budgets on other clouds, they notify rather than stop resources, though they can trigger action groups for automation. For provider-neutral practices, see our guide to budgets, tagging and right-sizing.
Resource providers
Each Azure service is delivered by a resource provider, such as Microsoft.Compute or Microsoft.Web. A subscription must have a provider registered before you can deploy its resources. The portal registers many automatically; with the CLI or infrastructure as code you may need to register them explicitly.
Limits and quota increases #
Subscriptions have default limits, including regional vCPU quotas per VM family. New and free subscriptions often have lower defaults. You can view usage and request increases on the Quotas page in the Azure portal or by opening a support request. Requests are reviewed against capacity and account standing, so submit them before you need the capacity, and provide accurate details about the workload.
Before assigning roles broadly, work through our cloud account security checklist. If you plan to use AI services, our overview of Azure AI services explains how those resources and their quotas fit into subscriptions. The Microsoft Azure overview covers the wider platform.
For official detail, start with the Azure Resource Manager documentation and the Cloud Adoption Framework, both part of the wider Azure documentation.
Azure subscriptions: frequently asked questions #
What is the difference between a tenant and a subscription?
A tenant is an identity directory holding users and groups. A subscription is a billing and resource container that trusts one tenant for sign-in. One tenant can have many subscriptions.
Can a resource group span multiple Regions?
Yes. The resource group’s own location only determines where its metadata is stored. Resources inside it can be deployed to any supported Region.
Can I move a subscription to another tenant?
Yes, subscriptions can be transferred between tenants, but existing RBAC role assignments, managed identities and some resource configurations are affected. Review Microsoft’s transfer documentation and plan for reassigning access.
Should I use one resource group per application?
Often one per application per environment works well, sometimes split further by lifecycle (for example networking separate from compute). Group resources that you deploy and delete together.
