Google Cloud Accounts Explained: Identity, Billing and the Resource Hierarchy

Most people describe a Google Cloud account as "a login". That description causes more confusion than any other single idea on this platform, because Google Cloud deliberately separates three things that other providers bundle together: who you are, who pays, and where resources live.

Getting those three apart in your head is what makes the difference between a clean hand-over and a month of billing surprises.

The three layers that make up an account

At the top sits an identity — either a consumer Google account or a Cloud Identity / Workspace user. This is what authenticates. It owns nothing by itself.

Below that sits one or more Cloud Billing accounts. A billing account holds a payment instrument, a currency, an invoice cycle and a set of billing administrators. Crucially, a billing account is not owned by a project; projects are linked to it.

Below that sit projects. A project is the container for actual resources: Compute Engine instances, Cloud Storage buckets, BigQuery datasets, Vertex AI endpoints, service accounts, API enablement and quota. Every resource belongs to exactly one project.

Organisations and folders sit above projects for larger customers, but most marketplace environments are a plain identity to billing account to project chain.

The practical consequence: you can hold the login and still not control the money, or control the money and not own the resources. Both are broken hand-overs.

What each layer controls

Compute Engine, and why machine type matters more than brand

Compute Engine is where most workloads start. Machine families are easier to reason about by shape than by name:

• E2 — cost-optimised, shared or dedicated cores. Fine for light web servers and internal tools.
• N2 and N2D — balanced general purpose, the default for application servers.
• C3 and C2 — compute-optimised, higher sustained clock, for CPU-bound processing.
• M-series — memory-optimised, for large in-memory databases and caches.
• A-series and G-series — accelerator-attached, for training and inference.

Persistent Disk type is a second and equally important axis. Balanced PD suits most application workloads, SSD PD matters for databases, and Local SSD gives the lowest latency but does not survive an instance stop. Disk size also determines throughput, not just capacity, which is why an undersized boot disk can throttle an otherwise well-specified instance.

Credits are not the same as a paid account

A Google Cloud environment can carry promotional credit, and two common states behave very differently:

• A free-trial account has a credit balance and platform restrictions — quota ceilings, some services unavailable, and an automatic stop when the trial ends.
• An upgraded or paid account has a live billing relationship. It may still carry a credit balance, but the trial restrictions are gone.

When a listing is described by credit value, the numbers that matter are the remaining balance and its expiry date, not the headline figure. Some credit programmes also carry service restrictions. If you intend to run accelerator workloads on credit, confirm the credit applies to GPU SKUs before committing.

Teams that specifically want a credit-bearing environment usually weigh a Google Cloud account against what they realistically expect to spend in the first ninety days, rather than against the credit headline.

Quota is the constraint people forget

Every project carries per-region quotas: CPUs, in-use IP addresses, persistent disk capacity, GPUs per family. A brand-new project starts with low ceilings. A project that has been running for a while and has had increases approved is materially more useful — and that quota history does not carry over if you create a fresh project inside the same account.

Before committing, check quota in the regions you actually intend to deploy to, not just the default one.

IAM: the part that decides whether a transfer is real

IAM bindings can exist at organisation, folder, project and resource level, and they survive a password change. A genuine hand-over means:

1. Primary identity credentials rotated, recovery phone and email replaced.
2. Two-step verification re-enrolled on hardware you hold.
3. Every unexpected IAM principal reviewed and removed at every level.
4. Service accounts audited — keys listed, unused keys deleted, remaining keys rotated.
5. Billing account administrators reduced to people you know.
6. Budget and alert thresholds set before the first deployment.

Step four is the one most often skipped. A service account key is a long-lived credential that ignores password changes and two-step verification entirely.

Where Google Cloud genuinely fits

Google Cloud is strongest where its managed data and machine-learning services pull their weight: BigQuery for analytical workloads without cluster management, GKE for teams already committed to Kubernetes, and Vertex AI where you want managed endpoints rather than self-hosted inference. Live migration of VMs during host maintenance is a real operational advantage that rarely appears in comparisons.

It is less obviously right for a single small VPS-style server, where a DigitalOcean account or Hetzner account will usually cost less and carry less conceptual overhead. Matching the platform to the shape of the workload beats brand preference every time, a point worth reading alongside the hyperscale versus VPS comparison.

Frequently asked questions

Does changing the password transfer ownership? No. It changes authentication only. Billing administrators, IAM bindings and service account keys all persist until each is individually reviewed.

Can credits be moved to a different billing account? Generally no. Promotional credits attach to the billing account that received them.

What should I check about region availability? Confirm the machine types and accelerator families you need are actually available in your target region, and that project quota there is non-zero. Availability varies more than the marketing map suggests.

Is a free-trial environment enough for production? No. Trial restrictions and the automatic stop at trial end make it unsuitable for anything you depend on. Evaluate on trial, then move to a properly billed environment.

Reviewing the configurations on the Buy Google Cloud Account listing against your target region and quota needs is the fastest way to tell whether a given environment will support what you are building.