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
CTO
CEO
Rabbit Team
6 min read
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.
Not all of these commitments are available for all services in GCP. For Compute Engine both types of discounts are available but for
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:
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.
There are at least two strategies to calculate CUD with:
For the sake of example let’s see a generated data based chart of a Compute Engine usage with weekday highs and weekend lows.
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.
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.
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.
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:
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.
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.
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 moreWe 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 moreCTO
CEO