CUD Types: Resource Based vs Spend Based

For GCP there are 2 different CUD types: Resource based and Spend based. Resource based means committing to a resource amount and Spend based means committing to a dollar amount with each having their own nuances, rates, and terms. Both CUD types are a commitment for either 1 Year or 3 Year with the latter offering higher discount % in consideration for the customer committing to a longer period. 

Resource based CUD

Currently Google offers Resource based CUD mostly for compute and storage SKU which usually applies to CPU, RAM, Local SSD and other specific resources across different machine types (N1, N2, N2D, etc) and are region specific (meaning CUD purchased for one region cannot be used for other regions).

Customers input the amount of the resource in question (i.e. 100 vCPU), the machine type (N1) and region (us-central1) and starting the next day that amount is considered covered under CUD.

Usually it's preferable to spin up the machines before purchasing CUD but it depends on preferences and some customers purchase even before spinning up the actual machines and seeing usage. If you spin up the machines before purchasing CUD (and running on demand for a bit) could have a significant advantage although it's slightly more costly - it can help confirm the amount you want to purchase CUD is indeed the amount you need.

Be aware that some teams find it challenging to accurately estimate resource increases. They might say they need 1000 vCPU but once they spin up the machines it might turn out they need less which is why I recommend starting with on-demand and only purchasing CUD after a day or two and once you have gotten a better sense of the average daily usage.  

Spend based CUD

This can be a more complex CUD option compared to Resource Based and in certain cases can be confusing to understand the unit cost and how this compares to Resource based CUD for the same resource. Spend Based aligns to specific SKU and means the customer is committing to a dollar spend amount ($$$) and not necessarily the amount of resources (usually the customer inputs an hourly spend level commitment for 1 or 3 years).

Google is increasing the offering under this option but for most the applicable resources are compute and storage within services such as BigTable, Cloud Function, etc.

For some resources Google only offers customers one option of the two and the offering depends on the resource. As an example - for Cloud BigTable google only offers Spend based CUD and customers can’t purchase resource based for it.

On the other hand there are some resources where customers can purchase and enjoy a combination of both such as CPU resource based CUD which can be used in concurrent with Flex CUD which is a special case of Spend based CUD. 

Flex CUD (Special Case of Spend Based CUD)

Google introduced Flexible Committed Use Discounts (‘Flex CUD’) in 2022 with the goal of allowing greater flexibility for customers to change regions and machine types. It is a form of Spend Based CUD that applies to multiple compute engine resources across Compute and storage (mostly vCPU and RAM). Flex CUD covers most machine types (N1, N2, N2D, E2 with more included in the future) and regions so the customer isn’t limited in purchasing in one region and can purchase Flex CUD that can be applied across regions. 

As the name implies Flex offer flexibility but is also more expansive compared to Resource Based CUD (but still cheaper compared to on-demand rates).

Here is a good summary of the difference between Resource Based CUD and Flex CUD:

Flex CUD use case is where you plan to switch regions in the future or migrate some workloads to new machines but don’t want to take the risk of double paying on Resource Based CUD for a specific machine type / region as you migrate or switch regions.

Flex CUD could be a valid use case for customers that often migrate between GCP regions and don’t want to purchase Resource Based CUD in both regions they are migrating to and from. Flex CUD solves this problem since the customer can migrate whenever it wants without having to worry about the region.

Flex CUD can be used in concurrent with Resource Based CUD and will only cover against on-demand usage that remains after the Resource Based CUD has been applied. In other words - Google is allowing the customer to benefit from the cheaper option first which is the Resource Based CUD.