Google Cloud CUD sharing: the 16 June 2026 default flip and the four-step chargeback fix

Summary. On 16 June 2026, Google Cloud changed the default CUD scope for most Cloud Billing accounts from Project to Billing account, which turns resource-based committed use discount sharing on. Resource-based CUDs cut Compute Engine list prices by up to 37% on a one-year commitment and up to 55% on three years, rising to 70% for memory-optimized machine types on three years, and up to 79% on SUSE Linux Enterprise Server licence commitments. Those discounts now pool across every project linked to the billing account rather than staying inside the project that bought the commitment. Google's own worked example is blunt about the effect: two commitments of 80 vCPUs each, bought in Project A, cover 160 of 200 vCPUs of usage spread across multiple projects, with the remaining 40 vCPUs billed at on-demand rates. If you run chargeback off project-level cost data, your allocation model changed underneath you and nobody sent an invoice to say so. The savings usually went up. The attribution almost certainly went wrong.

Three auto-configuration rules decided what happened to your account, and only one of them left you alone.

What actually changed on 16 June 2026

Google Cloud documents two CUD scope settings for resource-based commitments. Project keeps the discount inside the project where the commitment was purchased. Billing account pools discounts from every active resource-based commitment and applies them across all linked projects. The setting is per billing account, not per commitment.

The documented default for all new billing accounts is now Billing account, and on 16 June 2026 the default flipped from Project to Billing account for most existing accounts. Google auto-configured accounts using three rules:

The third row is the one that saves most mature FinOps teams. If you had a live resource-based commitment on 16 June 2026, Google left your configuration alone. Teams that let commitments lapse, or that had only just started buying them, are the ones who woke up inside a different allocation model.

That distinction matters because it inverts the usual pattern. The organisations most exposed here are the ones with the least commitment history, which are also the ones least likely to have a FinOps practitioner watching billing release notes.

Why this is an allocation problem, not a savings problem

Pooling raises coverage. That part is real and it is the reason Google made the change. A commitment sitting half-used in one project is money already spent, and letting it cover usage elsewhere converts waste into discount without any new purchase.

The problem is what pooling does to the numbers your finance team reads.

Before the change, a project-scoped commitment produced a clean story: the team that committed got the discount, and the team that did not commit paid on-demand rates. That asymmetry is the entire incentive structure behind commitment-based FinOps. Engineers agree to a one-year or three-year lock-in because their own budget line improves.

With sharing enabled, that link breaks by default. Google applies proportional attribution unless you configure otherwise, and the documentation describes it precisely: if project A consumes US$75 of eligible usage and project B consumes US$25, then project A is covered by up to 75% of the available CUDs and project B by up to 25%. Project B did not buy anything. Project B still gets a quarter of the discount pool.

For a platform team that centrally purchases commitments and re-bills at a blended rate, this is fine and arguably an improvement. For an organisation running true chargeback to product P&Ls, a team's cost per unit now moves when an unrelated team changes its usage. The real cost is not the discount, it is the argument you have with finance three weeks later.

Google Cloud's own 2019 launch post for the CUD Analysis report quoted an early adopter on why commitment visibility matters at all:

"With this tool, we better understand our historical usage of eligible compute resources and how that compares to our commitment levels. Our commitment utilization and coverage is automatically calculated, enabling us to know when to purchase more commitments so that we can maximize our discounts."

>

Dany Daya, Senior Program Manager, Etsy

Coverage and utilisation are still the right metrics. What changed in June 2026 is the denominator they are measured against.

How the discount actually lands

Two mechanics in Google's documentation surprise people, and both affect chargeback accuracy.

First, CUDs are credited to custom machine types before predefined machine types, and custom machine types carry a surcharge. A project running custom shapes will absorb discount ahead of a project running predefined shapes, regardless of which one bought the commitment. This is documented behaviour, not a bug, but it is invisible in a standard cost report.

Second, resource-based commitments remain regional. Pooling crosses project boundaries, not region boundaries. A commitment purchased in asia-south1 does nothing for usage in europe-west4, no matter how the scope is set. Teams that read "sharing enabled" as "my commitment now covers everything" overbuy in one region and stay uncovered in another.

Resource-based CUDs are also only available for Compute Engine, and cover vCPUs, memory, GPUs, Local SSD disks, sole-tenant nodes and operating system licences. Hardware commitments and licence commitments are purchased separately: you can hold both for the same VM, but not as a single commitment. Terms run up to six years for resource-based commitments, which is longer than the one-year and three-year options most comparison articles mention.

Proportional versus prioritized attribution

Resource-based CUDs support two attribution types. Spend-based CUDs support only proportional, and have no sharing toggle at all.

Prioritized attribution is the setting most teams should reach for before they reach for the off switch. It preserves pooled coverage while letting you name the projects that get covered first, so the team that funded the commitment still sees the benefit. Attribution preferences can be updated at any point during the commitment's lifetime, but they only apply while CUD sharing is enabled.

Check and change your CUD scope in four steps

1. Find your current scope. In the Google Cloud console, open Billing, then the Committed use discounts (CUDs) page, and choose the billing account. The Aggregated view lists every commitment across services, along with anything expiring in the next 30 days.

1. Compare against your 16 June 2026 state. If you had no active resource-based commitment that day, assume your scope was changed for you. If you had one, assume it was preserved. Confirm rather than trust the assumption.

1. Re-run one month of allocation both ways. Export Cloud Billing data to BigQuery and compare project-level cost with and without shared credits before you touch the setting. Attribution is visible in the usage cost export, so this is a query, not a guess.

1. Change the scope, or set attribution instead. Switching to Billing account takes effect at 12:00 AM US and Canadian Pacific Time the following day. Switching back to Project takes effect within a few moments. That asymmetry matters at month end: turning sharing off is close to instant, turning it on is not.

The timing gap in step four is worth planning around. If you disable sharing on the last day of a billing period to clean up a chargeback run, you get the change immediately. If you re-enable it afterwards, coverage does not resume until the following Pacific-time day, and any usage in that window bills at on-demand rates.

When to leave sharing on, and when to turn it back off

Leave it on if you buy commitments centrally, re-bill at a blended rate, run showback rather than chargeback, or have projects whose usage fluctuates enough that isolated commitments regularly sit idle. Pooling is doing exactly what it was designed to do, and disabling it costs real money.

Turn it back off if a business unit funds its own commitments from its own budget, if you contractually re-bill a client for a dedicated project, or if a regulated entity inside your organisation cannot accept subsidised infrastructure costs from a sibling entity. In those cases, the accounting requirement outranks the coverage percentage.

Between those two, use prioritized attribution. It is the option that keeps the coverage gain and restores the incentive, and it is under-used because it is one level deeper in the documentation than the sharing toggle itself.

One caveat that catches teams during reorganisations: if you move a project to a different billing account, the project keeps receiving CUDs from its own commitments under the destination account, but the source account's attribution and sharing settings stop applying. The project inherits the destination's configuration. Google's documented example is worth internalising: with sharing enabled in the source account and disabled in the destination, projects left behind in the source account stop receiving CUDs from the moved project's commitments, and in the destination the discount is limited to the moved project alone. A billing account migration is a commitment migration whether you planned it that way or not.

How Google Cloud compares to AWS and Azure

All three hyperscalers pool commitment discounts by default and all three let you scope them. The controls sit in different places and behave differently under failure.

The AWS design is the strictest: because both the purchasing and the receiving account must have sharing active, a single deactivated account silently pays on-demand rates even when the organisation is holding unused Savings Plans. The Azure design is the most granular, since scope is a property of each reservation rather than of the account, and it has its own quiet failure mode where emptying a management group flips that reservation back to Shared. Google now sits in the middle, with account-wide simplicity and the only prioritized attribution option of the three.

If you are running more than one of these, the practical lesson is that "our commitments are pooled" is not a portable statement. Each platform pools differently and each one has a documented condition under which the pooling changes without a purchase order. Our breakdown of where cloud egress fees actually land on an AI inference bill covers a similar pattern on the network side, and the agentic FinOps tooling comparison across Azure Copilot and Graviton4 looks at what the vendor tooling will and will not surface automatically.

India-specific considerations

The mechanics are identical for Indian billing accounts, and the asia-south1 (Mumbai) and asia-south2 (Delhi) regions behave like any other for regional commitment matching. Three local factors change the decision.

First, group structures. A large share of Indian technology organisations run several legal entities under one parent, sometimes with a global capability centre billing separately from a domestic product entity. Shared CUD scope across a single billing account that spans two legal entities means one entity's committed spend is discounting another entity's usage. That is a transfer-pricing conversation, not a FinOps one, and it is better to have it before the audit than during it.

Second, client re-billing. Services organisations that run dedicated Google Cloud projects per client and pass infrastructure through at cost need Project scope or prioritized attribution. A pooled discount that moves with another client's usage makes a pass-through invoice indefensible.

Third, the data protection overlay. Nothing in CUD configuration touches personal data, but the billing export you build to audit attribution often lands in a BigQuery dataset alongside other operational data, and the Digital Personal Data Protection Act 2023 obligations follow the dataset rather than the intent. Keep the billing export in its own project with its own access controls.

Teams working through the wider cost picture may find our guides on cutting AWS, Azure and GCP spend for Indian teams and FinOps for AI workloads across the three hyperscalers useful alongside this one. GPU commitments in particular behave differently, as covered in why GPU spend became the top FinOps concern.

What to do this week

Open the Committed use discounts page for every billing account you own, record the current CUD scope, and note which commitments expire in the next 30 days. Run one month of billing export both ways before changing anything. If the answer is that pooling helps your coverage but breaks your chargeback, set prioritized attribution rather than switching sharing off, and re-check the setting after any billing account migration or entity restructure. The setting is reversible in moments in one direction and takes until the next Pacific-time day in the other, so make the reversible change first and measure it.

FAQ

How eCorpIT can help

eCorpIT works with engineering and finance teams to make cloud cost data defensible, not just lower. That includes auditing CUD scope and attribution across billing accounts, rebuilding project-level allocation from BigQuery billing exports, and setting commitment strategy that survives a reorganisation or an entity split. We design cost reporting aligned with Digital Personal Data Protection Act 2023 requirements for the datasets involved. If your chargeback numbers moved in June and nobody can explain why, talk to our cloud and FinOps team.

References

1. Share resource-based CUDs across projects — Google Cloud documentation, CUD scope, the 16 June 2026 default change, attribution types and billing account migration behaviour.

1. Committed use discounts overview — Google Cloud documentation, spend-based versus resource-based commitments, attribution support and commitment terms.

1. Committed use discounts (CUDs) for Compute Engine — Google Cloud documentation, resource-based discount rates of up to 37% (one year), 55% and 70% (three years), and up to 79% on SUSE Linux Enterprise Server licence commitments.

1. Resource-based committed use discounts — Google Cloud documentation, purchasing resource-based commitments in a project context.

1. Attribution of committed use discount fees and credits — Google Cloud documentation, proportional and prioritized attribution.

1. Committed use discounts at a glance: new report shows your Compute Engine usage and commitments — Google Cloud blog, 17 June 2019, CUD Analysis report and the Etsy quotation.

1. Reserved Instances and Savings Plans discount sharing — AWS Billing documentation, turning discount sharing off per account.

1. Turning on shared reserved instances and Savings Plans discounts — AWS Billing documentation, requirement for both accounts to have sharing active.

1. Manage Azure Reservations — Microsoft Learn, reservation scope types and rescoping behaviour.

1. Buy an Azure reservation — Microsoft Learn, shared, single subscription and management group scopes.

1. Export Cloud Billing data to BigQuery — Google Cloud documentation, billing export used to audit attribution.

1. Invoicing and chargeback — FinOps Foundation Framework capability on chargeback and showback models.

Last updated: 21 July 2026.