Reserved Instances and Cost Math: When They Pay Off
Reserved instances are cloud compute commitments where you agree to use a specific instance type in a specific region for one or three years, in exchange for a discount of 30 to 70 percent compared to on demand pricing. Reserved instances transfer the utilization risk from the cloud provider to the buyer: the cloud provider offers a lower price because they have committed capacity, and the buyer pays for the capacity whether they use it or not. The break even point for reserved instances requires sustained utilization above approximately 60 percent.
What you need to know
- Reserved instances make economic sense for workloads that run continuously at utilization above 60 percent. Below this threshold, on demand pricing is cheaper.
- Commit to a one year term before a three year term unless you have strong confidence in the instance type requirements. The three year discount is larger, but the commitment risk is also larger.
- Savings Plans are more flexible than reserved instances and are often the better starting point. Switching to reserved instances provides marginally better discounts for very stable workloads.
- Reserve baseline load only. Spiky or seasonal peaks should use on demand or Spot. Reserve what you always need, not what you occasionally need.
- AWS Cost Explorer's reservation recommendations provide a starting point grounded in historical usage data. Trust the data over intuition.
The core argument
Reserved instance decisions are a classic tradeoff between risk and return. The return is a 30 to 70 percent discount on compute costs for a committed workload. The risk is paying for reserved capacity that goes unused if the workload changes. Most teams that have not run the numbers either overcommit (reserving instances for workloads that are too variable) or undercommit (leaving significant discounts on the table for stable workloads).
The math is not complex. Take a workload that runs continuously at 90% utilization on a specific instance type. The on demand price is $100 per month. The one year reserved price (all upfront) is $60 per month effective cost. At 90% utilization, the reservation saves $36 per month ($40 savings minus $4 for the 10% idle time). Over 12 months, the savings are $432. The reservation makes obvious sense.
The math changes significantly for variable workloads. A workload that runs at 90% utilization for 6 months and 20% utilization for the other 6 months has an average utilization of 55%, below the break even point. The reservation loses money compared to on demand pricing for this profile. The correct approach for this workload is: reserve at the 20% baseline level (what you always need), use on demand for the 6 month peak, and reevaluate whether the peak is predictable enough to benefit from a shorter term reservation approach.
Common mistakes
Making reservation decisions based on current month usage rather than 12 months of history. A single month of high usage creates a misleading picture. Pull 12 months of usage data before making a reservation commitment. Seasonal variation, growth trends, and incident recovery periods all affect what commitment level is appropriate.
Reserving database instances before application instances. Databases often have more stable utilization patterns than application servers (which scale with traffic), making database reservations lower risk. Many teams forget that RDS Reserved Instances provide the same discount structure as EC2 and have database workloads that are stable enough to benefit significantly.
Not using partial upfront or no upfront payment for the first reservation. The maximum discount comes from paying all upfront, but the cash flow implication of paying for 12 months of compute in one go is significant for smaller companies. Partial upfront and no upfront options have smaller discounts but better cash flow characteristics. For the first reservation in a category, use partial upfront to limit the exposure while validating the commitment level.
Ignoring the reserved instance marketplace for unwanted reservations. AWS has a marketplace where reserved instances can be sold before the term expires. Teams that reserved too much can recover some cost by selling the unused reservation. This option is not zero friction, but it reduces the cost of over reserving for AWS EC2 standard reserved instances.
Making all reservations at once. Instead of reserving 100% of baseline in January, stagger reservations so 20 to 25 percent expire each quarter. This provides flexibility to adjust commitment levels as usage patterns evolve and prevents the "all reservations expire simultaneously" renewal complexity.
Where to start
Run the Cost Explorer reservation recommendations. AWS Cost Explorer has a built in recommendations tool that analyzes your last 7, 30, or 60 days of usage and recommends specific reserved instance purchases with estimated savings. This is a starting point grounded in data. Review the recommendations critically, particularly for any service that had unusual usage during the analysis period.
Start with RDS if you have a stable database workload. Database workloads are typically more stable than application workloads and often represent significant monthly spend. A reserved RDS instance for a database that has been running continuously for months is a low risk first reservation. Calculate the monthly savings, the break even utilization, and the risk if the instance is no longer needed before committing.
Set a monthly reservation utilization review. Add a monthly calendar reminder to review reservation utilization in Cost Explorer. Reservations with utilization below 70% need attention: either the workload changed, the reservation was too large, or the instance type no longer matches the deployment. Catching underutilization early limits the cost of suboptimal reservations.
- Software Costs That Founders Underestimate
FAQ
Frequently asked
- What is the discount for reserved instances versus on demand?
- How do you calculate the break even utilization for a reserved instance?
- What is a Savings Plan and how is it different from a reserved instance?
- What is reserved instance convertibility and when should you use it?
- What is the risk of over reserving and how do you mitigate it?
Author
My approach to this kind of work
I approach this kind of work the way I would want someone to approach a system I depended on. With care, with rigor, with a sense that the next person who touches it should be able to understand it without my help. Yashveer Singh, founder of Yashveer Labs. That is the standard. If it is the standard you are looking for, I am the engineer to hire.