Cloud cost allocation by team: tagging and chargeback for engineering and finance teams on AWS and Google Cloud

Cloud cost allocation by team answers one question: who spent this? This post is for engineering and finance teams on AWS and Google Cloud who need each team to see, and eventually pay for, its own share of the bill. It covers tagging cloud resources by team, labels on Google Cloud, a tagging policy small enough to survive, how to split shared costs, and when showback should become chargeback.

Start with accounts and projects, then tags

Every AWS cost lands in exactly one account, and most Google Cloud costs land in one project. If a team owns an account or a project outright, its cost allocation is done: no tags needed, nothing left untagged. That’s why many companies give each team its own production account or project before they write a tagging policy.

Tags matter where accounts are shared: one production account running five teams’ services, a platform account, a data project everyone writes to. There, the resource’s tag is the only thing that says who it belongs to.

On AWS, you can also tag the accounts themselves. Account tags set in AWS Organizations can be activated for cost allocation, and every cost in a tagged account inherits them, including credits, refunds and charges that can’t be tagged at the resource level (AWS docs). On Google Cloud, labels on a project reach the billing export as project labels, so a labeled project covers every resource in it.

A minimal tagging policy

Tagging policies fail when they ask for too much. Three keys cover cost allocation:

Four rules keep it working:

• Lowercase, with dashes. Google Cloud labels allow only lowercase letters, numbers, underscores and dashes, so the same convention works on both clouds, and Payments never splits from payments.
• A fixed list of team values, matching your org chart, kept in one place with one owner. Free text is how you end up with payments, payment and pay-team.
• Tag at creation, in code. Set the keys as defaults in your infrastructure as code so every resource gets them without anyone remembering.
• Fix the source, not the report. When a tag is wrong, change it on the resource. A mapping in a spreadsheet hides the problem until next month.

Tagging cloud resources by team on AWS

A tag on a resource doesn’t reach your bill on its own. In the management account (or a standalone account), you activate each tag key as a cost allocation tag in the Billing and Cost Management console. A new key can take up to 24 hours to appear there, and up to 24 more to activate (AWS docs). From then on, Cost Explorer, Budgets and the Cost and Usage Report can group cost by it.

Activation isn’t retroactive by default. You can request a backfill of up to twelve months, and it fills in tag values only for the months the tag was actually on the resource (AWS docs).

To list user-defined tag keys that aren’t active yet, which only reads:

aws ce list-cost-allocation-tags --status Inactive --type UserDefined \
  --query 'CostAllocationTags[].[TagKey, LastUsedDate]' --output table

To activate them, which changes your billing settings (up to 20 keys per call):

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=team,Status=Active TagKey=env,Status=Active

Two AWS Organizations features keep tags consistent. Tag policies standardize keys, capitalization and allowed values, and can block noncompliant tagging on resource types you choose. They don’t catch missing tags, though: untagged resources aren’t evaluated for compliance (AWS docs). To require a tag when something is created, a service control policy can deny actions like ec2:RunInstances when the request carries no team tag (AWS docs). Test it on one account first: it blocks launches from any tool that doesn’t send tags.

Labels on Google Cloud

Google Cloud’s equivalent is the label: a key and value, up to 64 per resource, lowercase letters, numbers, underscores and dashes, with keys starting with a letter (Google Cloud docs). Labels need no activation. They flow into the Cloud Billing export to BigQuery, as labels for the resource and project.labels for its project.

Like AWS tags, labels aren’t retroactive: cost carries a label only from the day it was applied (Google Cloud docs). Google Cloud also has tags, which exist for IAM and organization policy conditions. They appear in the export too, but labels remain the usual tool for cost.

To list VMs with no team label, which only reads:

gcloud compute instances list --filter="-labels.team:*" \
  --format="table(name, zone.basename(), labels)"

To label one, which changes it:

gcloud compute instances add-labels checkout-api-1 --zone=us-central1-a --labels=team=payments

With the billing export on, cost by team for a month is one query:

SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = 'team') AS team,
  ROUND(SUM(cost), 2) AS cost
FROM `my-project.billing.gcp_billing_export_v1_XXXXXX_XXXXXX_XXXXXX`
WHERE invoice.month = '202609'
GROUP BY team
ORDER BY cost DESC

The row where team is null is your unlabeled spend.

Fix untagged and inconsistent tags

Measure before you fix. On AWS, group a month’s cost by the tag. Untagged spend comes back under the bare key, team$, with no value after it:

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=TAG,Key=team \
  --query 'ResultsByTime[].Groups[].[Keys[0], Metrics.UnblendedCost.Amount]' \
  --output table

Each Cost Explorer API call costs $0.01 as of October 2026 (pricing).

Then work the list from the top, by cost:

• Variants of the same team (Payments, payment, pay-team): fix them in code, and until then, merge them in reporting so the numbers are usable today.
• Untagged resources in an account one team mostly owns: give that account’s untagged spend to that team by default. It’s closer to the truth than “unallocated”.
• Costs that can’t carry a tag, such as support, credits and refunds: use account tags on AWS, or treat them as shared costs.

Don’t aim for 100%. Allocating the biggest untagged items first gets most of the bill attributed quickly, and the long tail of small resources rarely changes anyone’s decisions.

Split shared costs: proportional or even

Some spend belongs to everyone: a shared Kubernetes cluster, a platform account, networking, observability. Leaving it unallocated makes every team look cheaper than it is. There are two common ways to split it.

Say a shared platform account costs $6,000 a month and three teams have direct costs of $12,000, $6,000 and $2,000:

Proportional splits by each team’s share of direct cost. It’s usually fairer, because bigger workloads tend to lean harder on shared platforms. Even is simpler to explain and fine for small, fixed costs like a shared VPN.

On AWS, Cost Categories can apply split charge rules, proportional, fixed or even. The split results appear only on the cost category’s details page, not in Cost Explorer or the Cost and Usage Report (AWS docs). On Google Cloud, you split in your own BigQuery queries or reports.

Showback vs chargeback cloud costs

Showback shows each team its costs. No money moves; the point is that every team sees its number every month. Chargeback books those costs to each team’s budget in your accounting. The FinOps Foundation puts the difference as the formality of sending expenses to official accounting budgets (FinOps Foundation).

Start with showback. Run it for a few months, until three things are true: most of the bill is allocated, finance and engineering have agreed how shared costs split, and each month’s team totals add up to the invoice. Then chargeback is a bookkeeping change, not an argument. If you buy Savings Plans or Reserved Instances on AWS, report amortized cost, so upfront payments spread across the months they cover instead of landing on one team in the month of purchase.

Allocation also makes budgets useful: once each team has a number, each team can have a cap and an alert. Cloud budget alerts covers how to set those up on both clouds.

How Omni FinOps does it

Omni FinOps reads your AWS and Google Cloud costs and inventory through read-only access, tags and labels included. Its Allocations page, on the Growth plan and up, is tag-based showback: pick a key such as team and see cost per value. Normalize rules merge variants like Payments and payments. Assign rules give an account’s untagged resources a team. Shared accounts split across teams proportionally or evenly. Untagged resources are listed by cost, biggest first, and spend that isn’t tied to any resource is shown on its own, so the total never exceeds the bill. Budgets can be scoped to an allocation, so each team gets its own cap and alert. See how it connects on AWS and Google Cloud.