For digital natives, public cloud infrastructure serves as both the backbone of their technology stack and the biggest cost center in their operating budget, which means that it must be constantly monitored to ensure that its costs are in line with the company’s overall business objectives. FinOps teams, which are responsible for managing these costs and fostering cross-functional collaboration between engineering, finance, and product departments, are therefore always looking for ways to optimize cloud costs and reduce spend whenever possible.
One of the most common and widely-practiced methods of cost optimization in the public cloud is through volume-based discounts known as commitments; i.e. the cloud provider offers a rate reduction in exchange for an agreement to use a certain amount of resources over a given period of time. On AWS, these commitments take the form of either Reserved Instance or Savings Plans. See the chart below, or learn more about the differences between these plans.
For all of the variables in the different types of commitments across cloud providers, one of the few standards is in the term lengths. These agreements are almost always offered either 1- or 3-year terms, and with varying levels of discounts depending on the length of term and the amount of workload flexibility allowed within the agreement. For example, a 3-year commitment will always offer a greater discount (~60-70%) than a 1-year commitment (~25-35%), and one that allows you to change regions or machine types will generally provide less savings than one which locks you in.
Given the need to balance operational and developer flexibility with cost management and overall business goals, it’s rare for even a semi-mature company to have a single type of commitment; most commitment portfolios are tailored to the specific needs and growth stage of the company, and are comprised of a mix of 1- and 3-year deals across different teams, regions, machine types, and more.
Here’s a basic example of how that might look for a hypothetical company on AWS that serves the US market:
|Cloud Provider||Plan Type||Term Length||Region||Machine Family||Discount||Expiration Date|
|AWS||Compute SP||3-year||Variable||Variable||63%||March 5, 2025|
|AWS||EC2 RI||1-year||US East-1||M7g||28%||November 4, 2023|
|AWS||EC2 RI||1-year||US West-2||M7g||28%||November 4, 2023|
|AWS||EC2 RI||1-year||US East||T3||29%||February 12, 2024|
|AWS||EC2 RI||1-year||US West||T3||29%||February 12, 2024|
In this example, Company X bought a basic Compute Savings Plan in March 2022 to cover the bare minimum of compute that they expected to use for the next three years. Later that year, as their workloads grew and the 3-year commitment wasn’t covering enough, they decided to commit to the M7g machine family and purchased additional 1-year Reserved Instances on each coast to cover additional workloads, then did the same a few months later when a new project arose that would require T3 machines.
This is a common strategy among companies as their cloud footprint grows (assuming that they even want to take on the risk of purchasing commitments). They use a mix of 1- and 3-year commitments with varying discount levels, terms, and expiration dates, all of which must be regularly tracked and maintained to ensure that projected usage and spend is not over or under, and to determine whether they should be renewed or allowed to expire when their terms end. Needless to say, this is a significant burden on any organization, regardless of whether or not they have fully matured the process by building a FinOps practice into their ongoing activities.
Simplifying the process
DoiT Flexsave™ was built to simplify and automate the process of commitment management. Flexsave analyzes ongoing compute spend to identify any workloads that are not already covered by existing commitments (i.e. SPs, RIs, Spot, or Enterprise Discount Programs) and then automatically applies the equivalent of a 1-year commitment discount to those on-demand workloads.
Once a company activates Flexsave in its AWS environment, they can use it to get the same discount rates as was provided by their previous 1-year commitments. This means that they can let any existing 1-year plans expire and simply let Flexsave take over.
In the hypothetical example provided above, Company X would be able to let 80% of their commitments expire. In doing so, they would not only ease the burden on their FinOps team (or whoever is responsible for tracking commitments and usage), but also provide their developers with additional flexibility to move beyond the machine families and regions that they were previously locked into.
When all is said and done, Company X’s commitment coverage will look something like this:
To learn more about commitment management and how DoiT can help grow your FinOps practice, download the Cloud Compute Commitment Handbook.