Reserved Instances and Cost Math: When They Pay Off

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 1-year term before a 3-year term unless you have strong confidence in the instance type requirements. The 3-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 data-driven starting point based on historical usage. Trust the data over intuition.

The core argument

Reserved instance decisions are a classic risk-return tradeoff. 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 over-commit (reserving instances for workloads that are too variable) or under-commit (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 1-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 re-evaluate whether the peak is predictable enough to benefit from a shorter-term reservation approach.

Common mistakes

1. Making reservation decisions based on current month usage rather than 12-month 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.

1. 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.

1. Not using partial upfront or no upfront payment for the first reservation. The maximum discount comes from all-upfront payment, but the cash-flow implication of paying for 12 months of compute upfront 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.

1. Ignoring reserved instance marketplace for unwanted reservations. AWS has a marketplace where reserved instances can be sold before the term expires. Teams that over-reserved can recover some cost by selling the unused reservation. This option is not zero friction, but it reduces the cost of over-reservation for AWS EC2 standard reserved instances.

1. Making all reservations at once. Instead of reserving 100% of baseline in January, stagger reservations so 20-25% 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

1. 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 data-driven starting point. Review the recommendations critically, particularly for any service that had unusual usage during the analysis period.

1. 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.

1. 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.

Related reading

• Reserved Instances, Savings Plans, Spot: The Saving Map
• PlanetScale vs Supabase vs Neon vs Aurora Serverless
• Per Seat vs Per Usage Pricing: Cost Implications for Buyers
• Software Costs That Founders Underestimate