Managing AWS Compute Savings Plans: Elasticity, Seasonality, and Planned Waste

Published October 17, 2026

Aiming for 100% Savings Plan utilization costs you money. In the model on this page, a commitment sized so that nothing goes unused saves $2,062 a week. One sized to leave about 11% unused saves $3,143.

Cost Explorer shows 91% utilization and someone in finance asks why 9% of the commitment went to waste. Sometimes the right answer is that the 9% was the plan working.

Compute Savings Plans don’t bill against a monthly pool. You commit to a fixed number of dollars every hour for one or three years, and unused commitment at 03:00 on Sunday doesn’t roll over to cover the spike at 14:00 on Wednesday.

Real traffic rises and falls. Size the commitment to your lowest Sunday-night trough and you leave 60% or more of your weekday business hours at full On-Demand rates. Saving the most money means sizing above the floor and accepting some idle commitment on nights and weekends, because the weekday discount is bigger than the off-peak waste.

A week has 168 hours, and demand uses them unevenly

Consider a typical business application running on EC2, ECS, or EKS:

• Monday through Friday: Traffic climbs starting around 07:00, plateaus during business hours, peaks around midday, and tapers off into the evening. Autoscaling groups expand and contract to match.
• Nights: Traffic falls back to an idle baseline, punctuated only by scheduled maintenance or batch queues.
• Weekends: Activity drops to a fraction of weekday daytime volume.

If you calculate the average hourly spend across the week, say $90/hr, you might be tempted to commit to that average. But an elastic fleet rarely runs at its average. It oscillates between a floor of $40/hr on Sunday night and a peak of $205/hr on Wednesday afternoon.

Committing to the $90/hr average means burning $50 of unused commitment every single hour of the weekend ($50 × 48 hours = $2,400 wasted each weekend), while still paying full On-Demand rates for every dollar above $90 on weekdays.

Simulating the weekly cycle

Below is a simulated 168-hour week (Monday 00:00 through Sunday 23:59) for an elastic cluster. The fleet swings between a quiet weekend floor of $40/hr (On-Demand equivalent) and weekday peaks around $205/hr, totaling $14,747 in pure On-Demand spend over the week.

The chart models a 3-year Compute Savings Plan with a 45% discount. At that rate, $1.00 of hourly commitment covers $1.82 of On-Demand usage.

Zero waste saves $2,062 a week. Some waste saves $3,143.

Try the presets on the chart. They show why “zero waste” is a financial trap:

1. The Zero-Waste Floor ($15/hr commitment). This commitment covers up to $27.27/hr of On-Demand usage. Because the application never drops below $40/hr, utilization is 100%. Waste is $0.

   • Commitment paid: $2,520/week
   • On-Demand paid: $10,166/week
   • Net saved: $2,062/week (14% off On-Demand)
   • The team celebrates 100% utilization, but leaves thousands of dollars of weekday volume exposed to On-Demand rates.

2. The Optimal Sweet Spot ($30/hr commitment). This commitment covers up to $54.55/hr of On-Demand usage. Over nights and weekends, demand dips below $54.55, generating $539/week in unutilized commitment. Plan utilization drops to 89.3%.

   • Commitment paid: $5,040/week
   • On-Demand paid: $6,564/week
   • Net saved: $3,143/week (21.3% off On-Demand)
   • Despite $539 in visible waste, the company pockets an extra $1,081 in net cash every week ($56,200/year) compared to the zero-waste strategy. The weekday savings easily swallow the weekend waste.

3. The Aggressive Over-Commitment ($85/hr commitment). Trying to cover peak demand pushes the commitment line too high. The plan covers up to $154.55/hr, but on weekends and nights, $60 to $100/hr of commitment sits idle.

   • Commitment paid: $14,280/week
   • On-Demand paid: $1,012/week
   • Waste: $6,732/week
   • Net saved: -$545/week (a net loss)
   • Here, the waste exceeds the total discount earned during weekday peaks. The company spends more money holding the Savings Plan than if it had done nothing and paid full On-Demand rates.

A commitment dollar breaks even at utilization of 1 minus the discount

To know whether an additional dollar of hourly commitment is worth buying, calculate its break-even utilization.

Let D be your plan’s discount percentage (e.g. 45% = 0.45).

• When a commitment dollar is used, it buys 1 ÷ (1 − D) of On-Demand compute for $1.00. The dollar saved is:

  Savings per used dollar = D ÷ (1 − D)

  At a 45% discount, each used dollar yields $0.818 in savings ($1.818 − $1.000).

• When a commitment dollar is unused, you pay $1.00 and get $0.00. The dollar lost is $1.00.

An additional dollar of commitment breaks even across a period when the savings during active hours equal the waste during idle hours:

Hours Used × (D ÷ (1 − D)) = Hours Unused × $1.00

Since Hours Unused = Total Hours − Hours Used, substituting and rearranging gives the break-even utilization rate:

Break-Even Utilization = 1 − D

In practice:

• For a 3-year Compute Plan (45% discount): A dollar of commitment needs to be absorbed for only 55% of the week (92 out of 168 hours) to beat On-Demand pricing. If your application runs elevated traffic for 18 hours a day Monday through Friday (90 hours), that tranche is right at break-even. Any tranche utilized more than 92 hours a week is pure profit.
• For an EC2 Instance Plan (66% discount): You only need 34% utilization (57 hours out of 168). You can leave that commitment idle for the remaining 111 hours of the week, which is all weekend and every night, and still come out ahead of On-Demand.
• For a 1-year Compute Plan (28% discount): The margin is tight. You need 72% utilization (121 hours out of 168). Low-discount commitments cannot tolerate weekend waste; they must be confined to baseline usage.

Your workload’s shape sets the right commitment

No single rule of thumb (“cover 80% of compute”) works across architectures. Here are three common profiles:

1. The flat core (databases, message brokers, caching)

Clusters running Kafka, Elasticsearch/OpenSearch, RDS, or persistent queue workers rarely scale down on weekends.

• Elasticity ratio (Peak to Trough): 1.1 : 1
• Strategy: Commit up to 90–95% of peak. Because demand is steady, break-even utilization is easily met 168 hours a week. A high-discount 3-year commitment gives maximum return here.

2. The B2B SaaS application (business-hours traffic)

API gateways and microservices serving corporate customers during the workday.

• Elasticity ratio: 3:1 to 5:1
• Strategy: Commit to the floor plus roughly 20–30% of the weekday peak. Target 85–90% overall utilization. Let the sharp midday peaks spill to On-Demand (or Spot instances if stateless). Do not attempt to cover the top 40% of the humps with Savings Plans.

3. Development and staging environments

Sandbox accounts configured with auto-stop scripts that turn off instances at 19:00 on weekdays and all weekend.

• Elasticity ratio: Infinite (drops to zero).
• Active hours: ~50 hours out of 168 (30% utilization).
• Strategy: Unless you hold a 3-year EC2 Instance plan with discounts exceeding 70%, dedicated Savings Plans on dev accounts will lose money. Cover dev clusters with excess commitment shared from production accounts, or leave them On-Demand with aggressive scheduled shutdown scripts.

How to size a commitment, step by step

Work through these steps before you buy, instead of clicking the single recommendation button in AWS Cost Explorer.

1. Export hourly data, not daily totals

Cost Explorer defaults to daily or monthly granularity. Daily averages hide the swing between day and night. Export hourly usage from your AWS Cost and Usage Report (CUR) or Cost Explorer API for the past 30 to 90 days.

2. Plot the hourly duration curve

Take all 720 hours of a month and sort them from highest spend to lowest spend. The resulting downward slope shows how many hours each incremental dollar of compute was alive.

• Find the spend level where hours alive drop below your break-even threshold (e.g. 55% of hours, or ~396 hours/month for a 45% discount).
• That dollar level is your mathematical commitment ceiling.

3. Layer your commitments

Instead of buying one massive 3-year Compute Plan, stack commitments into tranches:

Compute Spend ($/hr)
  ▲
  │   [ On-Demand / Spot ]         Top 25% (spikes, bursts, unpredictable growth)
  ├─────────────────────────────
  │   [ 1-Year Compute Plan ]      Middle 25% (weekday daytime volume, medium flexibility)
  ├─────────────────────────────
  │   [ 3-Year Instance/Compute ]  Bottom 50% (unshakable baseline, maximum discount)
  └─────────────────────────────► Time (Hours)

• Baseline floor: Cover with a 3-year commitment for maximum discount. Even during the quietest hour of the year, this tranche is 100% utilized.
• Daytime band: Cover with a 1-year Compute Savings Plan. Gives flexibility to adjust every 12 months as services evolve.
• Peak crests: Leave on On-Demand or Spot. The utilization on these peaks is too low to ever break even on a commitment.

4. Check application changes before signing

A Savings Plan commitment is fixed in plan dollars. If you migrate your cluster to newer instances or to Graviton, your plan-rate cost per workload drops:

• Moving from an Intel m6i.xlarge ($0.1920/hr) to a Graviton m7g.xlarge ($0.1632/hr) drops compute cost by 15%.
• If your old fleet was absorbing $100/hr of commitment, the new fleet may absorb only $85/hr, turning $15/hr into permanent waste.
• Review instance specs on the instance explorer and compare family rates in the Graviton vs. x86 guide before purchasing commitments.

5. Account for the application ranking order

AWS applies Savings Plans each hour by ranking usage from highest discount percentage to lowest. If your commitment runs short during peak hours, your highest-discount instances are covered first, while lower-discount lines spill to On-Demand. For the exact worked math and queue order, see how Compute Savings Plans are applied.

Bottom line: size each tranche of commitment by how many hours a week it will be used, not by whether it will ever sit idle. A tranche used for more than the break-even share of the week earns its place, and one used for less loses money.

Next steps

• Explore instance pricing → to check On-Demand and Savings Plan base rates across instance sizes
• Graviton vs. x86 pricing → to evaluate whether architecture migrations should precede commitment purchases
• How Compute Savings Plans are applied → for the step-by-step queue ranking mechanics
• Compare region pricing spreads → to verify regional price differences before committing multi-year budgets