If what a cloud account is answers the definition question, this article answers the mechanical one. How do the identity, the money and the resources actually connect? Azure and Google Cloud make good examples because both separate those layers deliberately, and both are listed on the marketplace with options that only make sense once you see the layers.
Layer one: the root identity and everyone under it
An account begins with a single root identity. On Azure, that identity signs in to the Azure portal and controls access through Microsoft Entra ID, formerly Azure Active Directory. On Google Cloud, the account is tied to a Google identity, either a personal account or a Cloud Identity or Workspace identity.
From the root, you create additional users, groups, roles and service accounts. The point of this layering is least privilege: the root identity is kept for rare administrative tasks, while daily work runs under identities that can only touch what they need. Multi-factor authentication on the root identity is the single most important control in the whole structure.
Layer two: the billing profile
Resources cost money, so every account needs a billing relationship. Here the two platforms diverge in a way that trips up newcomers.
- Azure bills through subscriptions. An account can create one or more subscriptions, each with its own billing scope, and resources are created inside a subscription.
- Google Cloud bills through a Cloud Billing account. Projects are linked to a billing account, and without an active link most resources cannot be provisioned or will be shut down once any trial period ends.
This is why the Buy Google Cloud Account options are described by balance, such as “Google Cloud Prepaid $300 Credit Account” or “Google Cloud $1K Credit Account”. The credit lives in the billing layer, and projects draw on it. On the Buy Azure Account page, “Azure Pay-As-you-Go Account” describes a subscription billed on usage, while the credit-labelled options describe a balance that offsets usage for a period.
Layer three: containers for resources
Neither platform lets resources float freely. Azure groups them into subscriptions and then resource groups. Google Cloud groups them into projects, optionally arranged under folders and an organization. The container decides three things: which billing profile pays, which identities have access and which quotas apply.
A practical consequence is that one account can hold several isolated environments. A development project and a production project on Google Cloud can share an identity but have separate permissions and separate spending. The same is true of two Azure subscriptions. The Azure subscriptions, accounts and tenants guide and the Google Cloud billing accounts and projects guide cover each hierarchy in depth.
Layer four: quotas and limits
Quotas are the part most people discover by accident. Both platforms start new accounts with conservative defaults. On Google Cloud, quotas apply at the project or region level, and Compute Engine CPU, GPU and certain AI-related quotas frequently require increase requests. Azure accounts can likewise carry elevated quotas for virtual machines, GPU-accelerated instances or specific regions, or they can sit at defaults.
A quota is not a bug or a billing problem. It is the provider’s trust mechanism, and it grows as an account demonstrates legitimate use. The article on vCPU limits and service quotas explains why new accounts start small and how increase requests work.
How the layers interact day to day
A single action touches all four layers. Suppose you create a virtual machine:
| Step | Azure | Google Cloud |
|---|---|---|
| Who is asking | Entra ID identity with a role on the subscription | Google identity with an IAM role on the project |
| Where it lives | Resource group inside a subscription | Project, optionally under a folder |
| Who pays | The subscription’s billing scope | The billing account linked to the project |
| What limits apply | Regional vCPU and family quotas | Per-project and per-region quotas |
If any layer says no, the machine does not launch. A missing role, a project with no billing link or an exhausted quota all produce errors that look different but come from the same model.
What this means for a marketplace listing
An account listed with a credit balance is offering something in the billing layer. An account listed with approved quotas is offering something in the limits layer. Neither changes the identity layer, which you must secure yourself immediately after taking control: change the password, enable multi-factor authentication, audit existing users, roles and service accounts, and rotate any keys.
Every provider also expects accounts to be operated within its terms of service. Understanding the mechanics helps you do that well: you know where the money flows, who can act and what the ceilings are. The Azure section of the cloud FAQ collects further questions about subscriptions and credits.
