On-Demand, Reserved Instances, and Savings Plans in plain terms
On-Demand is the default: you pay the published hourly rate for exactly what you run, with zero commitment and total flexibility. It is the right price for spiky, experimental, or short-lived workloads, and the wrong price for anything that runs 24×7. Cloud providers know your baseline is predictable, so they offer a discount in exchange for a commitment to keep spending.
Reserved Instances (RIs) were the original version of that bargain: commit to a specific instance family in a specific region for one or three years, and pay substantially less per hour. Standard RIs deliver the deepest discounts but are the least flexible; if you move off that family, the reservation can strand. AWS Savings Plans are the modern, more forgiving form. Compute Savings Plans let you commit to a dollar-per-hour spend level and apply that discount automatically to any EC2, Fargate, or Lambda usage, regardless of instance family, size, or region. EC2 Instance Savings Plans sit in between: family-locked to a region, but deeper discounts than the Compute variant.
How to use this as an AWS Savings Plans calculator
Enter your monthly On-Demand compute spend, then set the steady-state share to the fraction you would commit to as an hourly Savings Plans spend level; that share times your bill is the commitment the tool prices. Pick the term and payment option, and the output is the monthly and annual savings range for a Compute Savings Plan, with the uncommitted remainder shown as still On-Demand.
One translation to keep in mind: AWS states a Savings Plan as a commitment to a specified amount of compute per hour for one or three years, priced at the discounted rate, so the dollars-per-hour figure you buy in the console is smaller than your On-Demand baseline divided by 730. Take the exact number from Cost Explorer's Savings Plans recommendation, which is built from your real usage; use this page for the question that comes before it — how much of the bill is steady enough to deserve a commitment at all.
The discount ladder: term and payment option
Two levers set the discount. The first is term: a three-year commitment roughly doubles the savings of a one-year commitment. The second is payment option: no upfront (pay monthly), partial upfront, or all upfront (pay the whole commitment on day one). Each step toward more upfront cash adds a few points of discount, because the provider gets its money sooner.
The calculator above uses published Compute Savings Plans ranges as its baseline: roughly 20% to 27% for one-year plans and 45% to 55% for three-year plans, shown as a conservative-to-headline range because a mixed fleet rarely realizes the full sticker discount. EC2 Instance Savings Plans and standard RIs can push individual families to 66% to 72%, which is why single-workload commitments still have a place. To see how these discounts fit a broader cost program, read what FinOps is and our approach to AWS cost optimization.
Compute Savings Plans vs EC2 Instance Savings Plans vs Reserved Instances
Maximum discounts are AWS's own "up to" figures from the Savings Plans types documentation and the EC2 Reserved Instances pricing page; a real fleet lands well below them, which is why the calculator shows a range. Two details the headline numbers hide: Compute Savings Plans are the only option that follows a workload from EC2 to Fargate or Lambda, and both Savings Plan types cover the EC2 instances inside EKS, ECS and EMR clusters while leaving the EKS cluster fee itself undiscounted. If your commitment decision is really a Kubernetes sizing decision, start with the Kubernetes cost calculator and bring the node total back here.
The commitment-risk tradeoff
Every discount here is a bet that your future usage will look like your past usage. That bet is cheap on a one-year no-upfront plan and expensive on a three-year all-upfront plan. The failure mode is the same in both cases: you commit to a spend level, then re-architect, migrate a workload to serverless, adopt Graviton, downsize, or lose a customer, and you keep paying for a commitment you no longer use. All-upfront money is already spent; even no-upfront plans obligate you for the full term.
This is why disciplined teams commit in layers. Cover the steady-state baseline you are highly confident will persist, leave headroom for change, and add new commitments only as that floor proves stable over time. The cloud waste calculator helps size the flexible waste sitting on top of that baseline; this tool sizes the disciplined commitment underneath it.
When each option makes sense
On-Demand is correct for anything unpredictable: new services, batch jobs, dev and test environments you can switch off, and traffic you cannot forecast. Compute Savings Plans are the default first purchase for most teams, because they discount the flexible baseline of your compute without locking you to a family. Reserved Instances and EC2 Instance Savings Plans earn their keep on large, stable, single-family workloads, such as a long-running database fleet or a steady production tier, where the extra few points of discount outweigh the lost flexibility.
Most mature setups blend all three: On-Demand for the spiky top layer, Savings Plans for the broad middle, and targeted RIs for the immovable base.
Rightsize before you commit
The most expensive mistake in commitment planning is buying a discount on waste. If a third of your fleet is oversized or idle, a three-year Savings Plan just locks in that inefficiency for three years. Rightsize, delete idle resources, and consolidate first; then commit to the leaner baseline that remains. A read-only cloud bill audit establishes that baseline from your real usage, and the ongoing cloud billing and FinOps engagement keeps commitments matched to reality as your architecture evolves. Our published results carry the site-wide disclaimer on case studies.