top of page

What are Committed Use Discounts? ('CUD') and How to Leverage it to Control Cloud Costs

Writer: Matan Ben-IshayMatan Ben-Ishay

Updated: Apr 25, 2024

Committed Use Discounts (‘CUD’) are discounts received on Cloud resources pricing in exchange for a commitment by the user to pay for the resource through duration of the commitment period. In simple terms - you commit to paying for a certain number of resources, say 100 vCPU and in return Google is charging you a lower price per unit for those 100 vCPU. During the entire commitment period (which usually is either 1YR or 3YR) the customer is obligated to pay for the resource - whether the customer actually uses it or not.

As a user you can still provision how much resources you want (with the applicable quota limitations), but you will only pay the discounted price on the resource amount covered by the commitment amount and period you selected. Any amount above the CUD amount getting will be treated as 'On-demand usage' and charged at the regular list price. So if you are planning to use the resources for the foreseeable future anyway why not purchase CUD and pay less for it?


On-demand Usage and Sustained Use Discounts ('SUD')

As mentioned, usage not covered by CUD is usually referred to as ‘On-demand’ usage. It's the same resource but on-demand means it's not under CUD and so its unit cost doesn’t get the discount benefit that usage covered by CUD receives. On the other hand, you only pay on demand when you actually use the resource whereas with CUD you pay for it even if you don’t technically use it (since you committed to pay for it in return for lower cost). 

Another important concept (that Google is depreciating over time) is Sustained Use Discounts (SUD). SUD is a discount that is applied automatically to certain resources that are running on-demand if they are being used for more than 25% of a billing month (usually 7 or 8 days within the same month depending on the number of days in the month). The discount increases up to 30% with the more days the resources are being used within a billing month. This basically gives customers an automatic discount protection for on-demand usage. The discount for SUD is lower compared to CUD which can be 37% (1 year commitment) to 55% (3 year commitment) but it is still better than on-demand and its automatic so you really don't need to do anything to get it.

Why do Cloud providers offer CUD? What is their incentive? 

For the customer the incentive is clear - discounts mean lower costs. But why does Google (and other cloud providers) offer CUD? The answer is likely physical servers forecasting accuracy & certainty. if they know what the customers' demand is then they can forecast the needed capacity more accurately and that directly translates to savings for them. It doesn’t mean they only use what is committed by customers for their forecast but it sure helps in estimating how many and for how long physical servers will be needed for. 

Commitment Period: 1YR or 3YR?

CUD can be purchased for either 1 year or 3 years with the latter offering higher discounts (CPU 1YR is 37% and 3YR is 55%). The decision of which to purchase depends on the strategy a customer chooses and based on the long term capacity forecast.

A longer commitment period can mean more risk since within 3 years machine type can become outdated or services’ needs can change and need less capacity vs before (resulting in wasted CUD with no actual usage). There is generally more flexibility and ability to react to changes such as those mentioned above if you purchase 1 Year CUD. But if you are strategic about CUD then you can reach a very high level of flexibility even with 3 Year CUD while also significantly lowering your cost compared to the alternative of 1 Year CUD.

Split your CUD purchases

Breaking down the purchases of CUD to smaller pieces can also benefit the customer and create flexibility for reacting to unplanned changes - it allows the customer to have various commitments that end at different intervals & times. Splitting the CUD purchases also depends on when you need the CUD to begin with and when you renew but generally speaking breaking down CUD to multiple commitment creates flexibility to unplanned changes down the line.

For example - as illustrated below, purchasing a 3 Year CUD for 1K vCPU every year would mean that in 2 years the customer would have 1K vCPU about to expire in 3 years, 1K vCPU that is about to expire in 2 years and 1k vCPU that is about to expire in 1 year. In Other words, the customer has three 1 Year commitments but for the price of 3 Year CUD. This is a hypothetical scenario and reality doesn’t always work this way but the point is that 3 Year CUD is significantly cheaper vs the other alternative. At the very least it's worth thinking strategically long term beyond just a 3 year period. 


Not Renewing CUD as a Flexibility Lever

Eventually every CUD purchase you make will be getting close to the end of the commitment period whether its 1 or 3 years and you would need to make a decision: renew it, reduce it, or not renew at all. The concept of not renewing a CUD is usually referred to as allowing 'CUD to fall' and as we saw in the example above - can be used as a flexibility tool. Generally speaking having CUD fall off in your future is usually a good problem to have since it allows us an opportunity to asses the total CUD level. If we no longer need all the capacity so we could reduce our total CUD if we desire so - and by that our costs.

A good habit is to always look at all CUD purchases before purchasing a new amount. Imagine you witness an increase in usage that you don't know if it's temporary or not and not sure if you should purchase CUD for it or not. If you look at your existing CUD and know a certain amount is falling soon then maybe you will be more inclined to purchase an amount since you have an exit point in the form of CUD falling off soon. Always consider all of your aggregated CUD purchases and exit points when you are analyzing whether to purchase more CUD or let usage run on-demand.

bottom of page