- Jason Flye
- Reading Time: 6 minutes
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. Selecting 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. Hyperscalers will commonly position two primary levers to bring down overall cost: hyperscaler 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:
- Usage-based commitments (resource, instance-based)
- 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.
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
Historically, Microsoft has focused solely on Reserved Instances (RI) as the usage-based commitment available to customers. However, in October 2022, Microsoft released their new Azure Savings Plan option to the public, designed to create additional flexibility beyond the standard RI model.
- Azure Savings Plan
Azure Savings Plan is a flexible pricing model that provides up to 65% off pay-as-you-go pricing in exchange for a commitment to a fixed hourly amount of compute. Rather than committing to a specific virtual machine type in a particular region (as is the case with Reserved Instances), Azure Savings Plan makes you commit only to a collective amount of spend on compute services per hour.
There are some key limitations to this model. After making a Savings Plan hourly commitment, customers must pay the full amount of the commitment, regardless of actual utilization. Additionally, if during the commitment period a customer exceeds the commitment made, excess spend will be charged at pay-as-you-go pricing, rather than the discounted rate.
- Reserved Instances
This is a much more rigid commitment model, with a fixed instance type, OS, and tenancy for the length of the commitment. Microsoft has built some flexibility into this model. For example, 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 unless the refund exceeds $50k in a 12-month period. Cancellations may also be subject to termination fees.
AWS’s Usage-Based Commitment Model
Amazon has taken a similar approach to Microsoft, where they have created both Savings Plan and Reserved Instance models. They created an additional layer of flexibility by providing two different forms of Savings Plan models and two different forms of Reserved Instance models.
AWS offers both Compute Savings Plans and Instance Savings Plans. Similar to Microsoft’s model, these Savings Plans require customers to commit to a consistent amount of spend per hour over a commitment term (1 or 3 years). They come with familiar caveats as well – you will be charged the committed spend amount (regardless of utilization) and any overage will be at On-Demand Rates.
The flexibility that AWS adds is that they have created two tiers to the Savings Plan model. With Compute Savings Plans, you can save up to 66% on EC2 usage regardless of instance family, region, OS or tenancy. With Instance Savings Plans, you can save a higher percentage (up to 72%), but you must commit to an Instance Family in a specific region.
While AWS also has a Reserved Instance model, there are two different levels of Reserved Instancing to provide customers with maximum choice and flexibility: Convertible Reserved Instances and Standard Reserved Instances.
- Convertible Reserved Instances
These 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 OSs, and can also be merged or split.
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 up to 66% above list, which increases based on the length of the commitment (1 – 3 years).
- Standard Reserved Instances
Standard Reserve Instances are much more rigid and, in many ways, act similarly to Reserved Instances you would see from 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 up to 72% 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”.
Relationship-Based Commitments
While Google, Microsoft, and Amazon all have different names for their relationship-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.
Taking Advantage of your Hyperscaler Commitment Discounts
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.
