To Commit or Not to Commit: Making Sense of Cloud Savings Options

So we all have commitment issues. Let’s face it, “commitment” is probably one of the most scary words in the English lexicon.
Jokes aside, what does it actually mean when we talk about cloud commitments?

What Are Cloud Commitments and How Do They Work?

Well, basically it’s a model where you can commit to the cloud vendor either for a particular resource or an amount of spend. The commitment will usually be for a term of 1 or 3 years and based on both the size of the commitment and term, you will receive a discount. These discounts usually vary from around 30%-70%.

Now just to be clear, this is not a negotiated contract discount. While there are such things between large cloud consumers and vendors, what we are discussing here are predefined (by the vendors) commitments that are public knowledge. All discounts are published on the cloud vendors website and available to be purchased on demand via the cloud vendors portal.

So as mentioned, there are generally two main types of commitment:

1. Resource-based
2. Spend based

Resource based

Resource based, also commonly referred to as a reservation or reserved instance (RI) is a commitment that is based on a certain resource type such as a certain SKU of a VM or managed DB, X amount of managed cores or any other number of resource types that varies based on the Cloud Vendor. 

You are basically committing to a certain type of resource in a certain region.

The commitment will be for 1 or 3 years, depending on your preferences, with the 3 year commitment offering you a higher discount.

• In Azure this offering is referred to as an Azure Reservation.
• In GCP Resource-based committed use discounts.
• And in AWS as Standard or Convertible reserved instances.

Azure allows purchasing of reservations for the following resource types: VM, Blob, Files, Cosmos DB, Data Factory, SQL Database, Synapse Analytics, Databrick, App Service stamp Fee, Database for MySQL, Database for PostgreSQL, Database for Maria DB, Data Explorer, Cache for Redis, Dedicate Host, Disk Storage, Backup Storage, OR Software Plans (SUSE Linux, RedHat, RedHat OpenShift).¹

GCP allows purchasing of reservations for the following resource types: Compute Engine, Software Licenses (SUSE Linux Enterprise Server, SLES for SAP, RHEL for Linux and RHEL for SAP images), OR GPUs and local SSDs with Capacity Reservation.

AWS supports the purchasing of reservations for the following resource types: EC2, RDS, ElasticCache, OpenSearch, Redshift, and DynamoDB.

Or in the case of convertible reserved instances just for EC2.

Differences between cloud reservations

So now you’re asking yourselves are there any differences between the different clouds other than cost? The answer is a firm YES.

AWS as you noticed has two models

• Standard reserved instances are non-refundable or exchangeable but can be sold via the AWS marketplace to other users.
• Convertible Reserved Instances are exchangeable and can be exchanged for another convertible reserved instance.

Based on this the convertible reserved instance discount is lower and it is also only available for EC2 instances. 

AWS also offers a full upfront payment option, partial upfront or no upfront with the discount being slightly larger for upfront payments.

Azure offers up to $50,000 a year of refunds, allowing you to refund any remaining commitment up to the $50,000 mark a year.

Aure also offers an exchange, allowing you to exchange an existing reservation for a new reservation and this exchange will not count against your refund limit. Just so long as the new reservation costs more, even by a single dollar, than the previous remaining reservation.

Azure also offers both upfront or no upfront purchasing options however with no difference in discount.

GCP does not allow for any cancellations or refunds. GCP billing is all monthly with no upfront charges.

Things to look out for

Once a commitment covers a service, on-demand pricing no longer takes effect. So, shutting down an instance will not pause charges as you have already prepaid for the resource via the commitment plan.

Spend Based

Spend based also commonly referred to as Saving plans (AWS & Azure) is a commitment plan based on actual spend. 

You basically commit to a certain level of monthly spend in $ for a term of 1 or 3 years and receive a flat discount on all of your spend. However the spend commit is scoped to certain resource types and is not for your entire cloud spend and unlike reservations there is no commitment to a certain region.

There is also no commitment to a certain cloud service/resource type, with the exception of the AWS EC2 instance savings plan that is scoped to just certain EC2 instances and is also limited to a single region.

• In Azure this offering is referred to as Azure Savings plan for Compute
• In GCP this offering is referred to as GCP Spend-Based Committed Use Discounts
• In AWS as EC2 Instance savings plan or AWS Compute Savings Plan.

Azure Savings plan covers VM (with exceptions), App Service (with exceptions), Functions, Container Instances, OR Dedicated Host

GCP Spend based Commit covers: Cloud Bigtable, Cloud Run, Cloud Spanner, Cloud SQL, Compute Engine, Cloud VMware Engine, Kubernetes Engine, Memorystore for Redis OR Memorystore for Memcached

AWS Compute Saving plan covers: Compute (EC2, Lambda, Fargate) Or EC2 instance savings plan that covers only EC2 (with a slightly higher discount than compute savings plan)

Differences between cloud Spend Commits

Well unlike reservations here there are much less differences.

None of the Cloud Vendors allow refunding of the commitment.

With the slight exception of AWS allowing a cancellation within 7 days of purchase as long as the commitment is below $100 an hour ($73,000 a month).

Things to look out for

Another gotcha is that the spend is calculated on an hourly basis. So you can’t just go ahead and look at your entire monthly spend on eligible services as you might have peak and low points based on scaling and other load requirements, so you are going to want to commit to your low points. In other words, you are committing to an hourly level of spend and not a monthly or yearly amount.

You will also need to take into account that you need to commit to the spend after discount and not the spend pre-commit, so you need to work out your exact hourly spend, how much discount you will receive, and then commit based on that number.

Using Anodot’s advanced Saving Plan Simulator can help you analyze your exact usage and recommend the best savings plan configuration for your environment, allowing you to apply an aggressive savings plan without over-committing.

Conclusion

So we’ve covered the basics of the three major hyperscale cloud providers’ commit plans.

We’ve seen that there are two main models: 

• Resource commit – Scoped to a specific resource type in a specific region.
• Spend commit – Scoped to an array of compute services with no region limits.

So while committing to a certain resource type will provide a higher discount, using a spend commit will offer you a bit more flexibility and less management overhead.

One last thing, if you have both types of commitments in place then the resource-based commit will apply first then the spend commit on any left over uncovered resources.

And this is usually the best practice for maximum savings.

Cover what you can with a resource reservation then cover 70-80% of the rest with a savings plan.

We always leave 20%-30% without commitment to allow for maximum flexibility.

And always, and I mean always check out the latest information published by the Vendor. Prices and terms are being updated constantly so keep an eye out for changes and updates.

Want a proof of concept? Talk to us to learn how much you can save with Anodot’s tools.