Size an AWS Savings Plan hourly commitment, then see covered spend, on-demand overflow, waste and net monthly saving.
A Savings Plan applies discounted rates to usage until your hourly dollar commitment is exhausted, and everything above it falls back to on-demand. Because usage is consumed at the discounted rate, an hourly commitment buys roughly commitment ÷ (1 − discount) worth of on-demand-equivalent usage — and any commitment you do not consume in an hour is simply lost, which is why utilisation matters as much as coverage. Commitments are billed hour by hour and unused dollars never roll over, so over-committing turns a discount into a surcharge; sizing to your steady-state trough is the standard safe play.
Savings Plan
discounted need = on-demand spend × (1 − discount); covered = min(commitment, discounted need); overflow at on-demand = (discounted need − covered) ÷ (1 − discount).
discounted need = on-demand spend × (1 − discount); covered = min(commitment, discounted need); overflow at on-demand = (discounted need − covered) ÷ (1 − discount). A Savings Plan applies discounted rates to usage until your hourly dollar commitment is exhausted, and everything above it falls back to on-demand. Because usage is consumed at the discounted rate, an hourly commitment buys roughly commitment ÷ (1 − discount) worth of on-demand-equivalent usage — and any commitment you do not consume in an hour is simply lost, which is why utilisation matters as much as coverage.
Commitments are billed hour by hour and unused dollars never roll over, so over-committing turns a discount into a surcharge; sizing to your steady-state trough is the standard safe play.
This calculator takes 5 inputs: Hourly commitment, On-demand equivalent spend per hour, Savings Plan discount vs on-demand, Hours in the billing month, Plan type. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
No. Coverage and utilisation pull against each other: commit to your trough of steady usage and let spiky or short-lived capacity run on-demand or on Spot. Most FinOps teams target high utilisation (near 100%) and accept coverage somewhere in the 70–85% range.