Google Cloud Cost Optimization: CUD vs SUD — The Enterprise Strategy Guide

Google Cloud Platform offers two automatic and negotiated discount mechanisms that, when combined intelligently, can reduce compute costs by 30–57% versus on-demand rates. Yet the majority of enterprises with significant GCP footprints are either under-utilising Committed Use Discounts, incorrectly relying on Sustained Use Discounts as a substitute, or missing the commercial negotiation layer entirely. This guide covers the complete GCP discount architecture as part of our broader enterprise cloud cost optimisation framework.

Understanding the interaction between SUD, CUD, and private pricing agreements is essential for any enterprise spending $1M or more annually on Google Cloud. The discount stacking rules are non-intuitive, and the commercial negotiation opportunity at scale is substantial but requires a different playbook than AWS or Azure.

GCP Pricing Architecture: How Discounts Stack

Google Cloud's compute pricing hierarchy has several layers that interact in specific ways. Understanding this architecture is the prerequisite for any discount strategy. The baseline is on-demand (pay-as-you-go) pricing — the highest rate, charged per second with no commitment. Below that sit the two automatic and negotiated discount categories: Sustained Use Discounts (SUD), Committed Use Discounts (CUD), and private pricing agreements.

A critical rule for GCP cost optimisation: CUDs and SUDs do not stack. You receive either the CUD discount or the SUD discount on a given unit of compute — not both. This is fundamentally different from AWS, where Reserved Instances and Savings Plans apply to baseline usage while Spot pricing is available for flexible workloads. On GCP, the choice between CUD and SUD is structural and must be made deliberately at the portfolio level.

On top of CUDs and SUDs, enterprises with large enough spend can negotiate private pricing agreements — negotiated rate cards that provide discounts across GCP services above and beyond the published discount tiers. Our guide on negotiating cloud EDP and MACC agreements covers the multi-cloud dimension; this article focuses specifically on GCP's mechanics.

GCP Compute Pricing Tiers at a Glance

Discount Type	Max Discount vs On-Demand	Commitment Required	Flexibility
On-Demand	0%	None	Full (per second)
Sustained Use Discount (SUD)	Up to 30%	None (automatic)	Full (monthly)
Resource-based CUD (1-year)	Up to 37%	1-year resource commitment	Low (instance-specific)
Resource-based CUD (3-year)	Up to 55%	3-year resource commitment	Very low
Spend-based CUD (1-year)	Up to 28%	1-year spend commitment ($/hour)	Medium (cross-resource)
Spend-based CUD (3-year)	Up to 46%	3-year spend commitment	Medium
Private Pricing Agreement	5–25% additional	Negotiated commitment	Varies

Sustained Use Discounts (SUD) Explained

Sustained Use Discounts are Google Cloud's automatic, no-commitment discount that applies to certain Compute Engine workloads when they run for a significant portion of the billing month. SUDs require no action from the enterprise — they are applied automatically to eligible compute resources as monthly usage accumulates. This makes them particularly valuable for workloads that are consistent but where the enterprise has not yet formalised a commitment strategy.

How SUD Calculation Works

GCP calculates SUDs based on the percentage of the month that a VM runs. For Compute Engine N1 and N2 machine types (General Purpose), the SUD applies as follows: for usage in the first 25% of the month (roughly the first 180 hours), the full on-demand rate applies. As usage increases through 25–50%, 50–75%, and 75–100% of the month, incremental discounts accumulate, ultimately reaching approximately 20–30% discount for workloads that run the full month.

The SUD is calculated across all VMs within a project and region combination — it is not per-instance. GCP aggregates compute across instances and applies the incremental discounts to the combined usage. This means fragmented workloads across multiple projects may realise lower SUDs than consolidated workloads within fewer projects.

SUD Eligibility — What Qualifies

Not all GCP compute workloads qualify for SUDs. Predefined machine types (N1, N2, N2D, C2) are generally eligible. However, E2 machine types, Spot (preemptible) VMs, and custom machine types may have different SUD treatments. App Engine Flexible, Cloud Run, and GKE Autopilot nodes have their own pricing structures that may or may not include SUD equivalents. Before relying on SUD for cost planning, verify eligibility for your specific VM families in the current GCP pricing documentation.

The SUD Limitation: Maximum 30% Discount

The most important strategic limitation of SUD is its ceiling: the maximum SUD discount achievable through full-month utilisation is approximately 30% off on-demand pricing for eligible workloads. For workloads that run reliably 24/7 and where the enterprise is comfortable with a multi-year commitment, 3-year resource-based CUDs can achieve 55% discounts — nearly double the SUD maximum. For predictable baseline workloads, CUDs will almost always deliver superior economics. SUD is best treated as a safety net for variable or unpredictable workloads, not as the primary cost optimisation mechanism for stable GCP infrastructure.

Committed Use Discounts (CUD) — Resource vs Spend-Based

Committed Use Discounts are GCP's mechanism for providing deeper price reductions in exchange for a commitment to minimum usage over 1 or 3 years. CUDs come in two forms — resource-based and spend-based — with meaningfully different characteristics that determine which is appropriate for different workload profiles.

Resource-Based CUDs: Maximum Discount, Minimum Flexibility

Resource-based CUDs commit to a specific vCPU and memory configuration in a specific region for the commitment term. In exchange, GCP provides discounts of up to 37% (1-year) or 55% (3-year) for N1 and N2 machine families. The resource-based CUD is the highest-discount option available through the self-service pricing tier, but it carries meaningful rigidity: changing instance types, migrating regions, or reducing compute requirements during the commitment term does not reduce the commitment obligation.

Resource-based CUDs are most appropriate for workloads with a stable, predictable compute footprint: always-on production databases, application servers with consistent traffic patterns, data processing pipelines with reliable throughput requirements. For these workloads, the discount depth justifies the commitment inflexibility.

Spend-Based CUDs: Flexibility at Lower Discount Depth

Spend-based CUDs commit to a minimum per-hour spend level (in USD) on eligible GCP services in a region, rather than committing to a specific resource configuration. The discount is lower — up to 28% (1-year) or 46% (3-year) — but the flexibility is substantially higher. Spend-based CUDs can apply across different machine types and families as long as the spend threshold is met, making them more appropriate for heterogeneous environments or workloads where the instance configuration may evolve.

Spend-based CUDs are also available for services beyond Compute Engine, including Cloud SQL and Cloud Spanner, making them valuable for enterprises with database-heavy GCP workloads. This is a meaningful differentiator from resource-based CUDs, which are primarily Compute Engine instruments.

CUD Sharing Across Projects

An often-misunderstood feature of GCP CUDs is their sharing behaviour. By default, CUDs purchased in one project apply only to that project. However, if consolidated billing is configured at the organisation level, resource-based CUDs can be shared across all projects in the billing account — a capability that can dramatically improve CUD utilisation for enterprises with workloads distributed across multiple projects. Ensuring CUD sharing is enabled is one of the first configuration checks we recommend when auditing a GCP cost environment.

CUD vs SUD: Which to Use and When

The CUD vs SUD decision is not binary — in practice, a well-structured GCP estate will use both in complementary roles. The strategic framework for allocating between the two mechanisms follows a tiered commitment logic: CUDs cover the predictable baseline, SUDs protect the variable layer above it, and Spot (preemptible) VMs handle fault-tolerant, interruptible workloads.

The Three-Layer GCP Discount Model

Layer one is the stable baseline: workloads that run 24/7 with consistent resource requirements. For these workloads, 3-year resource-based CUDs provide the maximum available discount (up to 55%) and the TCO advantage clearly outweighs the commitment risk given workload stability. The target CUD utilisation for this layer should exceed 85%.

Layer two is the predictable but variable layer: workloads that run consistently but with some flexibility in instance sizing or configuration. Spend-based CUDs are the appropriate instrument here — they provide meaningful discounts (up to 46% for 3-year) while accommodating workload evolution. Targeting 70–80% of this layer with spend-based CUDs, with SUD covering the remainder, is a reasonable heuristic.

Layer three is the truly variable layer: bursty workloads, development and test environments, batch processing, and stateless applications that can tolerate interruption. SUDs provide automatic discounts for any consistent-enough usage in this layer, while Spot VMs offer 60–91% discounts for fully interruptible workloads.

Workload Type	Recommended Discount Mechanism	Target Discount
Always-on production (stable config)	3-year resource CUD	Up to 55%
Always-on production (variable config)	3-year spend CUD	Up to 46%
Business-hours workloads	1-year spend CUD + SUD	25–37%
Variable / seasonal workloads	SUD (automatic)	Up to 30%
Fault-tolerant batch / dev-test	Spot VMs	60–91%

Building a GCP Discount Portfolio Strategy

Constructing an optimal GCP discount portfolio requires a structured analysis of your current workload landscape. The process follows five steps that we apply in our GCP cost optimisation engagements: inventory, classification, baseline determination, commitment sizing, and portfolio management.

Step 1: Workload Inventory and Utilisation Baseline

Pull 90-day compute utilisation data across all GCP projects using Cloud Monitoring or a third-party FinOps tool. For each workload group, establish average and peak resource consumption (vCPU-hours, memory-GB-hours), monthly uptime percentage, and workload stability score. Workloads running above 85% monthly uptime with consistent resource profiles are primary CUD candidates.

Step 2: Classify Workloads into Commitment Tiers

Map each workload group to the three-layer model described above. The output is a CUD sizing target: the vCPU and memory quantities that should be covered by resource-based CUDs, the $/hour spend target for spend-based CUDs, and the remaining variable compute that will rely on SUD or Spot pricing. This classification should be refreshed every six months as the workload landscape evolves.

Step 3: Model the Commitment Term Trade-off

For workloads that qualify for CUD coverage, model the NPV trade-off between 1-year and 3-year commitments. The additional discount from 3-year versus 1-year CUDs is typically 18–22 percentage points. For a $5M baseline GCP estate covered by CUDs, that gap represents $900K–$1.1M in annual savings. The risk trade-off — primarily the risk of overcommitting if GCP usage declines — should be assessed against the organisation's cloud growth trajectory and the agility value of shorter commitments.

Step 4: Purchase CUDs Strategically

Once the commitment sizing is determined, CUDs should be purchased through the GCP Console or programmatically via the Commitment API. Key operational considerations: purchase CUDs at the billing account level (not project level) and enable CUD sharing to maximise utilisation across the portfolio. Stagger CUD expiry dates where possible to avoid cliff-edge renewal pressure that weakens negotiating position.

GCP Private Pricing and Strategic Agreements

For enterprises with annual GCP spend above approximately $1M, Google Cloud offers private pricing agreements — negotiated contracts that provide discounts beyond the published CUD tiers. These agreements are not publicly documented and require engagement with GCP's enterprise account team, but they are widely available to enterprises that approach the negotiation proactively.

What Private Pricing Covers

GCP private pricing agreements typically include a negotiated percentage discount against list prices for specific services (Compute Engine, BigQuery, Cloud Storage, Vertex AI), a committed annual spend level, and potentially non-standard terms such as payment flexibility, credits for proof-of-concept work, or support package inclusions. The effective additional discount from private pricing, above the CUD tier, is typically 5–20% depending on deal size and competitive context.

Negotiation Leverage with GCP

Google Cloud is the third-largest hyperscaler by market share and is actively trying to win enterprise share from AWS and Azure. This creates meaningful negotiating leverage that is absent or weaker in negotiations with AWS (the market leader) or Microsoft (with bundled licensing relationships). Enterprises that can credibly demonstrate an AWS or Azure migration alternative — or that are considering a multi-cloud architectural split — are in a strong position to extract superior commercial terms from GCP.

The IT Negotiations advisory team has represented enterprises in GCP private pricing negotiations and has consistently found that the gap between first-offer GCP pricing and achievable pricing — when the negotiation is conducted with benchmark data and competitive leverage — is 10–25% of annual spend. For a $5M GCP estate, that is $500K–$1.25M in annual recoverable value.

For the broader multi-cloud negotiation context, our guide on multi-cloud cost optimisation strategy covers how to use hyperscaler competition to your advantage.

Common Mistakes Enterprises Make with GCP Discounts

After reviewing GCP cost environments across dozens of enterprise engagements, we consistently encounter the same mistakes. Correcting them typically delivers 15–30% additional savings with no architectural changes required.

Mistake 1: Treating SUD as a Strategy Rather Than a Safety Net

SUD is an automatic discount — valuable but capped at 30% and not a substitute for a deliberate commitment strategy. Enterprises that are satisfied with their SUD levels and have not built a CUD portfolio are systematically overpaying for their stable workloads. The analysis is straightforward: pull workloads running above 85% monthly uptime, size a CUD portfolio to cover them, and model the NPV of the commitment. In most cases the payback period is under six months.

Mistake 2: Not Enabling CUD Sharing

CUD sharing across billing accounts is disabled by default. Enterprises that purchase CUDs project-by-project, without enabling organisation-level sharing, frequently end up with a fragmented CUD portfolio where some projects are over-committed (low utilisation) and others remain on on-demand pricing. Enabling CUD sharing is a configuration change that takes minutes and can immediately improve CUD utilisation across the portfolio.

Mistake 3: Buying Resource CUDs for Variable Workloads

Resource-based CUDs commit to a specific vCPU and memory configuration. Enterprises that buy resource CUDs for workloads that are growing, changing instance types, or migrating regions frequently end up with stranded commitments — commitments they are paying for but not fully utilising. For any workload with configuration uncertainty, spend-based CUDs provide superior flexibility at a modestly lower discount rate.

Mistake 4: Not Negotiating Private Pricing

A significant proportion of enterprises with $1M+ annual GCP spend have never engaged GCP's account team in a structured private pricing negotiation. GCP's published pricing is not the floor — it is the starting point. Enterprises that accept published pricing without negotiation are paying a premium that GCP's own commercial team would readily discount if asked with leverage and benchmark data.

Next Steps for GCP Cost Optimisation

Google Cloud cost optimisation is a multi-layered exercise that spans technical configuration (CUD portfolio, SUD maximisation, Spot VM adoption), commercial negotiation (private pricing agreements), and ongoing governance (utilisation monitoring, commitment rebalancing). The combination of all three layers is where the largest savings are achieved.

For the broader cloud cost optimisation context, return to our enterprise cloud cost optimisation pillar guide. For the specific FinOps framework and organisational design required to sustain these savings, see our article on building a cloud FinOps culture in enterprises. For GCP's interaction with AWS and Azure in a multi-cloud environment, see our guide on multi-cloud cost optimisation strategy.

IT Negotiations provides independent, buyer-side advisory for enterprises seeking to reduce GCP costs — both through commitment portfolio optimisation and through commercial negotiation with Google Cloud's enterprise sales organisation. Our advisors bring benchmark data from comparable enterprise GCP estates and have no commercial relationship with Google Cloud. If you would like a no-obligation assessment of your GCP cost position, contact us here.