Google Cloud Fundamentals: Projects, Billing Accounts and Core Services

Google Cloud fundamentals come down to two ideas that shape everything else: every resource belongs to a project, and every project that uses paid services is linked to a Cloud Billing account. Once those two relationships are clear, IAM, APIs, quotas and cost reporting on Google Cloud become much easier to reason about.

The resource hierarchy #

Google Cloud arranges resources in a tree. Policies set higher in the tree are inherited by everything below, which is how organizations apply consistent permissions and constraints.

1. Organization: the root node, tied to a Google Workspace or Cloud Identity domain (for example example.com). Individual users who sign up with a personal Google account start without one.
2. Folders: optional groupings under the organization, commonly used for departments, teams or environments.
3. Projects: the core container for resources, APIs, quotas and IAM bindings.
4. Resources: VM instances, Cloud Storage buckets, Cloud SQL instances, BigQuery datasets and so on.

Organization policies (for example, restricting which Regions resources can be created in, or disabling service account key creation) and IAM roles granted at the organization or folder level flow down to every project underneath.

Projects in detail #

A project is more than a folder. It is the unit where you enable APIs, where quotas are tracked, where IAM permissions are most often granted, and where billing is attached. Deleting a project shuts down every resource in it.

Three identifiers

• Project name: a human-friendly label you can change at any time.
• Project ID: a globally unique identifier you choose (or accept) at creation. It cannot be changed later and appears in URLs, API calls and gcloud commands, so pick something meaningful such as acme-billing-api-prod.
• Project number: assigned automatically and used internally, for example in default service account names.

APIs are enabled per project

Most Google Cloud services must be enabled in a project before you can use them. The first time you try to create a Compute Engine VM or call the Vertex AI API in a new project, you will be prompted to enable the corresponding API. Enabling an API is free; using it is not. This per-project model is also a useful control, since a project that never enables a service cannot accidentally run it.

How many projects should you create?

A common pattern is one project per application per environment: app-dev, app-staging, app-prod. This keeps permissions, quotas and costs separate. Shared services such as networking (via Shared VPC) or centralized logging often live in their own projects.

Cloud Billing accounts #

A Cloud Billing account holds the payment method and receives the charges for linked projects. It sits beside the resource hierarchy rather than inside it: a billing account can pay for projects across different folders, and even for projects in different organizations.

• One billing account can be linked to many projects.
• Each project is linked to at most one billing account at a time.
• A project with no billing account (or a disabled one) cannot use paid services, and running paid resources in it will be stopped.

Billing accounts are either self-serve (charged automatically to a card or bank account) or invoiced (monthly invoices for eligible organizations). A separate payments profile, shared across Google services, holds the legal name, address and payment methods.

Billing permissions are separate

Billing uses its own IAM roles, such as Billing Account Administrator, Billing Account User (which allows linking projects to the account) and Billing Account Viewer. Someone can be Owner of a project and still be unable to change which billing account pays for it. This separation lets finance teams control payment without needing access to infrastructure.

For exporting detailed billing data, Cloud Billing can export to BigQuery, which is the usual route for custom cost dashboards. The official Cloud Billing documentation covers account types, roles, budgets and exports.

IAM on Google Cloud #

Google Cloud IAM grants roles to principals on a resource. Principals include Google accounts, Google groups, service accounts and Workspace or Cloud Identity domains. Roles come in three kinds:

• Basic roles (Owner, Editor, Viewer) are broad and predate the rest of IAM. Google recommends avoiding them in production.
• Predefined roles are curated by Google for each service, for example roles/storage.objectViewer.
• Custom roles let you bundle exactly the permissions you need.

Workloads should authenticate as service accounts, ideally attached to the resource (a VM, a Cloud Run service) rather than using downloaded JSON keys. Granting roles to groups instead of individuals makes access reviews far simpler.

Core services at a glance #

If you already know AWS, mapping concepts helps. The equivalents below are approximate, since the products differ in detail.

Networking differs in one important way

A Google Cloud VPC network is a global resource, while its subnets are regional. One VPC can have subnets in several Regions that communicate over Google’s network without extra peering. On AWS, by contrast, a VPC is confined to one Region. Firewall rules (and newer network firewall policies) apply at the VPC level and target instances by network tags or service accounts. For the concepts behind this, see our guide to VPCs, subnets and firewalls.

Regions and zones

Resources are zonal (a VM, a persistent disk), regional (a regional Cloud SQL instance, a Cloud Run service) or multi-regional and global (some Cloud Storage buckets, global load balancers). As with other clouds, placing redundant resources in multiple zones is the baseline for availability.

Quotas #

Each project has quotas, such as the number of vCPUs per Region or API requests per minute. They protect both you and Google from runaway usage. You can view them under IAM and Admin, then Quotas, and request increases there. Some requests are approved automatically; others are reviewed and may require billing history.

A first-day setup that scales later #

1. Sign up on the official Google Cloud site, complete billing setup and turn on 2-Step Verification for the account.
2. If you have a company domain, set up Cloud Identity or Workspace so you get an organization node.
3. Create separate projects for development and production with meaningful project IDs.
4. Create a budget with alert thresholds on the billing account.
5. Grant access through groups and predefined roles rather than the Owner or Editor role.
6. Install the gcloud CLI and set a default project with gcloud config set project PROJECT_ID.

New users should also understand the difference between trial credit and always-free usage, covered in our comparison of the Google Cloud free trial and Free Tier. For habits that keep spending predictable across any provider, read cloud cost management with budgets and tagging (Google Cloud calls tags “labels” for billing purposes). The Google Cloud platform overview summarizes strengths and trade-offs, and the Google Cloud documentation and Resource Manager documentation go deeper on hierarchy and policy.

Google Cloud fundamentals: frequently asked questions #

Can I move a project to a different billing account?

Yes. A user with the right permissions on both the project and the target billing account can change the link in the Billing section of the console. Charges from that point go to the new account.

What happens if I delete a project?

The project is scheduled for deletion and its resources stop. There is a recovery window (documented as 30 days at the time of writing) during which an owner can restore it; after that it is permanently removed and the project ID cannot be reused.

Do I need an organization to use Google Cloud?

No. Individuals can create projects without one. An organization becomes important when several people or teams need central control over IAM, policies and billing.

Why is a service asking me to enable an API?

Most services are not enabled by default in a new project (a small set of common APIs is). Enabling the API makes the service available in that project only, and you can disable it later if it is no longer needed.