Google Cloud’s Committed Use Discounts (CUDs) are actually a lot like a gym membership: you commit to a certain level of usage over a period, and you get a significant discount on the standard rates. The surprising part? You don’t have to commit to specific machines or specific regions to get the discount, making them far more flexible than you might initially assume.
Let’s see this in action. Imagine you have a fleet of n2-standard-4 instances running in us-central1. You’ve been running them consistently for months, and you’re confident this usage will continue.
Here’s a look at your current on-demand costs for these instances:
gcloud compute instances list --filter="zone:( us-central1-a us-central1-b us-central1-c us-central1-d )" --format="table(name, machineType, status, cpuPlatform)"
Let’s say you have 10 such instances, and the on-demand price for an n2-standard-4 in us-central1 is approximately $0.135 per vCPU per hour and $0.054 per GB of RAM per hour. Each n2-standard-4 has 4 vCPUs and 16 GB of RAM.
- vCPU cost per instance per hour: 4 vCPUs * $0.135/vCPU/hr = $0.54/hr
- RAM cost per instance per hour: 16 GB * $0.054/GB/hr = $0.864/hr
- Total on-demand cost per instance per hour: $0.54 + $0.864 = $1.404/hr
- Total on-demand cost for 10 instances per hour: 10 * $1.404/hr = $14.04/hr
If these instances run 24/7 for a month (approx. 730 hours):
- Monthly on-demand cost: $14.04/hr * 730 hrs = $10,249.20
Now, let’s look at a Committed Use Discount. You can purchase a CUD for compute resources. For n2-standard-4 in us-central1, a 1-year commitment might offer a discount of around 40-60% off the on-demand price. Let’s assume a 50% discount for this example.
When you purchase a CUD, you’re committing to a spend rather than specific resources. You’d go to the GCP console, navigate to "Billing" -> "Commitments" -> "Compute Engine". You’d select "Commit to spend" and choose your region (us-central1) and commitment term (1 year).
You’d then specify the amount of spend you want to commit to per hour. To cover your 10 n2-standard-4 instances, you’d calculate your committed spend:
- On-demand hourly spend: $14.04/hr
- Discounted hourly spend (50%): $14.04 * 0.50 = $7.02/hr
- Commitment amount: You’d commit to spending $7.02 per hour for compute resources in
us-central1for 1 year.
Your new estimated monthly cost with the CUD would be:
- Monthly committed spend: $7.02/hr * 730 hrs = $5,124.60
This is a significant saving, nearly $5,000 per month in this example!
The magic of CUDs is that Google Cloud automatically applies the discount to any eligible Compute Engine resource usage within the specified region. If you have other N2 instances, or even E2 instances, running in us-central1, the discount will be applied to them first before any remaining discount can be used for other eligible instance families in that region. If your usage drops below your committed spend for a period, you still pay the committed amount. If your usage exceeds your committed spend, you pay the on-demand rate for the excess.
The key levers you control are:
- Commitment Term: 1-year or 3-year. Longer terms offer deeper discounts.
- Commitment Type:
- Resource-based: Commit to a specific number of vCPUs, RAM, GPUs, etc., for a particular machine family and region. This is less flexible.
- Spend-based: Commit to a dollar amount of spend per hour for a region. This is the most flexible and generally recommended for dynamic workloads.
- Region: CUDs are regional. A CUD in
us-central1only applies to resources inus-central1. - Machine Family (for resource-based): You can commit to
n2,e2,n1, etc.
The system in action is that Google Cloud’s billing system continuously monitors your Compute Engine usage within a region. When you have an active CUD for that region, it calculates your total eligible spend. If this spend is less than or equal to your committed spend, the discount is applied, and you pay the committed amount. If your eligible spend exceeds your committed spend, the discount is applied up to the committed amount, and the excess usage is billed at the on-demand rate.
A common misconception is that a CUD locks you into specific instance types. While resource-based CUDs can do this, the more flexible spend-based CUDs allow you to commit to a dollar amount and then apply that discount across a wide range of eligible Compute Engine resources within that region, including different machine types and even some other services like GKE nodes or Cloud Run. You don’t need to predict exactly which n2-standard-4 instances will be running; you just need to predict your total Compute Engine spend in that region.
The next step after optimizing Compute Engine costs with CUDs is often exploring Sustained Use Discounts, which automatically apply for workloads that run for a significant portion of the month but don’t warrant a long-term commitment.