GCP Billing Explained: Accounts, Budgets, Pricing, and Cost Tracking

GCP billing in simple terms

Think of GCP like a hotel stay. The hotel is your billing account. It holds your payment card and is where the bill gets charged. The rooms are your projects. Each room has guests and a minibar, but the room itself doesn’t pay for anything. The payment goes to whoever checked in. The bill at checkout lists every room, every order, every night.

One billing account. Many rooms. Everything charged to the same card at the end of the month. That is the GCP billing model.

Here is what each piece means in plain English:

• Billing account: stores your payment method and receives charges. One billing account can pay for many projects.
• Project: a container for resources. It links to a billing account but does not itself hold money or pay for anything.
• Usage: what GCP measures: CPU seconds, GB stored, API calls made, bytes transferred.
• Invoice: the monthly summary of all charges across your billing account.
• Budget alert: an email or Pub/Sub message that fires when spending approaches a threshold you set. It does not stop charges.
• Labels: key-value tags you attach to resources to track which team or application created the cost.
• Billing export: a feature that sends raw billing data to BigQuery so you can query it with SQL.

How billing works in GCP: the full flow

Here is what happens from the moment you create a resource to the moment you receive a bill.

1. You create or use a resource. You spin up a VM, upload a file to Cloud Storage, or run a BigQuery query. The resource starts consuming something: CPU, storage, bandwidth.

2. GCP meters the usage. GCP tracks consumption per second, per GB, or per request depending on the service. This happens automatically in the background.

3. Charges attach to the linked billing account. Your project is linked to a billing account. All usage costs roll up through the project to that billing account.

4. The project reports usage; the billing account pays. Projects are containers. They do not hold money. The billing account is the payer. One billing account can pay for many projects and you see a unified view across all of them.

5. Discounts may apply automatically. If a Compute Engine VM runs for a large portion of the month, GCP applies a sustained use discount without you doing anything.

6. Budget alerts fire when you hit a threshold. If you set a budget, GCP sends a notification when spending reaches 50%, 90%, or 100% of the limit. Your services keep running.

7. An invoice is generated monthly. On the first of the following month, GCP generates an invoice and charges your payment method. If billing export to BigQuery is enabled, data appears there in near-real-time, well before the invoice arrives.

The core billing building blocks

Billing accounts

A billing account is the central object in GCP billing. It holds your payment method, receives all charges from linked projects, and is where you create budgets, view cost reports, and configure billing export. You manage billing accounts in the Cloud Console under Billing.

One billing account can pay for many projects. Each project links to exactly one billing account at a time. If a project has no linked billing account, most paid services will refuse to create resources.

Projects

A GCP project is a container for your resources and the unit of billing attribution. All VMs, storage buckets, databases, and services belong to a project. The project links to a billing account, which is how charges flow upward. Deleting a project stops charges for that project but does not affect the billing account or other linked projects.

Pricing models

GCP uses several pricing models depending on the service. Most services are pay-as-you-go: you pay for what you consume with no upfront commitment. Some services also offer capacity reservations and flat-rate models. See GCP Pricing Models for a full breakdown of on-demand, committed, and spot pricing across services.

Discounts

GCP offers sustained use discounts (applied automatically), committed use discounts (require a 1 or 3-year commitment), and Spot VM pricing (heavily discounted but interruptible). These are covered in detail below.

Budgets and alerts

A budget defines a spending threshold and sends notifications when you approach it. Budgets can be scoped to a whole billing account, a specific project, a specific service, or a label value. See Billing Budgets and Alerts for setup instructions.

Labels

Labels are key-value pairs you attach to resources. They flow through to billing exports and let you slice spending by team, environment, or application. Labels are metadata only. They do not affect access control or reduce billing costs directly.

Billing exports

Billing export sends raw usage and cost data to BigQuery automatically. Once enabled, you can query daily spend by any dimension: service, project, label, SKU, or region. This is the foundation of serious cost tracking and FinOps practices in GCP.

Billing account vs project: the key distinction

This is the most common source of confusion for beginners. Billing accounts and projects are not the same thing and serve completely different purposes.

A practical example: a company might have one billing account with three linked projects: production, staging, and dev. All three projects appear on the same monthly invoice. The billing team manages the billing account. The engineering teams manage the projects.

See the GCP resource hierarchy for how billing accounts, projects, folders, and organisations relate to each other.

Pay-as-you-go pricing in GCP

GCP charges per unit of consumption. The unit depends on the service:

• Compute Engine VMs: per second (one-minute minimum). A VM running for 15 minutes costs 15x the per-minute rate. The VM is charged whether or not it is handling any traffic.

• Cloud Storage: per GB stored per month, plus per-operation fees (reads and writes) and egress fees for data leaving GCP. See network egress costs for details.

• BigQuery: per TB of data scanned on-demand, or per slot-hour for capacity reservations. Queries that scan no data cost nothing.

• Cloud Run: per request, plus per CPU-second and memory-second while actively handling requests. Idle Cloud Run services cost nothing.

The key difference to understand: Compute Engine VMs charge continuously whether idle or busy. Cloud Run charges only when actively processing requests. For low-traffic HTTP services, Cloud Run is almost always cheaper than an equivalent VM.

Use the cloud cost estimator to model costs before committing to a service or configuration.

Discounts and cost-saving models

Think of the three discount types like this: sustained use is a loyalty discount (just keep buying, no sign-up needed), committed use is a season pass (commit upfront for bigger savings), and Spot is a standby ticket (huge discount, but you can get bumped at any time).

Sustained use discounts

If a Compute Engine VM runs for a significant portion of the billing month, GCP automatically applies a sustained use discount (SUD). No action required. The discount scales with uptime: a VM running 100% of the month on an eligible machine type (N1, N2) gets up to 30% off the on-demand price. SUDs do not apply to E2 machines or Spot VMs.

Good for workloads that run continuously. If your VM only runs a few hours a day, the discount is small. If it runs all month, it is meaningful.

Committed use discounts

Committed use discounts (CUDs) give you 20-55% off on-demand pricing in exchange for committing to a specific amount of vCPU and memory for one or three years. Commitments are per region.

CUDs make sense for stable, predictable workloads where you know the resource needs in advance. They do not make sense for experimental projects, short-lived workloads, or resources you plan to scale significantly. See Compute Engine cost optimisation for when to use CUDs vs other strategies.

Spot VMs

Spot VMs (formerly preemptible VMs) offer 60-91% discounts compared to standard on-demand prices. The tradeoff: GCP can stop them at any time when capacity is needed elsewhere. They are well-suited for batch jobs, data pipelines, and any workload that can tolerate interruption and restart. Never use a Spot VM for anything that needs to stay up continuously.

Budgets, alerts, and hard spending caps

This is where beginners most often get burned. The billing controls in GCP are notification systems, not automatic shutoffs. Understanding the distinction matters before you leave any resource running unattended.

A budget in GCP defines a spending threshold and notifies you when spending approaches it. You can set a budget on a billing account or scope it to specific projects, services, or label values. Budgets do not stop charges. They alert you.

Budgets vs quotas vs automated shutdowns

These three mechanisms are often confused because they all relate to controlling resource usage. They do completely different things:

GCP does not automatically shut off production resources when you hit a budget threshold because doing so would break live services. The system is designed for reliability first. If you want something close to a hard spending cap, the standard approach is:

1. Create a budget and connect it to a Pub/Sub topic.
2. Write a Cloud Function that listens to that topic.
3. Have the function disable billing on the project when spending crosses the limit.

This will stop all resources in the project immediately. Use it only for sandbox or experiment projects, not production. See the budgets and alerts guide for working code examples.

When billing controls matter: real-world scenarios

A student using free tier and trial credits

Your free trial gives you $300 for 90 days. Set a $5/month budget alert immediately. This catches anything that escaped the free tier: a VM left running in the wrong region, a Cloud SQL instance forgotten after a tutorial. If the alert fires, investigate before costs compound.

A small app running on Cloud Run

Cloud Run charges only when handling requests, so your cost at low traffic is close to zero. The main billing risks are misconfigured concurrency settings and unexpected traffic spikes. A budget alert at $10-20/month gives you an early warning if something goes wrong. See Cloud Run cost optimisation for tuning concurrency and memory settings.

A team with multiple projects under one billing account

Create a budget per project (not just one for the whole billing account) so you can identify which project is generating unexpected spend. Apply labels to every resource from day one so you can query spend by team in BigQuery. This setup scales well as the team grows.

A production service with predictable load

Enable billing export to BigQuery. Apply labels consistently. Set budgets at the project level with Pub/Sub routing. Review identifying expensive resources monthly. Consider committed use discounts if resource usage is stable and predictable.

A sandbox or experiment project

This is the case where automated shutdown is worth considering. If you are running short experiments, a forgotten resource is a real risk. Use the Pub/Sub + Cloud Function pattern to disable billing automatically if daily spend exceeds a small threshold. Alternatively, use a strict quota to cap the number of VMs or CPUs the project can create. And always use clean-up habits after each experiment.

Using labels to track costs

Labels are key-value pairs you attach to GCP resources. They flow through to billing exports, which means you can filter spending by team, environment, or application. The catch: they only work if you apply them consistently from the start.

Common labelling conventions:

• env=prod, env=staging, env=dev
• team=platform, team=backend, team=data
• app=payments-api, app=reporting

# Add labels to a Compute Engine VM
gcloud compute instances update my-vm \
  --zone=us-central1-a \
  --update-labels=env=prod,team=backend,app=payments-api

One critical rule: labels must be applied before billing data is exported. Historical billing data cannot be retroactively labelled. If you start tracking costs six months in and your resources have no labels, you have no way to attribute past spend. Define your label taxonomy before creating resources and enforce it through an Organisation Policy if you need consistency across teams.

Once labels are in billing export, you can query spend per label in BigQuery:

-- Total spend by team label for the current month
SELECT
  labels.value AS team,
  SUM(cost) AS total_cost
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXXX`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND DATE(usage_start_time) >= DATE_TRUNC(CURRENT_DATE(), MONTH)
GROUP BY team
ORDER BY total_cost DESC;

Billing export to BigQuery

GCP can export detailed billing data to a BigQuery dataset automatically. Once enabled, it sends a continuous stream of usage and cost records: service, SKU, project, region, labels, and cost. Configure it in the Console under Billing > Billing export. It is not enabled by default.

For a single project or small account, the billing console is usually enough. Billing export becomes essential when you need to:

• Query spend by label (for example, by team or environment)
• Identify cost trends over weeks or months
• Build custom cost dashboards or reports
• Correlate spend with deployment events or traffic data

See cost breakdown reports for practical query examples, and BigQuery pricing to understand what querying billing data itself will cost.

GCP billing vs GCP pricing

These terms are often used interchangeably but they mean different things:

• Pricing is how each GCP service charges per unit: per vCPU-hour, per GB stored, per million API calls. Pricing is defined by Google and listed on product pricing pages.

• Billing is how charges are collected, tracked, attributed, and paid. Billing includes billing accounts, invoices, budgets, exports, labels, and discounts.

In practice: pricing tells you what something costs per unit. Billing tells you what you actually owe and how to track it. See GCP Pricing Models for a full breakdown of on-demand, committed, and spot pricing structures.

How to manage billing in practice

GCP gives you several tools to manage billing depending on what you need:

Cloud Console

The Cloud Console billing section gives you a visual overview of spend by project and service, budget status, cost trends, and access to billing export setup. It is the right starting point for most people.

gcloud CLI

The gcloud CLI lets you list billing accounts, check which billing account a project uses, and link or unlink accounts programmatically. Useful for automation and scripts.

# List billing accounts you have access to
gcloud billing accounts list

# See which billing account is linked to a project
gcloud billing projects describe my-project-id

# Link a billing account to a project
gcloud billing projects link my-project-id \
  --billing-account=BILLING_ACCOUNT_ID

BigQuery exports

Once billing export is enabled, BigQuery becomes your most powerful billing analysis tool. You can query spend by any dimension, join billing data with application metrics, and build scheduled cost reports. See cost breakdown reports for practical query examples.

Cost optimisation and FinOps

For teams managing cloud spend across multiple services and projects, see building a cost optimisation strategy and FinOps principles in GCP.