What Is a GCP Project? IDs, Billing, IAM, and Project Structure

What is a GCP project?

A GCP project is the fundamental container for every resource you create in Google Cloud. It controls which billing account pays for your usage, which APIs are enabled, who has access, and what quotas apply. Every VM, storage bucket, and database belongs to exactly one project. You cannot create anything in Google Cloud without one.

Simple explanation

Think of a GCP project like a workspace in an office building. Each workspace has its own budget (billing), its own set of tools unlocked for use (APIs), its own list of who is allowed in (IAM), and its own limits on how much it can consume (quotas). Nobody from one workspace automatically gets into another, and the finance team gets a separate invoice per workspace.

When you log in to the Cloud Console or run a gcloud command, you are always working inside a specific project. Everything you do (creating a VM, uploading a file, enabling a database) lands in that project and only that project.

What a GCP project is

A GCP project is the fundamental resource boundary in Google Cloud. All resources exist inside a project. When you create a Compute Engine VM, it belongs to one specific project. When you set up a Cloud SQL database, it belongs to one project. When a service account sends an API request, it is authenticated under a project.

A project controls four things that matter enormously for how GCP works:

• Billing: every charge from resources in the project goes to one linked billing account
• APIs: each service must be explicitly enabled per project before you can use it
• IAM: access permissions are scoped to the project; roles granted here apply to everything inside
• Quotas: usage limits (CPU cores, API calls, storage) are enforced per project

The project is not a virtual machine, a network, or a storage container. It is a logical boundary: a set of rules that determine what can be built, who can access it, and who pays for it. Resources live inside projects, but the project itself is the organisational structure around them.

Three identifiers, one project

Every GCP project has three ways to identify it. You will encounter all three in different situations, and confusing them is one of the most common beginner mistakes.

Project name

A human-readable label you set and can change later. It does not have to be globally unique. Use it as a display name so humans can read it in the Console. Never use it in API calls, CLI commands, or automation. It is not a stable identifier.

Example: Payments Service (Production)

Project ID

A string you choose when creating the project. It must be globally unique across all of GCP, not just within your organisation but across every GCP customer in the world. It cannot be changed after creation. GCP uses this in API calls, CLI commands, service account email addresses, Cloud Storage bucket URLs, and audit logs.

Example: acme-payments-prod

Project number

A numeric identifier assigned automatically by Google. You do not choose it and cannot change it. You will see it in IAM policy exports (e.g., serviceAccount:123456789012@cloudservices.gserviceaccount.com), audit logs, and some API responses. It identifies the same project as the project ID. You rarely need to use it directly, but you need to recognise it when you see it.

Example: 123456789012

Side by side

# A consistent project ID naming convention scales well.
# Pattern: {company}-{service}-{environment}

acme-payments-prod       # production payments service
acme-payments-staging    # staging payments service
acme-auth-prod           # production authentication service
acme-data-platform-dev   # development data platform
acme-shared-networking   # shared VPC host project

Short, lowercase, hyphen-separated, environment suffix at the end. If you open a log file and see acme-payments-prod in the project field, you know exactly what you are looking at. That clarity is worth the thirty seconds it takes to think about a naming convention before you create your first project.

How GCP projects work

A project has a simple lifecycle. Understanding the sequence helps you avoid wasted time on “why isn’t this working?” errors that are actually just missing steps.

1. Create the project: give it a name and choose your project ID
2. Link a billing account: without this, most paid services will refuse to run
3. Enable the APIs you need: each service must be turned on per project
4. Create resources inside the project: VMs, databases, storage buckets, and so on
5. Assign IAM roles: grant people and service accounts access to those resources
6. Delete the project when you are done: it enters a 30-day pending-deletion state

# Create a new project
gcloud projects create acme-payments-prod \
  --name="Payments Service (Production)"

# Link a billing account to the project
gcloud billing projects link acme-payments-prod \
  --billing-account=BILLING_ACCOUNT_ID

# Set this as the active project for subsequent commands
gcloud config set project acme-payments-prod

# Enable an API (e.g., Compute Engine)
gcloud services enable compute.googleapis.com

# List all projects your account has access to
gcloud projects list

Deleting a project does not immediately destroy it. GCP moves it into a pending-deletion state for 30 days. During that window the project is inaccessible but can be fully restored. After 30 days it is permanently gone, along with every resource inside it.

What a project scopes

Billing

Each project links to exactly one billing account. All resource charges in that project appear on that account’s invoice. One billing account can pay for many projects simultaneously, which makes it easy to see total spend across a company while still breaking costs down per project. Understanding the billing model before you start adding resources is worth the ten minutes it takes.

APIs

Most GCP services are disabled by default in a new project. Enabling an API in one project does not enable it in another. This is intentional: a project that only runs Cloud Run has no business with the Kubernetes Engine API enabled. API enablement is per-project and leaves a clear audit trail showing when each service was turned on and by whom. For the exact steps, see Enabling APIs in a Project.

IAM permissions

When you grant someone the Storage Object Viewer role on a project, they can read from every Cloud Storage bucket in that project. Permissions granted at the project level apply to everything inside it. Granting access at a higher level (a folder or organisation) reaches further down and cannot be blocked at the project level. See the Resource Hierarchy guide for how this inheritance works, and IAM in GCP for how roles and bindings work.

Quotas

Usage limits in GCP (maximum CPU cores, API calls per minute, storage capacity) are enforced per project and often per region. New projects start with conservative defaults that are fine for learning but may need increasing before a real deployment. If you need more than the default, you request an increase through the Console. See Quotas and Limits for what to check before a large deployment.

GCP project vs folder vs organisation vs billing account

These four concepts are related but distinct. Confusing them, especially the billing account and the project, causes real setup problems.

Organisation

The root node of your GCP environment, tied to a Google Workspace or Cloud Identity domain. Policies set here apply to every folder, project, and resource your company owns. This is where company-wide rules live, enforced by Organisation Policies. Without an organisation, you cannot set company-wide constraints across projects.

Folder

An optional grouping layer between the organisation and projects. Use folders to separate business units, environments, or product areas. IAM roles granted on a folder apply to every project inside it. The most common structure is two top-level folders: Production and Non-Production. Folders do not hold resources directly. They hold projects.

Project

The place where resources actually live. Every resource must belong to exactly one project. Projects have their own billing link, their own IAM policies, their own enabled APIs, and their own quotas. This is the level you will work with every day.

Billing account

A billing account is not part of the resource hierarchy. It is a separate GCP object that stores your payment method and pays for projects linked to it. One billing account can pay for many projects. Each project links to exactly one billing account at a time. The billing account does not contain resources. It only receives charges.

The full picture from top to bottom: Organisation → Folders → Projects → Resources, with a Billing Account sitting alongside, linked to one or more projects but not part of the hierarchy chain. For a full walkthrough of how IAM flows through this structure, see the Resource Hierarchy guide.

Real examples