See exactly how much a 1-year or 3-year commitment saves vs paying on-demand โ and which Savings Plan type fits your workload.
Enter your monthly spend above to see a recommendation.
| Feature | On-Demand | 1-Year SP | 3-Year SP |
|---|---|---|---|
| Commitment required | None | 1 year | 3 years |
| Discount vs On-Demand | โ | โ | โ |
| Flexibility to change | Full | Limited | Locked in |
| Works with scheduling? | Yes | Yes โ pays for itself faster | Yes โ pays for itself faster |
| Best for | Variable / unpredictable workloads | Stable workloads, some flexibility needed | Long-term stable production workloads |
Savings Plans give you a discount on the hours you commit to. Scheduling your non-production instances off during nights and weekends reduces the hours you need to commit to โ which means a smaller commitment cost and the same workload covered. Teams typically save an additional 40-60% on top of their Savings Plan discount by scheduling dev/staging environments off outside business hours.
Try ServerScheduler free โAWS Savings Plans offer discounts of up to 72% off on-demand pricing in exchange for a one- or three-year hourly spend commitment. The discount sounds compelling, but the right commitment size isn't always obvious. The calculator above models your break-even point and projected savings so you can make the decision with numbers rather than intuition.
AWS Savings Plans are a flexible pricing model that applies discounts automatically to your compute usage in exchange for a commitment to a minimum dollar-per-hour spend over one or three years. Unlike Reserved Instances, which are tied to a specific instance type and region, Savings Plans apply automatically to any eligible compute usage within the plan scope.
The commitment is expressed as an hourly dollar amount โ for example, committing to $1.00/hour under a Compute Savings Plan means you're agreeing to pay at least $8,760 per year ($1.00 ร 8,760 hours). In return, any compute usage up to that threshold is billed at the discounted rate. Usage above the threshold is billed at on-demand rates.
Savings Plans don't require you to specify instance types in advance, but they do require you to forecast your baseline usage accurately. Overcommitting means paying for capacity you don't use. Undercommitting means leaving discount opportunities on the table.
There are two main Savings Plans variants relevant to EC2 workloads. Compute Savings Plans offer up to 66% savings and apply to EC2, Fargate, and Lambda usage across all instance families, sizes, and regions. They're the most flexible option and the right choice if you expect your instance mix to change over the plan term.
EC2 Instance Savings Plans offer up to 72% savings but are locked to a specific instance family in a specific region. They provide the highest discount but require more confidence in your long-term usage pattern. If you know you'll be running m5 instances in us-east-1 for the next three years, an EC2 Instance Savings Plan maximises your discount.
| Plan Type | Max Discount | Applies To | Flexibility |
|---|---|---|---|
| Compute Savings Plan | Up to 66% | EC2, Fargate, Lambda | Any family, size, region |
| EC2 Instance Savings Plan | Up to 72% | EC2 only | Specific family and region |
| On-demand (baseline) | 0% | All compute | Maximum flexibility |
To get an accurate result from the calculator, you need your current monthly on-demand compute spend and an estimate of what percentage of that spend represents stable, predictable baseline usage. The baseline is the portion of your compute that runs consistently โ production workloads, persistent services, always-on infrastructure.
Do not include non-production instances that you're scheduling to stop during off-hours in your baseline calculation. Those instances only run for a fraction of each month, and their effective hourly spend is much lower than their nominal on-demand rate. Including them overstates your commitment level and may lead you to commit more than you'll actually use.
If you use instance scheduling to stop dev and staging environments overnight and on weekends, those instances run for roughly 35% of the month. Commit only against the compute that runs consistently โ typically your production workloads.
Savings Plans make sense when your production compute baseline is stable and you have confidence it won't drop significantly over the commitment term. The one-year plan is a lower-risk entry point โ the discount is smaller (typically 30 to 45% vs on-demand depending on instance type), but you're only locked in for twelve months, which reduces the risk if your architecture changes.
The three-year plan maximises discount but requires confidence in your longer-term usage. It's most appropriate for mature production workloads running on established instance families where significant architectural change is unlikely. For accounts still actively optimising their infrastructure, the one-year plan preserves more flexibility. The Savings Plans recommendations in ServerScheduler show your current coverage and specific commit suggestions based on your actual usage data.
Savings Plans and instance scheduling work well together because they target different layers of your AWS bill. Savings Plans apply to production workloads that run continuously, reducing the hourly rate. Instance scheduling applies to non-production workloads, reducing the number of hours they run. The two strategies don't compete โ they address separate cost pools.
A common approach is to implement scheduling first (it's immediate and requires no commitment), capture those savings, then use the resulting stable production baseline spend to right-size your Savings Plans commitment. Use the Cost Savings Calculator to model scheduling savings and this tool to model commitment savings, then add the two figures to understand your total optimisation opportunity.
See your current coverage and get specific commit recommendations.
EC2 Right-SizingReduce instance sizes before committing to Savings Plans.
Cost Savings CalculatorModel scheduling savings on your non-production infrastructure.
Total Cost of OwnershipHow to think about the full cost of your AWS infrastructure.