If you don't know what Committed Use Discounts ('CUD') are - then you can read all about it here but its basically getting discounts on your Cloud resources usage in exchange for a commitment to pay for them in the long term.
What is even CUD sharing?
Only GCP users with admin access can purchase CUD due to the commitment and liability aspect as it could be material from a dollar perspective - by purchasing CUD with a few clicks admin users are basically committing to pay for 1 or 3 years worth of resources which can add up to a few hundred thousand and even millions of dollars. By default CUD purchased within a specific project can only be used for that project but you can (and should) enable discount sharing across projects.
When discounts are shared, CUD purchased within one project can be applied automatically to all usage across all projects within a billing account. Generally speaking you should always have the discount sharing option enabled as there are very limited cases where you don’t want to share discounts across projects (for example: A project used for a specific customer that prefers more flexibility and doesn’t want to commit to usage amount or CUD).
Once sharing is enabled, you don’t have to worry about it again and can shift attention to determining the total CUD amount you should purchase. This is under the assumption that the objective of purchasing CUD is to ultimately lower the expected cost and be cost efficient. When CUD sharing is enabled - if one project doesn’t utilize its allocated CUD, GCP automatically assigns it to a different project and thus actually lowering our cost vs the alternative of not enabling and paying more.
Lets visualize this using an example:
Example 1: CUD ‘discount sharing’ not enabled: for Project 1 on the left we will be paying for 800 vCPU (the amount we committed to - the black dotted line). For Project 2 on the right we will be paying for 500 vCPU on demand. Total paid: 800 vCPU CUD, 500 vCPU on-demand.
Example 2: CUD ‘discount sharing’ enabled: for Project 1 we will be paying for 800 vCPU (the amount we committed to - the black dotted line). For Project 2 We will only be paying for 200 vCPU on demand since 300 vCPU are covered by Project 1 given we paid for 800 vCPU but only used 500 vCPU in that project. Total paid: 800 vCPU CUD, 200 vCPU on-demand. Compared to Example 1 we just paid less for identical usage.
How to Enable CUD Sharing?
You only need to do it once and never worry about it again. To enable discount sharing for CUD or confirm its indeed enabled just follow these steps:
First make sure you have the right admin access (you can learn about admin access here).
Next go to ‘GCP Billing Console’ and click the ‘CUD analysis’ tab.
From the ‘Commitment Type’ drop down menu choose ‘Resource Based CUD’ and look at the ‘Commitment Scope’. If it says ‘Billing account’ then discounts are shared but if it says ‘Project’ then discounts are not shared. If discounts are not shared, in order to change it you have to click ‘EDIT’ which is right next to it and enable discounts sharing.
These steps are true to 2024 and are subject to change as Google makes changes to GCP Billing Console (more on enabling Resource Based CUD discounts sharing can be found in GCP documentation here).Â
CUD Attribution
Another aspect that is more used for charging back the cost to business units or for budget control is 'CUD Attribution'. There are multiple options that can be controlled by the user to attribute the amount of CUD purchased across the different projects in your GCP account:
No attribution (keeping it unattributed)
Proportional attribution
Prioritized attribution
The most common attribution is proportional as it allows the most control of CUD attribution by driving accountability and helping identify anomalies or unplanned changes. When the attribution is proportional, any anomaly or sudden increase of usage will become visible as the cost for the specific project where the increase happened will visibly change - higher usage amount equals higher costs (and often times as on-demand costs).
Why does proportional attribution drive accountability? If the increase is unplanned then the burden of the unplanned cost will be shared across all projects proportionally. Other projects, while their usage has remained flat, will receive a smaller piece of the CUD and their overall cost will increase. This is likely to bring questions from teams around why their cost has increased although their usage stayed flat and questions around why the unplanned usage isn't attributed to the project that created it. Ultimately, this can serve as a function of peer pressure for generating accountability on teams. The incentive here is clear - teams should let the Cloud efficiency and/or centralized team handling CUD purchases know ahead of time if they are planning to increase to avoid over spending.
Any Reason to not Enable CUD Sharing?
As mentioned, there could be rare cases where we don’t want to enable discount sharing but those are very limited and by rule of thumb you should make sure discounts are shared. Generally speaking making decisions around CUD purchases should be made in the context of all consolidated usage across all projects - ideally there is a single centralized team that looks at the aggregated usage across all projects within a billing account and makes the cost efficient decisions of whether to purchase more CUD or not.