The world is constantly innovating, but that doesn’t mean newer things are always better than existing ones (remember New Coke?).
In late 2019, AWS introduced Savings Plans, their newest type of commit discount instrument. In particular, they introduced two types of Savings Plans: Compute Savings Plans and EC2 Instance Savings Plans (EC2ISPs). So how do these new tools compare to their predecessors, Reserved Instances? Our mission at ProsperOps is to autonomously deliver world-class savings outcomes for our customers. To do that, we have analyzed and extensively used all the various commit discount instruments and have a strong opinionation backed by data, that a combination of Compute Savings Plans and Convertible RIs, blended together and properly managed, consistently deliver the highest Effective Savings Rate. We’ve previously discussed the strengths and weaknesses of the Compute Savings Plan, but what about the EC2ISP?
In this post, we make the argument that for most people, EC2 Instance Savings Plans are inferior to their direct predecessor, the Standard RI. As such, unless you have one specific use case (discussed below), we recommend you avoid using EC2 Instance Savings Plans altogether. This may be an unpopular opinion (we\’re fine with that) and AWS is of course pushing Savings Plans these days, but consider the following five factors and then decide for yourself:
Discount
For a given EC2 instance, a matching Standard RI and EC2ISP deliver an identical discount.
Advantage: Draw. There is no savings advantage of one vs. the other so on this point, they are equivalent.
Scope
They are both regional (vs. global) commitments that apply to EC2 only and they both have 1- and 3-Year and All, Partial, and No Upfront options.
Advantage: Draw. Again, on this point, they are equivalent.
Ease of Purchase
Here’s where differences emerge. Savings Plan commitments are made in units of dollars, while RI commitments are made in units of instances. For RIs it is straightforward to specify the quantity of instances you want to cover. For Savings Plans, it requires calculating the correct dollar commitment. To illustrate, let’s assume you have the following instances you’d like to cover with either Standard RIs or EC2ISPs in the US West (Oregon) region:
- 100 c5.large Linux, shared tenancy
- 50 r5.4xlarge Windows, shared tenancy
- 150 r5.large Linux, shared tenancy
- 300 t4g.nano Linux, shared tenancy
With Standard RIs, you would purchase 4 RIs, one for each bullet point matching the instance size, quantity, tenancy, and operating system specified. If you wanted to do 1-Year All Upfront, you would simply specify that type of Standard RI. If instead you wanted to do 3-Year No Upfront, it’s an easy switch and you just specify a different term and payment type. Very straightforward.
How about EC2ISPs? You purchase EC2ISPs per Instance Family (i.e., c5, r5, t4g) so you could purchase 3 vs. 4, since 2 bullets are the same r5 family. Rather than specify a quantity of instances, you specify a dollar amount to cover. The key thing to understand is that Savings Plan commitments (both EC2 Instance and Compute) are made in post-discount dollars (i.e., the Savings Plan rate after the discount has been applied). For our example, you can calculate the appropriate amount of post-discount commitment as follows (you can look these up here):
You could purchase 4 EC2ISPs to match each row in the table above (with an overall commit of $83.30/hr) or you could purchase 3 by combining the two r5 purchases into a single EC2ISP totalling $77.55/hr. Either way, you specify the instance family, tenancy, operating system, and total hourly post-discount dollars of the commit.
Now, let’s say instead you want to buy a 3-Year No Upfront EC2ISP to cover the exact same set of instances. WARNING: If you buy them using the post-discount totals above and simply switch the term and pre-payment type from 1-Year All Upfront to 3-Year No Upfront, you will be overcommitted! Instead, you need to recalculate the post-discount dollar amount based on the 3-Year No Upfront numbers as follows:
For 3-Year No Upfront EC2ISPs, that means purchasing either 4 matching each row in the table above for an overall commit of $70.79/hr, or purchasing 3 EC2ISPs by combining the r5s into a single EC2ISP of $66.65/hr.
IMPORTANT: We see customers make this mistake often so we can’t stress this enough—when making Savings Plans commitments, make sure you are using the appropriate post-discount dollar amount for the specific resources and Savings Plan types you want to purchase.
For example, if you accidentally used the 1-Year All Upfront post-discount amount when making a 3-Year All Upfront commitment, you would be overcommitted by $12.51/hr. This means you’d be paying AWS ~$9,000/mo (or a total of ~$324k over 36 months) with zero benefit (assuming no other matching usage). Getting the hourly commit wrong can be a very costly mistake! This waste becomes a “headwind” that offsets your overall savings and lowers your Effective Savings Rate. In some cases, we’ve actually seen negative Effective Savings Rates which means the user would have been better off paying on-demand and making no commitment at all.
In summary, while EC2ISPs do offer the ability to make fewer purchases by combining across an instance family, the complexity of determining the correct dollar commitment amount is high and the risk of a mistake can be substantial. For complex environments with different instance sizes, operating systems, and tenancies within an instance family, that simplification is not to be discounted. However, in our opinion, the complexity and downsides of a dollar commitment don\’t outweigh the simplicity.
Advantage: Draw. We tend to think the Standard RIs are better here, but there are pros and cons for both instruments. The EC2ISP commitment is hard to calculate and creates more opportunity for error, but could also offer some simplicity.
Flexibility
With Standard RIs, you are locked into a specific instance size, tenancy, and operating system. There is one exception called Instance Size Flexibility (ISF) where AWS will automatically apply the RI if the operating system is Linux (not paid-for distributions like Red Hat, SUSE, etc.) and the instance size of the RI and EC2 instances vary within a family (e.g. a large RI will provide 50% coverage if you are running an xlarge instance).
There is no question EC2ISPs are more flexible as they allow for changes to the operating system, tenancy, and instance size (regardless of operating system) within an instance family. The key point to consider however is how valuable is that flexibility? How often do you change the tenancy and/or operating system within the same instance family? Not very often. Moreover, if you do make those changes, the discount also changes which, as we saw from above, can lead to overcommitment.
To illustrate, let’s take our previous example and say you want to swap out the 50 r5.4xlarge Windows instances for 50 r5.4xlarge Linux ones. With EC2ISPs, you get operating system flexibility, right? But look what happens. Let’s say you made a 1-year All Upfront r5 EC2ISP commit of $77.55/hr (the proper amount to cover your original r5 usage). When you switch from Windows to Linux, your post-discount value changes:
Your EC2ISP covers the new r5.4xlarge Linux usage but notice you are now overcommitted by $36.80/hr (i.e., you bought an EC2ISP for $77.55/hr and now only have post-discount usage of $40.75). This means you are paying AWS ~$26.5k/mo or $318k/yr for no benefit. That isn’t very useful flexibility.
That said, there is one case where EC2ISP flexibility really matters. If you are running Windows or a paid Linux distribution (Red Hat, SUSE, etc.) AND you frequently change instance sizes within an instance family (e.g., you scale up a 2xlarge to a 4xlarge), EC2ISPs will provide Instance Size Flexibility (ISF), where Standard RIs will not. Note if you run Linux, there is no additional benefit here since Standard RIs already provide Linux ISF.
Advantage: EC2ISPs. They are more flexible, but the flexibility is of limited value unless you run Windows or paid-for Linux distros and change instance sizes often.
Risk Mitigation
This is the biggest and most important difference! What happens if your EC2 needs change (e.g., upgrading m4s to m5s or changing from m5s to r5s) and your commitments no longer match? With EC2ISPs, you have absolutely zero recourse. Savings Plans (both Compute and EC2 Instance) are immutable commitments that can not be adjusted or disposed of in any way. That means you are stuck with your EC2ISP hourly commitment for the full 1- or 3-year term, period.
In contrast, EC2 Standard RIs have the AWS RI Marketplace where you can transfer/sell unwanted commitments to other AWS customers. To be fair, the liquidity of the market varies based on the RI type and region in question, but for reasonably common instance sizes and operating systems, we’ve generally been able to dispose of unutilized Standard RI customer commitments within days to weeks.
When we run our free savings analysis and find large amounts of unutilized commitment, it’s almost always EC2ISPs or Standard RIs. When it’s the former, there is nothing that can be done, but with Standard RIs, there are options.
Advantage: Standard RIs. No question they provide less risk.
Conclusion
Putting it all together, Standard RIs are equal to or superior to EC2ISPs for most use cases. Standard RIs offer equal savings, a less complex purchasing model, and de-risk your commit greatly since they offer an ability to be sold/transferred to another customer should your EC2 needs change. EC2ISPs do offer more flexibility, but that flexibility is of limited value (and doesn’t outweigh the de-risking benefit of Standard RIs), save the use case where you are running a non-Linux operating system and changing frequently between instance sizes. In that scenario, EC2ISPs make sense.
While ProsperOps forgoes both of these instruments in favor of an approach that delivers higher overall discounts with more commitment flexibility via Compute Savings Plans and Convertible RIs, our mission is to help users make the best cost optimization decisions based on their particular use case or future plans.
If you’d like to understand how ProsperOps can completely eliminate the tedium of discount instrument strategy and execution from your life, while automatically generating higher savings with the ability to manage risk, sign up to receive a complimentary AWS Compute Savings Analysis.
Prosper On!
