When Amazon Web Services got started way back in 2006, EC2 On-Demand pricing was an immediate success with developers. They loved the ease with which they could easily spin up a wide variety of AWS EC2 Instance types, whenever they needed them, all for a reasonable price, and then terminate them when done. This was a great improvement on waiting and waiting for IT to order new machines, configure them, or more critically, not even being able to do tests on machines that were far too expensive for short-term projects.
In this blog we will discuss how the new-found cloud freedoms quickly spawned a whole host of challenges, how AWS has continued to add additional pricing options as a result, and how the current abundance of options has in turn created a unique set of challenges and potential solutions.
Reserved Instances to the Rescue for Runaway EC2 Costs
While EC2 On-Demand adoption was massive, the cost of running instances On-Demand for long periods, whether intentionally, or by accident, was also quite massive and most organizations were surprised by how quickly their cloud bill became a very significant part of their IT spend.
To address the intentional part of the rising costs, specifically steady-state, long-term usage, AWS introduced Reserved Instances in 2009, where one could make an upfront payment for a 1 or 3 year commitment, and in exchange, receive anywhere from 30% – 72% discount in comparison to on-demand pricing.
Reserved Instance Adoption is Slowed by Financial Lock-In
As RIs initially were quite rigid in their pricing structure, customers with dynamic environments, were very hesitant to use them, with the legitimate concern that they would get locked-in to a pricing structure that offered no flexibility for change.
Some customers who bought RIs and then had unexpected changes in their workload requirements, would get stuck with a sunken investment, and even negative ROI. As a result, many AWS customers who could have benefited from RIs, stayed away.
AWS Continuously Increases Reserved Flexibility
In multiple attempts to remedy this issue, over the years AWS introduced various services and new pricing structures that allowed for more flexibility for more potential customers:
- In 2012 AWS Marketplace was opened as a secondary market where one could buy and sell RIs from other AWS customers. This potentially mitigated the risk of getting stuck with an unused Reserved Instance.
- In 2014 AWS allowed RI users to manually modify unused RI and re-apply them within the same instance family, based on their normalization factors (this was done either by combining two RIs into a larger one, or breaking an RI down into two or more smaller instances).
- In 2016 AWS introduced yet more options for the user to choose between:
- Convertible RIs which allow users to manually modify RIs across different family types, OS, and sizes.
- Regional RIs automatically applies unused RIs to any other running EC2 instances within that same family (for Linux) or to exact same instance size (for all other OS’s), with the added flexibility of being transferable to any AZ within that Region.
- In 2017 Instance Size Flexibility was introduced to allow for automatic application of an unused RI to other EC2 instances within the same family, that match up, based on the normalization factor.
- In 2019 AWS added additional reserved capacity packages to choose from, with the introduction of Savings Plans (“EC2 Savings Plans” and “Compute Savings Plans”). Customers could now commit to spend a desired amount per hour, e.g. $35/hour, for either 1 or 3 years. In this example, anything spent up to $35 will be charged in accordance with Savings Plans rates (between 66-72% savings). Any spend above the committed amount will be charged at On-Demand rates.
Reserved Instances vs. Savings Plans
With the introduction of AWS Savings Plans the obvious question is will Reserved Instances remain relevant and if they do, how to decide when to use them and when to use Savings Plans instead. For the time being there are sufficient differences between the two pricing options, creating pros and cons for AWS customers depending on their specific use case.
So now in early 2020, when planning your cloud finances, here are some points to keep in mind:
- Savings Plans can only be applied to EC2, Lambda and Fargate while Reserved Instances have broader application for EC2, RDS, Redshift, DynamoDB, Elasticsearch and ElastiCache.
- Convertible Reserved Instances allow for the increase of commitment (i.e. add additional reservations to cover more EC2 Instances) during the contracted term, without the need to increase the term. This is especially helpful when needs change and committing to a new 1 to 3 year term doesn’t make sense. With Savings Plans any addition to the original contract is done with a new contract that starts from day 0.
- EC2 Instance Savings Plans will apply usage across any given instance family, regardless of OS or tenancy. Standard Reserved Instances can also apply to usage across any given instance type family, but require the instances to be Linux and default tenancy.
- Standard Reserved Instances can be bought and sold on the AWS Marketplace allowing for greater flexibility, while Savings Plans cannot, requiring you to keep your committed spend at the level you defined.
- Convertible Reserved Instances are scoped to a specific instance type, OS tenancy and region while Compute Savings Plans will apply across all of your usage types in multiple regions.
The Paradox of Choice
One might think that all these different AWS pricing options would guarantee fully optimized cloud spend. But all too often, having so many choices can lead to “decision paralysis”, especially when handling large, complex deployments that require rigorous capacity planning, and cost benefit analysis by DevOps and Finance teams.
In our experience enterprises invest a huge amount of human resources for a few weeks every quarter or two, just for Reserved Instances and Savings Plans planning and procurement.
First, various project or application teams need to give an estimate of how much compute resources they require for the upcoming period.
This then needs review by the TechOps or DevOps teams to confirm that the planned project(s) indeed require the requested compute power.
Finally, the finance team needs to review the specific flavors of Reserved Instances or Savings Plans being suggested and ensure that the recommended reserved capacity will truly deliver positive ROI.
Much of this is often done working with cumbersome spreadsheets, with tedious review of historical cloud usage and performing complex projections of expected compute capacity needs. Even with the AWS Spot Market for buying shorter-term, second-hand RIs or for selling unused RIs, achieving any significant value, requires a tremendous investment of time of effort.
Perfect Reserved Capacity Planning for the Cloud
Fortunately, Spotinst Eco has an incredible track-record helping companies completely streamline the process of identifying when to buy AWS Reserved Instances and Savings Plans, and what type as well. Not stopping there, Spotinst Eco fully automates the ongoing management of the reserved capacity, ensuring maximum utilization, ROI and financial flexibility, with minimum time and effort required from the DevOps and Finance teams.
Cost Analysis Before Buying Reserved Capacity
Cost Analysis After Buying Reserved Capacity with Eco
Sounds interesting? Book a demo with a Spotinst solution architect today!