What Is a Cloud Account? Organizations, Projects, Billing, and Access
What a cloud account really contains: resources, identity, billing, and quotas. How AWS accounts, Google Cloud projects, and Azure subscriptions differ, and what to review when you take one over.
A cloud account is the container that every provider uses to tie resources, identity, and billing together. Before you create a server, a bucket, or a database, the provider needs to know who owns it, who may touch it, and who pays for it. This guide explains what an account is, how AWS, Google Cloud, and Azure structure theirs differently, and what to check when you take over an account someone else set up.
What a cloud account actually holds
Strip away the console and an account is four things bound together. The first is a resource boundary: every virtual machine, disk, IP address, and DNS zone belongs to exactly one account. The second is an identity store: the people, applications, and roles that may act inside that boundary. The third is a billing relationship: a payment method, invoices, and a running usage meter. The fourth is a set of quotas: the maximum servers, vCPUs, IP addresses, or API calls the account may consume.
These four pieces travel together. When you take over an account you inherit all four, including whatever limits and payment terms the previous owner accumulated.
- Resource boundary
- Everything you create lives inside one account or one project
- Identity store
- Users, roles, service accounts, and the permissions attached to them
- Billing relationship
- Payment method, invoices, credits, and the usage meter
- Quotas
- Provider-set ceilings on servers, vCPUs, IPs, and API rates
How the three hyperscalers structure accounts
The word “account” means something slightly different on each large provider, and the differences matter once you run more than one workload.
AWS: accounts and Organizations
On AWS the account is the hard boundary. Each account has a twelve-digit ID, a single root user identified by an email address, its own bill, and its own service quotas. AWS Organizations groups many accounts under one management account, applies service control policies, and rolls charges into consolidated billing.
Google Cloud: organizations, folders, projects, and billing accounts
Google Cloud splits the idea into layers. Resources live in a project, which has a name, a project ID, and a project number. Projects can sit inside folders under an organization resource tied to a Google Workspace or Cloud Identity domain. Billing is separate: a Cloud Billing account holds the payment method, and a project must be linked to one before it can consume paid services. One billing account can pay for many projects.
Azure: tenants, subscriptions, and resource groups
Azure starts with a Microsoft Entra ID tenant, which is the identity directory. Under the tenant sit one or more subscriptions, and a subscription carries a billing arrangement and a quota set. Inside a subscription, resources are grouped into resource groups for lifecycle and access control. Management groups sit above subscriptions to apply policy broadly. A subscription is the closest Azure equivalent to an AWS account.
| Concept | AWS | Google Cloud | Azure |
|---|---|---|---|
| Resource container | Account | Project | Subscription and resource group |
| Grouping layer | Organizations and OUs | Organization and folders | Management groups |
| Identity directory | IAM, IAM Identity Center | Cloud Identity or Workspace | Microsoft Entra ID tenant |
| Billing object | Account, or consolidated billing | Cloud Billing account | Billing account and subscription |
| Quota scope | Per account, per region | Per project, per region | Per subscription, per region |
Identity and access: who can act inside the account
Every provider has a privileged owner identity. AWS calls it the root user, Google Cloud grants the Owner role at project or organization level, and Azure has the Global Administrator in the tenant plus the Owner role on subscriptions. Standard practice is to protect it with multi-factor authentication and then stop using it for daily work.
Below the owner sit the everyday identities. AWS uses IAM users, groups, roles, and JSON policies. Google Cloud uses IAM principals (users, groups, service accounts) bound to predefined or custom roles. Azure uses role-based access control with built-in roles such as Contributor and Reader scoped to a subscription, resource group, or single resource. In all three the pattern is the same: grant the narrowest role that lets the job get done.
Billing, payment, and account state
An account is only useful when its billing state lets it create resources. New accounts typically start in a limited state until a payment method is verified, and some services stay locked until the account is upgraded from a trial to full pay-as-you-go. Google Cloud makes this explicit: a billing account is either a free trial account or a paid one, and upgrading is a deliberate step. Azure offers a free account that converts to pay-as-you-go. AWS accounts are pay-as-you-go from the start with a free tier layered on top.
Billing history also shapes what the account can do. Providers raise or lower default quotas partly on the basis of account age and payment record, which is why an account with several months of settled invoices often has more headroom than a brand new one. Labels such as “Old Billing Paid” on a marketplace listing restate exactly that: earlier billing periods have been paid. They do not promise a specific quota, and the only reliable way to learn the current limit is to read it in the console after you sign in.
Credits are a separate layer. Promotional and trial credits are applied against usage before the payment method is charged. They usually expire, often apply only to certain services, and are set by the provider under terms that change. Treat a credit balance as a time-limited discount rather than as cash.
What to review when you take over an account
Whether you inherit an account from a colleague, a contractor, or a marketplace, the checklist is the same.
- Owner identity. Confirm you control the root user, the Google Cloud Owner principal, or the Azure Global Administrator. Rotate the password and enrol your own multi-factor device.
- Recovery contacts. Update the email address, phone number, and any alternate contacts so recovery flows reach you rather than the previous holder.
- Existing identities. List every IAM user, service account, access key, and role. Remove anything you do not recognise and rotate keys you keep.
- Billing. Check the payment method, billing contact, linked billing accounts or subscriptions, and invoice status. Note credit balances and expiry dates.
- Quotas. Open the quota page (AWS Service Quotas, Google Cloud Quotas, Azure Usage + quotas) and record the limits for the regions and services you plan to use.
- Running resources. Inventory what is already deployed. Orphaned instances and disks cost money.
- Audit logs. Verify AWS CloudTrail, Google Cloud Audit Logs, or Azure Activity Log is recording changes.
- Terms of service. Read the acceptable use policy and confirm your workload is allowed. Providers suspend accounts that break their terms, and no account label protects against that.
Where to go next
If you are comparing accounts across the three hyperscalers, the listed variants are on the Buy AWS Accounts page, the Buy Google Cloud Accounts page, and the Buy Azure Accounts page. Each listing restates only what its label says, so run the review checklist once you sign in.
Related reading in the Cloud Library:
- Cloud account handover checklist: what to review when you take over an account
- IAM basics: users, roles, and policies across cloud providers
- Cloud service quotas and limits explained
- How cloud credits work: trials, promotional credits, and billing
Browse every guide in the Cloud Library, or see how the providers line up on the AWS vs Azure comparison page.