Home/Library/Labels and Folders: Cost Allocation
Governance · Google Cloud · Updated May 2026

Labels and Folders: Cost Allocation on Google Cloud

Cost allocation on Google Cloud comes down to two mechanisms: labels that tag individual resources, and the folder and project hierarchy that groups them. Get both right and every dollar has an owner, showback is automatic, and optimization decisions become obvious. Get them wrong and the bill is a wall of untagged spend nobody will claim.

Cost allocation on Google Cloud is the foundation everything else stands on, because you cannot cut, charge back, or hold anyone accountable for spend you cannot attribute. Two tools do the work. Labels are key-value pairs you attach to resources to mark which team, environment, application, and cost center owns them. Folders and projects form the resource hierarchy that organizes the estate into ownership boundaries. Used together, they turn an opaque bill into a clear map of who spends what. This is the See step of our method, and it has to come first.

This article is part of our Google Cloud cluster. For where allocation sits among the wider levers, start with our complete guide to Google Cloud cost optimization, the pillar this piece links up to.

Labels vs folders vs projects: what each does

These three layers answer different questions, and you need all three.

MechanismGranularityBest for
FoldersDepartment or business unitOrg structure, policy inheritance, broad allocation
ProjectsApplication or team boundaryThe natural unit of ownership and billing rollup
LabelsIndividual resourceFine-grained allocation: env, app, cost center

Projects are the strongest allocation boundary on Google Cloud, because billing data rolls up cleanly by project and access control follows the same lines. Folders group projects by department for policy and reporting. Labels add the dimensions projects cannot capture, like splitting one project's spend across environments or features.

A labeling standard that survives real teams

The labels that matter are the ones applied consistently, so keep the standard small and enforce it. We typically require four: team or owner, environment (prod, staging, dev), application or service, and cost-center. Use lowercase keys and values, a controlled vocabulary so the same team is not spelled three ways, and a documented standard everyone references. Apply labels through infrastructure as code so they are set at creation and cannot drift, rather than hoping engineers add them by hand. Labels propagate into the billing export, so once they are consistent you can break down spend by any of them.

Design the hierarchy for allocation

Organize folders and projects to mirror how you want to allocate cost, not how the org chart happened to look five years ago. A common pattern is a folder per department, projects per application or team within it, and separate projects for production and non-production so the two never blur. This structure makes allocation a rollup rather than a reconciliation, and it lets you apply budgets and policies at the right level. For the budgets that ride on this hierarchy, see how to set budgets and alerts in Google Cloud.

Want allocation that actually sticks?

Our Google Cloud cost audit builds the labeling standard, enforces it in code, structures the project hierarchy for clean allocation, and stands up showback so every dollar has an owner. On the performance model you pay only from realized savings. No savings, no fee.

Book a GCP cost audit →

From allocation to showback

Once labels and hierarchy are consistent, the billing data lets you produce showback: a per-team or per-project view of spend that you circulate so each owner sees their own cost. Showback changes behavior on its own, because engineers who can see their bill start managing it. Build the reports from the BigQuery billing export, grouped by your labels and projects; see Cloud Billing reports and BigQuery billing export for the data pipeline. The combination of clean allocation plus visible showback is what turns cost optimization from a central chore into a distributed habit.

Handling the unlabeled and the shared

Two categories always remain. Unlabeled spend is the resources that slipped through; track the unlabeled percentage as a metric and drive it down, because it is the spend nobody owns. Shared spend, like a central network, logging, or a shared cluster, cannot be cleanly attributed to one team. Allocate it with a documented and agreed key, such as by usage or headcount, rather than leaving it unassigned. For the cluster-specific version of this problem, see persistent disk and storage cleanup on GCP for the kind of orphaned resources that often sit unlabeled.

Label behavior, the resource hierarchy and billing export fields above reflect Google Cloud as of May 2026. Verify current behavior in Google Cloud documentation before acting, as the platform changes.

Go deeper · free guide

The Google Cloud Cost Optimization Field Guide includes our labeling standard template and the showback report queries we deploy. It is the downloadable companion to this article.

The short version

Allocate cost with three layers: folders for departments, projects as the primary ownership boundary, and labels for fine-grained dimensions like environment and cost center. Keep the labeling standard small, enforce it in code, and design the hierarchy to mirror how you allocate. Push the data into showback so owners see their own spend, track unlabeled percentage as a metric, and split shared cost on an agreed key. When you want allocation built and made to stick across the estate, that is exactly what our Google Cloud cost optimization service delivers.

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only