- Newest
- Most votes
- Most comments
Reserved instances are pretty painful to administer so I'd say definitely use savings plans wherever possible. We found the decisions around renewals created too many obstacles and hence delays, so savings opportunities were lost. Have a look at this article for a pragmatic discussion of savings plans versus reservations - https://www.linkedin.com/pulse/aws-savings-plans-reservations-perils-over-optimising-steve-kinsman/
Compute Savings Plans are a flexible pricing model that offers low prices, just like Amazon EC2 Reserved Instances (RI), but with added flexibility. With Savings Plans, you can reduce your bill by committing to a consistent amount of compute usage (measured in $/hour), instead of specific instance configurations. Savings Plans give you the flexibility to use the compute option that best suits your needs at low prices, without having to perform exchanges or modifications.
Here is a good comparison
https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
Some scenarios when RI is fit
- Plan to use them throughout the contract period, or at least 75% of the time.
- Use applications that require constant, "always-on" power for the better part of one to three years at a time.
- Need to extend discounted instances for databases (Amazon RDS) and compute (Amazon EC2) uses.
- You have a reasonably consistent usage pattern over an extended period.
Based on what you explained in scenario on Questions seem fall in these criteria.
Thank you. You are saying that a set of reserved instances would be better than a Savings Plan?
Relevant content
- Accepted Answerasked 9 months ago
- asked 8 months ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
Interesting, and very helpful. I've created a spreadsheet to compare On Demand with different reserved or savings options:
$283.83 - On Demand $176.4 - RI 1 Yr no upfront $159.85 - RI 1yr all upfront $122.4 - RI 3 yr no up front $106.56 - RI 3 yr all up front $178.47 - SP 1 Yr no up front $177.35 - SP 1 Yr all up front (glitch in the calculator? almost the same as no up front) $136.51 - SP 3 Yr no up front $109.5 - SP 3 Yr all upfront
This makes the differences in price very clear. What about the difference in risk? I understand that SPs are more flexible if I need to change, say, a t2.medium to a t2.large, but how to calculate the cost of that? The difference between t2.large on demand and t2.medium SP? And for RIs, the risk is related to instance type... If I need to go t2.large from t2.medium, the best I can hope for is to sell the unused RI in marketplace? In either case, what happens if I upgrade from t2 instances to t3 instances?
Changing instance size is OK even for RIs with non-licensed OSs; SPs add the ability to do it with licensed OSs like Windows too. Instance family is a problem though for both Standard RIs and EC2 Instance SPs. That's why I recommended in that article to go with the max flexibility of a Compute SP, which then frees you up to commit to 3 years and get good savings that way with the least possible risk. The amount of risk depends on how quickly your architecture tends to change. Also don't underestimate the ongoing burden of micro-managing Standard RIs and up-front payments; this consumes limited time that could be spent on security uplift so introduces risk too.