Azure Accounts, Tenants, and Subscriptions: The Building Blocks of Governance
Before anything gets deployed in Azure, there's a governance skeleton underneath it: an identity that's doing the deploying, an organisational boundary that identity belongs to, and a billing/access boundary the resulting resources sit in. Getting these three concepts — account, tenant, and subscription — straight first makes everything downstream (permissions, cost tracking, policy) much easier to reason about.
Azure accounts and tenants
An Azure account represents a user (a person) or an application, it's the identity used to access Azure resources, and it's the basis of authentication. It's bad practice to hardcode a personal user ID and password into an application; assign the application its own account instead (in practice, this is what an app registration or managed identity does).
A tenant represents an organisation or company. It's usually associated with a domain name (company.com); if no custom domain is provided, Microsoft assigns one ending in .onmicrosoft.com. Structurally, a tenant is a dedicated instance of Microsoft Entra ID — the identity service Microsoft renamed from Azure Active Directory in 2023, purely a naming change with no effect on existing credentials, configurations, or APIs.
Every account must belong to at least one tenant — an account that isn't part of a tenant isn't an Azure user. An account can belong to more than one tenant, has a default tenant when you sign in, and can switch between the tenants it belongs to. Creating a new tenant is relatively easy and something you can do at any time, not a one-off setup step tied to a subscription.
Azure resources
Any entity managed by Azure counts as a resource — virtual machines, web apps, storage accounts, and SQL databases are all examples. Some resources create sub-resources as a side effect: deploying a virtual machine, for instance, typically creates a public IP address, a network interface card, and a network security group alongside it. These sub-resources are themselves resources in their own right.
Permissions aren't limited to individual resources — Azure RBAC role assignments can be scoped at four levels: management group, subscription, resource group, or resource, with each level inheriting from its parent. So a role granted at the management group level applies to every subscription underneath it, all the way down to individual resources, unless something more specific overrides it further down the hierarchy.
Subscriptions: billing and access-control boundaries
A subscription is a billing unit, it determines how the resources assigned to it get billed. The hierarchy runs resources → resource groups → subscriptions → management groups, with each level inheriting settings from the one above it.
Subscription types vary (free, enterprise, sponsorship, pay-as-you-go), and the type determines who pays for what's deployed under it. Beyond billing, a subscription serves two distinct boundary roles:
1) Billing boundary: determines how an account is billed for Azure usage. You can create multiple subscriptions for different billing requirements, and Azure generates separate reports and invoices per subscription, which helps organise and manage costs.
2) Access control boundary: Azure applies access-management policies at the subscription level, so separate subscriptions can reflect different organisational structures (different departments getting different policies, for example). This lets you manage and control access to whatever resources get provisioned under a given subscription.
Each subscription can only be assigned to one tenant, but a single tenant can have many subscriptions — you can move a subscription between tenants using the "Change directory" option.
Management groups: scaling governance above subscriptions
Once you're managing more than a handful of subscriptions, applying access, policy, and compliance settings to each one individually stops scaling. Management groups sit above subscriptions in the hierarchy for exactly this reason: you organise subscriptions into management groups and apply governance conditions there, and every subscription within the group automatically inherits those conditions — the same inheritance pattern resource groups and resources follow further down. Management groups can themselves be nested, giving enterprise-grade governance regardless of how many subscriptions, or what types, sit underneath.
A few hard limits apply: a single directory supports up to 10,000 management groups, a management group tree can be up to six levels deep (not counting the root or subscription levels), and each management group or subscription can have only one parent.
Where this fits into the rest of the series: how you actually structure management groups and subscriptions for an organisation — flat vs. deep hierarchies, departmental vs. geographic grouping, and where landing zones and Blueprints come in — is covered separately, since it's a design question rather than a definitional one.