More articles

Want to bridge the cloud cost transparency gap between Management and Engineering?

Get in touch with us, we're here to help.
Zoltán Guth

CTO

Balázs Molnár

CEO

Almost Everything About Google Cloud’s Committed Use Discount

Rabbit Team

6 min read

Introduction

As the landscape of cloud services has evolved, Google Cloud Platform (GCP) has expanded its pricing strategies beyond just the traditional pay-as-you-go model. GCP offers Committed Use Discounts (CUDs), a scheme that encourages customers to commit to certain levels of resource usage or spending over time in exchange for significant discounts on these services. These discounts can be substantial, often reducing the costs up to 57% compared to on-demand pricing. This post focuses on these publicly available discount options provided by GCP, highlighting how commitment to resource usage can lead to reduced cloud expenditure.

The reason for commitment based discounts are available is that Google Cloud, like other Cloud Service Providers, constructs data centers and provides services, charging customers based on the time and usage of these resources. Google faces the operational challenge of balancing server availability — having too many or too few at any time. This risk factor contributes to the pricing structure of their on-demand cloud services, often reflected in a risk premium included in these rates.

In GCP there are two types of commitments available: resource based or spend based.

  • In spend-based or flexible commitment models, customers receive a discount by agreeing to a predetermined expenditure on specific GCP products. This arrangement essentially involves committing a certain amount to the use of these offerings in exchange for reduced rates.
  • Resource-based commitments offer discounts in exchange for a commitment to a specified level of Compute Engine usage.

Not all of these commitments are available for all services in GCP. For Compute Engine both types of discounts are available but for

  • AlloyDB for PostgreSQL
  • Cloud Bigtable
  • Cloud Run
  • Cloud Spanner
  • Cloud SQL
  • Google Cloud VMware Engine
  • Google Kubernetes Engine
  • Memorystore

only spend based commitment is available.

Because both types of discounts are available for Compute Engine there is a priority order for these commitments if a customer chooses to apply both:

  1. Resource based is going to be applied
  2. Spend based is going to be applied

In general we can say that resource based commitments are more strict, because you will be restricted to a specific machine type and a specific location but with spend based none of them are restricted. In exchange for that you can get a higher discount for resource-based commitments. The best practice is that if you are confident that you don’t want to change the machine type and the location in the next 1 or 3 years, then use resource-based commitments, if you know that you might change it in the future then commit with spend-based commitment. The good news is that you can mix it as well, you cover only the 50% of your resources with resource-based commitment and use spend-based for the rest.

Both of the commitment types are available for 1 or 3 years. Due to the risk factored in as discussed above the discounts are different for 1 and for 3 years. The discount is bigger if the commitment is longer.

CUD Calculation

There are at least two strategies to calculate CUD with:

  1. Maximize saving
  2. Cover the minimum usage

For the sake of example let’s see a generated data based chart of a Compute Engine usage with weekday highs and weekend lows.

Maximize saving

Maximize CUD strategy

Screenshot is from followrabbit.ai’s CUD planner feature

As you can see the suggested commitment is way overcommitting on the weekends but on the weekdays you are going to win that much it covers the weekends losses and even more.

Cover Minimum Stable Usage

Cover minimum stable usage strategy

Screenshot is from followrabbit.ai’s CUD planner feature

Here the suggested commitment is really close to the x axis. It covers the usage that is always on both on weekends and weekdays too. This approach would be on the safe side of the commitments since this usage is always on and predictable.

Additional Considerations

The two examples are based on resource based commitments but as we have already written combining the two types of commitments can be a great approach. In this example the customer can go with the minimum stable usage strategy for the resource based commitments and then go with the maximized saving strategy for the spend based approach for the rest. So for example have 5-10 resource based commitments with minimum stable usage strategy and then on the top of them have a spend based commitment with maximize saving strategy for the rest of the usage.

Spend based commitment recommendation

Please bear in mind that this approach is specifically applicable to Compute Engine. For other services, only a spend-based commitment is available.

There are additional factors to consider when determining CUD. Existing Commitment: If there’s a commitment already in place, you have three options:

  1. Calculate the CUD without considering the current commitment and create a new one once the current one expires. This one is useful if the last commitment end date is close.
  2. Calculate the CUD while taking into account the ongoing commitment and create an additional commitment.
  3. Merge existing commitment with a new one.

The third option requires special attention, as Google doesn’t permit the cancellation or reduction of commitments to a smaller amount. However, it does allow merging to larger or longer commitments. The way it works is that a new commitment needs to be made and then merge the old one with the new one. In that case a new commitment is going to be created with the latter end date from the two. Follow this link for more details.

Regarding the second option, a strategic approach involves making small monthly or quarterly commitments. This enables you to make decisions on whether to increase or decrease the commitment each month or quarter over the next year.

Changing Machine Type, Series or Family

Before making a commitment it might be worth checking if it is time to move the workload to another type of CPU. In that case it is recommended to run the workload on the targeted CPU to see how the characteristics of the usage works out due to differences for example in the concurrency handling of the CPU.

Worth checking different machine families as well: AMD vs Intel because the price difference before commitment can be up to 12% save if choosing AMD.

More articles

4 min read
Committed use discounts are available for Dataflow streaming

Google introduced the general availability of Dataflow streaming committed use discounts (CUDs), providing a new way for you to save money on a key driver of your streaming costs: streaming compute.

Read more
4 min read
Rabbit Startup Program: Navigating Cloud Costs for Sustainable Growth

We are happy to announce Rabbit Startup Program! We would like to help and accelerate the growth of startups in a cost conscious way to maximize the ROI of the cloud in the hypergrowth phase

Read more

Want to bridge the cloud cost transparency gap between Management and Engineering?

Get in touch with us, we're here to help.
Zoltán Guth

CTO

Balázs Molnár

CEO