Free Tool · No Signup, Nothing Stored

What will Reserved Instances
and Savings Plans save you?

Enter your compute spend and steady-state share, then compare every term and payment option using published AWS discount ranges. Runs entirely in your browser; nothing is sent or stored. Share the result by copying the URL.

estimate your commitment savings

A worked example for a team spending $50K/month on on-demand compute, committing the steady-state 70% on a 3-year Compute Savings Plan (no upfront):

commitment-eligible spend (70% of bill)$35K/mo
estimated monthly savings (conservative → up-to*)$11K – $16K/mo
annualized savings$134K – $189K/yr
effective discount on total compute bill22% – 32%
still on-demand / flexible (30% of bill)$15K/mo

Enable JavaScript to plug in your own spend, steady-state share, term and payment option. The interactive version runs entirely in your browser; nothing is sent or stored.

*A conservative floor up to AWS's published "up to" figure for Compute Savings Plans (~20–27% for 1-year, ~45–55% for 3-year). EC2 Instance Savings Plans and standard Reserved Instances can reach ~66–72% for a single instance family.

Directional estimate, not a quote. Actual discounts depend on instance family, region and utilization. A 3-year commitment locks you in even if you re-architect, migrate or downsize, so commit only the baseline you are confident will still exist in three years. Over-committing on a 3-year term is a real financial risk.

Model your real commitment mix in a free 30-min review →

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.

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.

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.

Commit with evidence, not optimism.

A read-only bill audit sizes your true steady-state baseline and models the exact Savings Plan and RI mix for your usage, so you commit the right amount on the right term.

last updated: 2026-07-10

What the audit covers Book the Audit →

Frequently asked questions

What is the difference between a Savings Plan and a Reserved Instance?

Both trade a 1-year or 3-year usage commitment for a lower rate than On-Demand. Reserved Instances discount a specific instance family in a region; EC2 Instance Savings Plans do the same with more flexibility; Compute Savings Plans apply the discount to any EC2, Fargate or Lambda usage regardless of family, size or region. Compute Savings Plans are the most flexible, which is why this calculator uses their published discount ranges as the baseline.

How much can I actually save with a Savings Plan?

It depends on term and payment option. Compute Savings Plans discount roughly 20% to 27% on a 1-year commitment and roughly 45% to 55% on a 3-year commitment, with all-upfront paying the most and no-upfront the least. EC2 Instance Savings Plans and standard Reserved Instances can reach 66% to 72% for specific instance families. The calculator applies these rates only to the steady-state share of your spend, because committing bursty or short-lived usage is where teams lose money.

Is a 3-year commitment worth the risk?

Only for genuinely steady-state workloads. A 3-year term roughly doubles the discount, but you are locked in even if you re-architect, migrate, downsize or move off the instance families you committed to. The safe rule is to commit only the baseline you are confident will still exist in three years, cover the rest with 1-year plans or On-Demand, and layer in new commitments as that floor proves stable. Over-committing on a 3-year term is one of the most expensive mistakes in cloud finance.

Does this calculator use my real AWS bill?

No. It runs entirely in your browser using published AWS Savings Plan discount ranges applied to the numbers you type; nothing is sent to a server or stored. Your inputs are encoded in the page URL so you can bookmark or share the result. For discounts based on your actual usage, instance families and existing commitments, a bill audit reads your real billing data.

Should I buy Savings Plans or Reserved Instances first?

Start with Compute Savings Plans for the flexible baseline of your compute, because they keep discounting even as you change instance families, and add Reserved Instances or EC2 Instance Savings Plans only for large, stable, single-family workloads where the extra few points of discount are worth the reduced flexibility. Right-size and delete idle resources before you commit, so you are not buying a discount on waste.