Not sure what the differences are between various types of discounts and commits in the Google Cloud ecosystem? Don't worry, it's a common source of confusion in the marketplace and Cloudbakers is here to help clarify this for you. While we're at it, here's a quick plug: if you still need more help with this after reading this post, don't hesitate to reach out and contact us to learn more about a free FinOps assessment and Managed Cloud Optimization offerings!
CUDs: Committed Use DiscountsIf you use virtual machines and kubernetes (aka k8) to run your applications, Committed Use Discounts (CUDs) are worth a look to save a lot of money.
Think about the cloud from the perspective of the provider (Google, AWS, Azure): they have an insane inventory management problem. When all is said and done, IT outsourcing is a razor thin margin business and has consistently burned data center businesses for 20 years. Better server inventory management (when to buy and how much) can make a huge difference.
You can infer just how much of a difference this makes based on the crazy discounts Google will give you to commit to using a certain amount of server capacity over a 1 year period (XX%) or a 3 year period (YY%). When you sign up for a CUD, Google has a better forecast of future demand.
SUDs: Sustained Use DiscountsSimilarly, using a server on a sustained basis, also helps with that inventory problem. If you constantly turn servers on and off (ironically one of the benefits of the cloud), it makes the inventory problem worse. As a result, if you turn it on and run it consistently, Google gives you a substantial sustained use discount (SUD).
They do this automatically and you don't have to commit to anything or sign up for anything. You just design your architecture with this in mind.
This is analogous to what we called designing for manufacturability - sidebar story - we had a client who was trying to reduce manufacturing costs and in the process we discovered one of the most costly steps was putting square holes in curved surfaces. Manufacturing engineers loved the challenge as it included submerging parts in special liquid and firing lasers to make the holes one atom at a time. We went to the design engineers and asked if there was a special reason for the square holes, nope. They changed the design and the manufacturing costs came down 75%.
The same can happen for you in cloud. Make sure your engineers design with knowledge of how their application behavior will affect the cost to run it.
GCP CommitsIf you are talking to anyone in Google Cloud right now, you are very likely having conversations about commit contracts. It was an unfortunate choice of language. These have NOTHING to do with CUDs.
Again, it's important to think about the situation from the point of view of the cloud provider. Cloud is 'on demand' and month to month. That makes financial forecasting a nightmare and as a result, is another contributor the historically low margin nature of data center operations. Another factor here is simply enterprise IT buying expectations set over the last 30 years. Enterprise IT needs to buy in bulk, over many years, and as a result, expects a hefty discount for the guaranteed volume.
Commit contracts are simply a financial instrument - a commitment to spend X over Y years and you receive a discount of Z% as a result of making that commitment. For businesses with predictably growing spend, and especially if you are moving workloads from another provider (low customer service at AWS or low reliability at Azure) to GCP, you can negotiate attractive discounts, and even get customized discounts for your spend patterns - e.g. egress for media tech businesses.
The other benefit of a commit contract is that the discounts apply to all of your spend on GCP, so more mature application architectures that use serverless for their applications and databases can also benefit. Originally published on April 05, 2021