What Is a Cloud Account? Tenants, Projects and Subscriptions Explained

One word, at least three meanings

Ask three engineers what a "cloud account" is and you will get three answers. The first thinks of the login: an email address, a password and a second factor. The second thinks of the bill: whoever holds the account gets the invoice. The third thinks of the fence around resources: the account is the box that virtual machines, buckets and databases live inside.

All three are right, and the confusion comes from the fact that providers split these roles differently. AWS bundles them into a single object. Azure separates identity from billing from resources with three named layers. Google Cloud puts resources in projects and money in a separate billing account. Developer clouds such as DigitalOcean and Hetzner keep the whole thing flat.

This article walks through each model so that words like tenant, subscription, project and organization stop sounding interchangeable. Once the vocabulary is clear, decisions about how to structure a new environment become far easier.

The three jobs an account performs

Identity and access

Somebody has to prove who they are before they can create a server. Every provider therefore has a root identity that owns the account, plus a way to add more people with narrower permissions. On AWS that is the root user and IAM. On Azure it is Microsoft Entra ID. On Google Cloud it is a Google identity attached to Cloud IAM roles.

Billing relationship

The second job is commercial. A payment method, a billing address, a tax status and an invoice history all hang off the account. Promotional balances such as free trial credit are attached at this layer, which is why credit does not automatically follow a resource if you move it somewhere else.

Resource and quota boundary

The third job is containment. Quotas (how many vCPUs you may run, how many IP addresses you may hold) are counted per boundary. Deleting the boundary deletes everything inside it. Access policies, cost reports and audit logs are all scoped to it as well.

Keep those three jobs in mind. The rest of this guide is really about where each provider draws the lines between them.

AWS: the account does all three jobs at once

An AWS account is the simplest model to explain because one object carries identity, billing and resources together. Sign up, and you receive a twelve-digit account ID, a root user and an empty environment in every enabled region. Everything you build lives inside that ID, and the monthly invoice is addressed to it.

The trade-off is that a single account becomes crowded quickly. Production and staging share quotas, IAM policies grow tangled, and one compromised credential can reach everything. AWS Organizations exists to solve that: it lets you create many accounts, group them into organizational units and pay for all of them through one management account with consolidated billing. The AWS Organizations user guide describes the service in full.

So when people say "an AWS account", they might mean the whole organization or one member account within it. In practice a well-run AWS estate is a tree of accounts, each used as a blast-radius boundary. Our separate guide to AWS Organizations and multi-account design covers the patterns in depth, and the AWS account listings on the marketplace describe what a single supplied account contains.

Azure: tenant above, subscription below, resource group inside

Microsoft separates the three jobs explicitly. At the top sits the tenant, a Microsoft Entra ID directory that holds users, groups and applications. The tenant is purely about identity; it owns no virtual machines and produces no bill.

Below the tenant come subscriptions. A subscription is the billing and quota container: every resource belongs to exactly one subscription, the invoice is generated per subscription, and vCPU quotas are counted per subscription per region. One tenant can hold many subscriptions, and a person in the tenant can be granted roles across several of them.

Inside a subscription, resources are grouped into resource groups, which are lifecycle containers rather than billing ones. Delete the group and its contents go with it. Above subscriptions, management groups let large organizations apply policy to many subscriptions at once.

The phrase "Azure account" is therefore ambiguous by design. What a buyer or a new hire usually receives is access to a subscription inside a tenant. The article on Azure subscriptions, resource groups and management groups shows how these layers fit together, and Microsoft's Azure Resource Manager overview explains the scopes formally.

Google Cloud: projects hold resources, billing accounts hold money

Google Cloud takes the separation one step further. The unit that contains resources is the project. Compute Engine instances, Cloud Storage buckets, service accounts and API enablement all live inside a project, and each project has a globally unique project ID.

Money lives elsewhere, in a billing account. A billing account carries the payment method and receives the invoice, and a project must be linked to one before it can consume paid services. The link is loose: one billing account can fund many projects, and a project can be re-pointed at a different billing account without moving any resources.

Above projects, an organization node (tied to a Google Workspace or Cloud Identity domain) and optional folders provide the hierarchy for IAM and policy inheritance. Individual Google accounts without a domain can still create projects, but they have no organization node above them.

The practical consequence is that a promotional balance, such as the free trial credit, belongs to a billing account rather than to a project. Our guide to Google Cloud projects and billing accounts unpacks that relationship, and the Google Cloud account listings describe supplied accounts in these terms.

Developer clouds keep the hierarchy flat

Providers built for individual developers and small teams deliberately avoid deep trees. DigitalOcean has a single account that can be converted into or joined to a Team; inside it, Projects are lightweight labels for grouping Droplets, databases and domains. Billing is per account, and the Droplet limit is counted per account too.

Hetzner Cloud uses Projects as its main container. Each project has its own servers, networks, volumes and API tokens, and the limits on how many servers you may create are tracked per project. Billing still rolls up to one customer account.

Vultr, Linode (now Akamai Cloud) and UpCloud follow a similar shape: one login, one invoice, optional sub-users, and grouping features that are organizational rather than structural. This flatness is one reason these platforms are quicker to learn; the AWS versus DigitalOcean comparison looks at what you gain and lose when the hierarchy disappears.

Same idea, different name

The table below lines up the vocabulary. Read across a row to find the equivalent concept on each platform; read down a column to see how one provider stacks its layers.

Notice that "account" appears in different rows for different providers. That single observation explains most of the confusion in cloud conversations.

Common questions