Hyperscaler (GCP, Azure, and AWS) Commitment Discounts


heads and clouds made of gears

As customers contemplate moving workloads and platforms to the public cloud, they are faced with a myriad of choices surrounding how they make this shift a reality.  Selection of the appropriate hyperscaler can be a complex decision, one which involves not only understanding the technical nuances of the platforms themselves, but also the commercial constructs unique to each of the different suppliers.

See Our Hyperscaler Resource Center

Hyperscalers will commonly position two primary levers to bring down overall cost: commitment discounts and investment credits.

In this blog, we will look at the approach Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS) take towards commitment discounts on their platforms, and how you can optimize these commitment options to secure the best possible deal.

How the Hyperscalers Approach Commitment to Their Platforms

GCP, Azure, and AWS take a similar layered approach associated with commitment to their platform by creating two different types of commitments:

  1. Usage-based commitments (resource, instance-based)
  2. Spend/relationship-based commitments

While these two commitments exist independent of each other, understanding what usage-based commitments you are able to make is critical to entering into the appropriate spend/relationship-based commitment.  Given this, let’s look at the usage-based commitment models between these three hyperscalers and how they differ.

Table comparing hyperscalers, AWS, Azure and GCP

GCP’s Usage-based Commitment Model

Google provides two different options towards usage-based commitments: Sustained Use Discounts (SUD) and Committed Use Discounts (CUD).

SUDs are unique (especially in comparison to the other hyperscalers) in that there is no commitment at all – GCP provides automatic discounting on resources that are run over 25% of the time during a month.  This does not require an upfront commitment, but rather provides discounts over 20% (above list) simply for sustained use of the resources over the course of a month.

CUDs are closer to the Reserved Instance models you see with Azure and AWS but have some key differences which provide additional flexibility.  Commitments to CUD are made to specific amounts of vCPU & memory usage over the course of the commitment (1-3 years).  Because the commitment is made to quantities of vCPU & memory usage (and not specific instance types), customers have greater flexibility to shift their commitments between instance types.  CUDs greatly increase discounting, providing a reduction of more than 50% of list price, depending on machine type and length of use.

Lastly, it’s important to note that a blend of these two types is possible – any workloads that do not qualify for CUD automatically quality for SUD.

Microsoft Azure’s Usage-based Commitment Model

Microsoft provides a more streamlined model compared to its competitors, focusing solely on Reserved Instances (RI) as the usage-based commitment available to customers.

Microsoft Reserved Instances do have a few unique attributes that are of note.  These RIs have a fixed instance type, OS, and tenancy for the length of the commitment.  However, Microsoft has built in some flexibility into their model.  RIs can be designated for flexibility in instance size, allowing them to grow beyond the initial committed size.  RIs can also be exchanged across the same family instance type (even across regions and series) but cannot move between family instance types.  Lastly, RIs can be cancelled, but may be subject to termination fees.  Bear in mind that an RI cannot be cancelled if the refund would exceed $50K in a 12-month period.

AWS’s Usage-based Commitment Model

While Amazon also has established a Reserved Instance model, Amazon has created two different levels of Reserved Instancing to provide customers with maximum choice and flexibility: Convertible Reserved Instances and Standard Reserved Instances.

Convertible Reserved Instances provide a more flexible form of reserved instancing, but at a reduced discount percentage.  These Convertible Reserved Instances can be exchanged for new instance types, tenancies, and OS’s, and can also be merged or split.  However, given that they are still Reserved Instances, the overall value of the commit cannot be reduced.  While the value cannot be reduced, if list prices do go down on compute resources, you can assign more resources to your instances to make up for the reduction in list cost.  Convertible Reserved Instances provide a discount of over 30% above list, which increases based on the length of the commitment (1 – 3 years).

Standard Reserved Instances, conversely, are much more rigid and in many ways act similarly to Reserved Instances you would see from Microsoft Azure.  These Standard Reserved Instances are also fixed for instance type, OS, and tenancy for the length of the term.  Standard Reserved Instances provide a discount of over 40% above list, which also increases based on commitment length.

One unique wrinkle to the AWS Standard Reserved Instance model is that, unlike Microsoft Azure, there is no simple mechanism to exchange or cancel a Standard Reserved Instance once it is entered into.  Instead, AWS users can sell their Reserved Instances on a marketplace, where different customers may sell compute resources to one another that they no longer need.  This is a convenient avenue for Amazon as they get to maintain the revenue on their books and make any exchanges/shifts of these RIs a “customer problem”.

Spend/Relationship-based Commitments

While Google, Microsoft, and Amazon all have different names for their spend-based commitments, the concept remains the same.  All three hyperscalers will offer additional discounts above list based on long-term financial commitments to their platforms.  As one would expect, the size of the commitment and the length of the commitment influence the amount of discount offered.  They all, similarly, come with the same caveat/warning – the customer is contractually obligated to pay the full amount of the spend commitment, whether those resources are consumed or not.

Whether you are entering into a Private Pricing Term Sheet (formerly EDP) with AWS, an Azure Prepayment (formerly Azure Monetary Commitment) or a GCP Commitment Agreement, it is critical that you enter into the right spend commitment for the strategic roadmap you are on.

Final Thoughts

The two layered approach to commitments with your hyperscaler of choice is critical to understand and forecast appropriately.  Failing to properly account for usage-based commitments, will leave customers subscribing to far too high a spend-based commitment, as they optimize their footprint and enter into long-term reserved instancing.  Similarly, over-forecasting your planned use of reserved instancing may leave you with a spend commitment that is far too low, and you will end up overpaying for your utilization of your hyperscaler.  Avoid trapping your company in unused or overpriced compute spend – make sure you understand and make appropriate use of the commitment options afforded to you.

Comment below, follow me on LinkedIn and follow UpperEdge on Twitter and LinkedIn.  Learn more about our IT Cost Optimization Advisory Services.

What to Read Next:

Leave a Comment

*