When the AWS bill starts to weigh on the income statement, the first question from both technology and finance is the same: how do we pay less for the same capacity? AWS offers several pricing models on compute, and choosing the wrong one —or choosing none and staying on On-Demand— translates directly into money leaving every month for no reason.
This guide compares the four models that define AWS compute spend —On-Demand, Savings Plans, Reserved Instances and Spot— with decision criteria for technology and finance leaders, not just architects.
The four models, in one line
- On-Demand is the list price: you pay for what you use, per second or per hour, with no commitment. Maximum flexibility, minimum discount. It is the starting point and the benchmark against which all the others are measured.
- Savings Plans are an hourly spend commitment (in dollars per hour) over one or three years in exchange for a discount. They do not reserve capacity: they are a billing model that applies automatically to your eligible consumption.
- Reserved Instances (RI) are a commitment to use an instance configuration over one or three years. They provide a discount and, in their zonal form, can reserve capacity in a specific Availability Zone.
- Spot Instances use spare AWS capacity at the largest discount in the catalog, in exchange for AWS being able to reclaim it with a two-minute warning.
The difference between them is not which one “saves more” on a table, but how much commitment and how much interruption your workload tolerates. That is the real axis of the decision.
How much each one saves (official AWS figures)
The maximum discounts AWS publishes against the On-Demand price are concrete and worth having clear before deciding:
- EC2 Instance Savings Plans: up to 72%, in exchange for committing to an instance family in a region.
- Compute Savings Plans: up to 66%, with maximum flexibility (they apply to EC2, Fargate and Lambda across any region, family, size, operating system or tenancy).
- Standard Reserved Instances: up to 72%, the largest discount among Reserved, for steady-state usage.
- Convertible Reserved Instances: up to 66%, a lower discount in exchange for the ability to exchange them for others with different attributes.
- Spot Instances: up to 90%, the most aggressive discount, on interruptible capacity.
The pattern is clear: the more flexibility, the smaller the discount; the more commitment or the more interruption tolerance, the greater the saving.
The criteria that really decide
1. How predictable your consumption is
This is the criterion that tilts the balance the most. If you have a compute base running 24 hours steadily —the core of a production platform, databases, business services—, that consumption is a natural candidate for a one- or three-year commitment. Committing the steady base with Savings Plans or Reserved Instances captures the discount with no risk, because you were going to consume that capacity anyway.
What you should not commit is unpredictable consumption: ephemeral test environments, campaign peaks, new workloads whose size you do not yet know. There, On-Demand and Spot fit better, and the commitment comes later, once the pattern stabilizes.
2. How much flexibility you need to keep
This is where Savings Plans gained ground on Reserved Instances. Compute Savings Plans apply on their own to whatever you consume —if you change family, region or migrate from EC2 to Fargate or Lambda— with no manual management. It is the model that best tolerates an architecture that is going to evolve.
Reserved Instances are more rigid: the Standard one ties you to a family (though you can adjust zone or size within it), and to change family you need the Convertible, which gives a smaller discount. The advantage Reserved keep is zonal capacity reservation: if you need a guarantee that an instance will be available in a specific zone —a typical requirement of a disaster recovery plan— that guarantee only comes from a zonal RI, not from a Savings Plan.
3. How much interruption the workload tolerates
Spot Instances are the biggest savings lever on AWS —up to 90%—, but they only work if the workload can survive AWS reclaiming the instance with a two-minute warning. They fit very well in batch processing, CI/CD pipelines, analytics and model training, and stateless containers orchestrated on Kubernetes or ECS, where the orchestrator simply replaces the lost node.
What should not run on Spot is anything that cannot restart cleanly: production databases, stateful servers, or services whose interruption has a direct business cost. The rule is simple: Spot for what can be retried, not for what must be guaranteed.
4. How you want to pay the commitment
Both Savings Plans and Reserved Instances offer three payment options: all upfront, partial upfront and no upfront. Paying more upfront increases the discount; paying nothing upfront reduces it but protects cash flow. It is a financial decision as much as a technical one, and it is best made with finance, not just architecture — especially given that AWS billing is done in US dollars.
The decision table
| Criterion | On-Demand | Savings Plans | Reserved Instances | Spot |
|---|---|---|---|---|
| Maximum discount | 0% (benchmark) | Up to 72% | Up to 72% | Up to 90% |
| Commitment | None | 1 or 3 years | 1 or 3 years | None |
| Flexibility | Maximum | High (Compute) | Medium | High, but interruptible |
| Capacity reservation | No | No | Yes (zonal) | No |
| Interruption risk | None | None | None | High (2-min warning) |
| Ideal workload | Unpredictable, testing | Steady base | Steady base with guaranteed capacity | Fault-tolerant, batch |
When each one makes sense
Stay on On-Demand for new workloads whose pattern you do not yet know, ephemeral test environments and unpredictable peaks. It is the base on which you later decide the commitment.
Choose Savings Plans to cover your steady consumption with the most flexibility: Compute Savings Plans when the architecture is going to evolve or mixes EC2, Fargate and Lambda; EC2 Instance Savings Plans when the family is fixed and you want the maximum discount.
Choose Reserved Instances when, beyond the discount, you need to reserve capacity in a specific zone, or when the Convertible gives you the exchange flexibility your three-year plan requires.
Choose Spot for everything that tolerates interruption: batch processing, CI/CD, analytics, training and stateless containers. It is where the biggest saving is, if the workload allows it.
And most important: it is not an exclusive choice. An optimized architecture combines all four —Savings Plans or Reserved for the base, Spot for the interruptible, On-Demand for the unpredictable— and adjusts the mix as real consumption becomes known.
How we approach it at Caleidos
At Caleidos, as an AWS Advanced Tier Services Partner, this decision is part of our FinOps and cost optimization practice: we do not start by committing, we start by measuring. We analyze the real consumption pattern, separate the steady base from the unpredictable peak, size the commitment so you do not overpay, and move interruption-tolerant workloads to Spot with the orchestration that makes them safe. The result is a smaller bill with the same workload intact, and cost dashboards that finance understands. If you want to understand the discipline behind this first, we explain it in what is FinOps.
Is your AWS bill growing faster than your business?
Let’s talk about your case: in 30 minutes we give you a concrete read on which part of your consumption is worth committing, which workloads can move to Spot, and how much saving is on the table without touching your architecture.
