.png)
This article is therefore a FinOps-focused selection of June 2026 updates. The most consequential change was Google’s June 16 update to the default scope for resource-based CUDs.
Alongside that change, June brought CUD Analysis to GA and expanded CUD recommendations to additional Compute Engine resources.
CUD sharing changed by default on June 16
On June 16, 2026, Google Cloud changed the default resource-based CUD scope from Project to Billing account for applicable Cloud Billing accounts.
New billing accounts created on or after June 16 have CUD sharing enabled by default. Existing accounts are handled according to whether they had active resource-based commitments when the change took effect.
With Billing account scope, resource-based CUDs are pooled across eligible projects linked to the same Cloud Billing account. A commitment purchased in one project can therefore cover eligible resource usage in another project under that billing account.
This can improve utilization when workloads move between projects, but it also changes how FinOps teams should think about chargeback and attribution.
What happens to CUD attribution?
- Proportional attribution: CUDs are distributed across projects according to eligible usage. This is the default.
- Prioritized attribution: Organizations can specify which projects receive CUD coverage first.
Before changing or purchasing commitments, confirm:
Who owns the Cloud Billing account.
Which attribution model your organization uses.
Which projects can receive shared CUD coverage.
Whether the resulting allocation matches your internal chargeback model.
See Google Cloud CUD sharing and attribution documentation.
CUD Analysis reached general availability
For FinOps teams, the important question is how effectively existing commitments are performing. CUD Analysis can help teams examine commitment utilization, savings, and usage trends and download daily usage data for further analysis.
That makes it useful before:
- Purchasing additional commitments
- Changing CUD attribution
- Expanding coverage
- Reviewing whether existing commitments still match workload demand
CUD Recommendations Expand to GPUs and Local SSD
These recommendations identify potential commitment opportunities for eligible usage that is not already covered by a commitment.
A recommendation is not the same thing as an automatic purchase decision. Google Cloud’s current documentation says CUD recommendations use the previous 30 days of usage history and are refreshed daily.
The recommendation models can consider stable usage as well as usage that exceeds a financial break-even threshold.
Use a recommendation as an input to a broader review:
- Is the usage baseline stable?
- Is the workload expected to grow, shrink, or migrate?
- Does the commitment apply to the required resource, machine series, and region?
- Does the resource require an attached reservation?
- What happens if utilization falls after purchase?
GPU and Local SSD commitments can also have reservation requirements. Google Cloud states that commitments specifying GPUs or Local SSD generally require matching attached reservations.
Although certain local Titanium SSD configurations are exceptions. Reservations should therefore be validated before committing. See Google Cloud resource-based CUD documentation.
Related read: Azure in June 2026 Updates
Spot VM planning gained better visibility
The information includes availability, estimated uptime, historical and current preemption rates, and pricing.
For FinOps teams, this makes it easier to distinguish nominally cheaper capacity from capacity that is practical for a particular workload.
Spot VMs remain appropriate for workloads designed to tolerate interruption. A lower compute price does not compensate for an application that cannot recover cleanly when capacity is preempted. See Google Cloud Compute Engine release notes.
Flex-start VMs expanded in managed instance groups
In June, Google Cloud expanded Flex-start support in managed instance groups so that VMs can be created gradually as capacity becomes available. A MIG can initially create only part of the requested capacity and add additional Flex-start VMs later as capacity becomes available.
Flex-start VMs can run for up to seven days. This makes them relevant for short-duration workloads such as batch processing, model fine-tuning, and other jobs that can tolerate a delayed start but need a bounded execution window.
The important distinction is that Flex-start is not simply a cheaper substitute for on-demand capacity. It trades immediate capacity for a more flexible provisioning model. See Google Cloud Flex-start VM documentation.
CUDs vs. Spot vs. Flex-start: Which should FinOps teams use?
| Option | Best for | Main tradeoff |
|---|---|---|
| Resource-based CUD | Stable, predictable Compute Engine usage | Long-term financial commitment |
| Spot VM | Interruption-tolerant workloads | Capacity can be preempted |
| Flex-start VM | Short-duration workloads that can tolerate delayed capacity | Flexible start and a maximum seven-day runtime |
- Use a CUD when you have a durable usage baseline that justifies a commitment.
- Use Spot when interruption is acceptable and the application can recover.
- Use Flex-start when the workload can tolerate waiting for capacity and can complete within the seven-day maximum runtime.
GCP June 2026 FinOps Checklist
Check whether relevant Cloud Billing accounts use Project or Billing account scope.
Confirm whether proportional attribution matches your chargeback model or whether prioritized attribution is more appropriate.
Use CUD Analysis to review utilization, savings, and daily usage.
Evaluate GPU, Local SSD, and OS-license recommendations against a stable usage baseline.
For GPU and Local SSD commitments, validate regional requirements and whether an attached reservation is required.
Use the new Spot VM visibility information when evaluating interruption-tolerant workloads.
Consider Flex-start for workloads that can tolerate delayed capacity and complete within seven days.
Make sure the billing-account owner, FinOps team, and project cost owners agree on commitment allocation and chargeback implications.
How Usage.ai fits
With Flex Insured Commitments, teams can capture commitment-based savings while reducing the risk of unused capacity. Our Flex Commitments reduce cloud spend by 30–50% on average across covered workloads, while qualifying commitments include cashback protection for eligible underutilization.
For GCP teams, we analyze billing data to identify stable usage that may be suitable for commitments, help determine an appropriate commitment level, and support eligible commitment actions.
This helps teams capture more of the savings available through GCP commitments without taking on the traditional risk of unused capacity.
Frequently asked questions
What changed with GCP CUD sharing in June 2026?
On June 16, 2026, Google Cloud changed the default scope for resource-based Compute Engine CUDs to Billing account for applicable Cloud Billing accounts, with CUD sharing enabled by default.
This allows eligible resource-based CUD coverage to be shared across eligible projects linked to the same Cloud Billing account.
What is CUD Analysis?
CUD Analysis is a Google Cloud Billing capability that provides a consolidated view of resource-based and spend-based CUD performance. It helps teams evaluate commitment utilization and savings and provides access to daily usage data for further analysis.
Are GCP CUD recommendations automatic?
No. CUD recommendations identify potential commitment opportunities; they do not automatically purchase commitments.
Before acting on a recommendation, teams should validate usage stability, expected workload changes, regional and resource eligibility, any reservation requirements, and the financial break-even point.
What is the difference between Spot and Flex-start VMs?
Spot VMs are intended for workloads that can tolerate interruption because Google Cloud can preempt them when capacity is needed.
Flex-start VMs are intended for workloads that can tolerate waiting for capacity to become available and can run for up to seven days.
How much can Compute Engine CUDs save?
The maximum discount depends on the resource, machine type, region, commitment plan, term, and other configuration details.
Google Cloud's current resource-based CUD documentation lists discounts of up to 70% for eligible vCPU and memory resources on some machine types, up to 65% for some GPU resources, up to 55% for Local SSD, and up to 79% for eligible operating-system licenses.
