What Is a Cloud Account? What It Is, and What It Is Not

Ask ten engineers what a cloud account is and most will say "a login". That answer is the root of a surprising share of cloud problems, because an account is at least four distinct things wearing one name.

The four layers

1. An identity. Credentials that authenticate a human or a machine. A password, an MFA device, a set of recovery options. This proves who is asking.

2. A billing relationship. A payment instrument, a currency, an invoice cycle, a set of people authorised to change it, and possibly a credit balance. This determines who pays and who can stop the spending.

3. A resource container. The boundary inside which virtual machines, storage, networks and managed services exist. Resources belong to exactly one container.

4. A permission boundary. The policy layer deciding who may do what to which resource, including machine identities that hold long-lived credentials of their own.

Different platforms bundle these differently, and knowing which model you are in tells you what to check.

VPS providers collapse all four into one thing, which is exactly why they are simpler to reason about — and why a single credential compromise there is more consequential.

Why the distinction matters practically

Because control of one layer does not imply control of another.

• You can hold the login and not be able to change the payment method.
• You can be a billing administrator and be unable to delete a virtual machine.
• You can reset every password and leave a machine identity with full access untouched.

That last case is the one that causes real trouble. API keys, service accounts and service principals are credentials that do not care about passwords or MFA. They keep working until someone deliberately revokes them.

A hand-over that changed the password and nothing else has changed authentication and left authorisation intact.

Machine identities: the part people miss

Every major platform has them under different names — IAM access keys and roles on AWS, service accounts and keys on Google Cloud, service principals and app registrations on Azure, API tokens on most VPS providers.

They exist so software can authenticate without a human present, which is exactly why they survive every human-facing security change. Auditing them means listing every one, establishing what it is for, deleting what is unexplained, and rotating what remains.

What actually transfers with an account

When an environment changes hands, these travel with it:

• Running resources and the data on them
• Configured networking, firewall rules and DNS
• Service limits and quota increases already approved
• Account history, which influences future limit requests
• Any remaining credit balance, subject to its own terms
• Every machine identity that has not been revoked

And these do not automatically change hands:

• Genuine control, until credentials are rotated and identities audited
• Support entitlements, which may be tied to a contract rather than the account
• Compliance posture, which is a property of how you operate, not of the account
• Responsibility for acceptable use, which attaches to whoever operates the environment

Quota and limits: the invisible specification

Two accounts on the same provider with identical console screens can have very different capabilities, because service limits are per account and per region.

A new account has conservative ceilings on CPUs, IP addresses, storage totals and concurrent instances. An account with approved increases can provision immediately what a fresh one cannot. This is why environments are described by vCPU, server or instance counts — those figures describe real ceilings rather than marketing.

Responsible operation

Whatever route you take to an environment, two obligations come with it and cannot be delegated:

1. The provider's acceptable-use policy applies to you. It governs what may run, how email may be sent, and what happens when it is breached. Availability of an account does not modify those terms.
2. You are responsible for what the infrastructure does. Data protection obligations, licensing, and the lawful use of compute are all yours.

Operating within those boundaries is not a formality. It is what keeps an environment usable rather than suspended.

Frequently asked questions

Is an account the same as a project or subscription? No, and the mapping differs by platform. On AWS the account is the container; on Google Cloud and Azure the container sits below the identity and billing layers.

Does changing the password give me control? It gives you authentication. Control also requires auditing permissions and revoking machine credentials.

Do quotas transfer? Yes — they belong to the account and region. They do not follow you into a different account.

What is the first thing to do with a new environment? Rotate credentials, enable MFA, then enumerate every machine identity. The hardening checklist covers the full sequence.

The how it works page sets out the complete process from evaluation to a running environment.