In November of 2019, we were one of the first providers to cover the release of AWS Savings Plans. At the time, we had a hypothesis that Savings Plans would not be a wholesale replacement for Reserved Instances, but rather a complement. We felt this way because while Savings Plans—Compute Savings Plans in particular (the EC2 Instance Savings Plans are materially less attractive in our opinion)—deliver tremendous optionality in terms of region and compute product coverage, they are fixed economic commitments that create commitment risk.
What do we mean by commitment risk, if Compute Savings Plans possess a high level of optionality? Compare them with Reserved Instances across two dimensions of risk mitigation:
- Reduction. There is no way to decrease the Compute Savings Plan commit if compute usage drops below the commitment amount, unlike the Convertible RI.
- Removal. There is no way to dispose of a Compute Savings Plan commitment, unlike the Standard RI (via the RI Marketplace).
So, while Compute Savings Plans are better than Reserved Instances in many aspects, they actually increase the commitment risk for users.
Even before the advent of Savings Plans, we encountered sophisticated AWS shops who would forgo significant cost reduction opportunities—tens of thousands of dollars per month—because commitments created risk (ex. “what if we end up moving to spot and away from EC2 six months from now?”). It was a clear signal to us of the importance of flexibility and the unique value of Convertible RIs. Most of the world doesn’t understand the real power of Convertible RIs and the ability to shape their hourly dollar commitment and term. This makes them a natural complement to Compute Savings Plans.
After working with AWS power users over the last seven months, we have conviction that Compute Savings Plans should be part of almost every discount management program. In fact, we’ve integrated them into our platform and utilize them as part of every customer discussion. However, the best outcomes, in terms of dollars saved and risk managed, are achieved by blending Compute Savings Plans and Convertible RIs. It’s the combination of these instruments, managed by ProsperOps algorithms and our real-time execution platform, that allow us to drive our customers’ global compute discount to world class levels of 40+%, while also protecting their downside risk.
Let’s look at a real-life B2C customer whose business was impacted by the pandemic to demonstrate the power of ProsperOps’ Savings Plan + RI approach (see Figure 1). The customer was averaging roughly $20k per day of compute usage (purple bars) for the first 13 days of the month. During that time, their commitment (red line) averaged ~87% of that usage and was comprised of Compute Savings Plans (gray shading) and Convertible RIs (green shading) (note that this level of commitment would be considered very risky if solely using an immutable commitment like a Compute Savings Plan).
Then, due to the pandemic, business conditions radically changed and compute usage needed to be reduced by ~40% over a 7 day period. ProsperOps algorithms were able to “squash” the RIs—to prevent overcommitment—while maintaining a spend coverage of ~94% and a utilization of >99%. Overall March compute gross savings were ~$99k.
Without ProsperOps, the customer would have followed one of two commitment strategies using a Compute Savings Plan:
Strategy A: Commit Aggressively
By committing entirely with a Compute Savings Plan covering ~87% of usage (see Figure 2), the decline in usage (purple bars) would have dropped below the Savings Plan commitment (red line), resulting in ~$3.6k/day of over-commitment (delta between the red line and gray shading). That overcommitment would have lasted until the usage increased above that commitment or the Savings Plan term ended. With this strategy, March’s savings would have been ~$30k versus the ProsperOps approach but more importantly, they would have exited the month being so overcommitted they would be losing money on their commitments (i.e. have negative savings) until their compute usage grew (it still hasn’t as of the time of this writing).
Strategy B: Commit Conservatively
By committing with a Compute Savings Plan covering only ~31% of usage (see Figure 3), the decline in usage would not have resulted in an overcommitted state. However, this strategy subjects most of the usage to the on-demand rate. That would have resulted in a March savings of ~$50k less versus the ProsperOps approach.
This real world example shows the power of a ProsperOps managed Compute Savings Plan and Convertible Reserved Instance portfolio to both maximize discount and maintain a high degree of commitment flexibility to manage risk.