Reserved Instances, Savings Plans, Spot: The Saving Map

What you need to know

• Compute Savings Plans are the most flexible AWS cost reduction mechanism and the right starting point for most teams. They apply across EC2, Fargate, and Lambda without workload-specific commitment.
• Reserved Instances are slightly more economical than Savings Plans for perfectly stable, unchanging workloads. They are worth considering after Savings Plans are established.
• Spot Instances provide the highest savings (up to 90%) but require interruption-tolerant workload design. Do not put production web servers on Spot without interruption handling.
• The layered approach (Savings Plans for baseline, on-demand for variation, Spot for batch) is the cost-optimal architecture for most teams.
• Measure utilization before committing. Under-utilized commitments cost more than no commitment.

The core argument

Most teams approach cloud cost optimization reactively: the bill is high, someone looks at the cost breakdown, and they buy some reserved instances for the biggest line items. This works but leaves significant savings on the table because it does not account for the different optimization mechanisms available for different workload types.

The right approach is to categorize every workload by its utilization pattern and interruption tolerance, then apply the appropriate cost reduction mechanism to each category. Stable workloads with defined instance requirements belong on Reserved Instances or Savings Plans. Variable workloads that scale unpredictably benefit from Savings Plans' flexibility over Reserved Instances' rigidity. Batch jobs, CI/CD runners, and ML training workloads belong on Spot because they can be designed to tolerate interruption and the 60 to 90 percent cost reduction is significant for compute-intensive work.

The layered strategy is the full picture. Savings Plans cover the baseline compute commitment with a discount applied automatically to whatever compute types you are using. On-demand handles the variation above baseline, which occurs unpredictably and does not merit a commitment. Spot handles workloads that can be interrupted, run offline, or can restart from checkpoints. The combination typically reduces the overall compute bill by 40 to 60 percent compared to all-on-demand, depending on workload profile and commitment level.

Common mistakes

1. Putting stateful or customer-facing workloads on Spot without interruption handling. Web servers that are terminated mid-request lose in-flight traffic. Databases that are terminated lose uncommitted transactions. If a workload must handle an interruption gracefully (complete in-progress work, drain connections), that handling must be implemented before the workload moves to Spot.

1. Buying Reserved Instances for workloads that are going to change. A Reserved Instance for a specific instance type that gets superseded by a newer generation leaves you locked into the old instance type for the rest of the term (or paying to convert to the new type). For workloads that are likely to scale up or change instance families, Savings Plans or Convertible Reserved Instances accommodate the change without waste.

1. Not setting up Spot instance interruption handling in the auto-scaling group. AWS provides a 2-minute interruption notice via instance metadata and EventBridge. Not handling this notice means the instance is terminated without graceful shutdown. Configure the auto-scaling group's lifecycle hooks to respond to the interruption notice with graceful shutdown and replacement instance launch.

1. Using Savings Plans without understanding the commitment duration implications. A 3-year Savings Plan commitment made at current compute spending levels assumes the spending level will remain stable or increase for three years. If the application is retired or significantly scaled down, the Savings Plan continues billing at the committed rate. Start with 1-year commitments before extending to 3-year.

1. Overlooking RDS and ElastiCache for reservation. Database and cache workloads are often the most stable compute workloads (they do not scale out automatically in response to traffic) and are often significant line items in the cloud bill. RDS Reserved Instances and ElastiCache Reserved Nodes provide the same discount structure as EC2 and are often easier to commit to because the utilization is very stable.

Where to start

1. Analyze the last 3 months of AWS compute spend by service and instance type. Use AWS Cost Explorer grouped by service and instance type to identify the largest cost drivers. Workloads that appear consistently in the top 5 cost items across all three months are candidates for reservation. Workloads that only appear in some months are more variable and require more careful analysis.

1. Start with a Compute Savings Plan at 50-70% of average hourly compute spend. This provides a meaningful discount on the baseline load without over-committing. The Savings Plan discount is applied automatically to the cheapest eligible usage, so it benefits multiple services simultaneously without requiring instance-specific reservations.

1. Identify one batch workload to move to Spot. Choose a workload that is currently running on on-demand, can be restarted without data loss (CI/CD builds, data pipeline jobs, image processing), and runs regularly. Move it to Spot with a fallback on-demand instance type in the same auto-scaling group. Measure the cost reduction and the interruption frequency to validate the pattern before expanding Spot usage.

Related reading

• Reserved Instances and Cost Math: When They Pay Off
• Render vs Fly.io vs Railway vs Heroku in 2026
• Observability in 2026: Metrics, Logs, Traces
• Software Costs That Founders Underestimate