Getting Started with GCP: Projects, Billing Accounts, and IAM

If you're coming to Google Cloud from AWS or Azure, the first thing worth internalizing is that a GCP project is not quite either an AWS account or an Azure subscription - it borrows ideas from both, with one important twist.

Projects are the fundamental container

Every resource in GCP - a VM, a storage bucket, a BigQuery dataset - lives inside exactly one project. Projects have a unique project ID (immutable once created), and they're the unit that most IAM permissions and quotas attach to. In that sense, a GCP project functions like an Azure resource group crossed with a subscription: it's both an organizational container and, often, an isolation boundary.

Billing accounts are separate from projects

Here's the twist: a billing account is a distinct object from a project, and one billing account can be linked to many projects. This is genuinely useful - it means a finance team can own and reconcile a single billing account while individual teams create and manage their own projects, each linked to that shared billing account, without the finance team needing access to (or being cluttered by) every project's day-to-day resources. Getting this link right matters: a project with no billing account attached can't create most billable resources at all.

IAM: permissions attach to resources, inherited down a hierarchy

GCP's resource hierarchy runs Organization → Folder → Project → individual resource, and IAM policies set higher in that hierarchy are inherited downward. A role granted at the organization level applies to every project underneath it, unless something more specific overrides it at a lower level. This is powerful for setting baseline guardrails centrally (e.g., "no one outside the security team can create public storage buckets, anywhere in the org") while still letting individual project owners manage day-to-day access within their own project.

Practical starting point

For a first real project: create one billing account, link it to a single project per meaningful workload (not one giant shared project for everything), and grant IAM roles at the project level rather than reaching for organization-wide permissions until you actually have more than one team to coordinate.