If your AWS compute spend is steady, paying on-demand prices for all of it is leaving a lot of money on the table. Commitment discounts, Savings Plans and Reserved Instances, can cut compute prices substantially in exchange for committing to spend for one or three years. They are also the easiest way to lock in waste: commit to capacity you later shut down, and you keep paying for it.

We manage commitments for about 180,000 USD of monthly compute. This guide explains the instruments, the two numbers that matter, and the process we use to buy without regret.

The instruments

Instrument Commits to Applies to Flexibility
Compute Savings Plan USD per hour of compute EC2 any family, size, region, OS; Fargate; Lambda Highest
EC2 Instance Savings Plan USD per hour One instance family in one region, any size and OS Medium
Standard Reserved Instance A specific instance configuration That configuration (with size flexibility for regional Linux RIs) Low; can be sold on the RI Marketplace in some cases
Convertible Reserved Instance A configuration that can be exchanged Exchangeable for equal or greater value Medium
RDS, ElastiCache, OpenSearch, Redshift reserved nodes Specific database or cache configurations That service only Low

Savings Plans do not cover RDS or other managed databases, which still use reserved instances or nodes. For EC2, Fargate and Lambda, Savings Plans have mostly replaced Reserved Instances because they adapt as you change instance types.

Discount depth increases with term (3 years versus 1) and payment option (all upfront, partial upfront, no upfront). EC2 Instance Savings Plans discount more than Compute Savings Plans in exchange for less flexibility. The exact percentages vary by instance type and region; use the AWS pricing pages or Cost Explorer recommendations for your actual usage.

Two numbers: coverage and utilisation

  • Coverage: the share of your eligible usage that is covered by commitments. Low coverage means you pay on-demand for steady usage.
  • Utilisation: the share of your commitment you actually use. Below 100 percent means you pay for commitment you do not use.

You want high utilisation always, and coverage that matches your stable baseline, not your peaks. Over-committing shows up as utilisation below 100 percent, and that money is gone. Under-committing shows up as lower coverage, and you pay on-demand prices for some steady usage. Under-committing is cheaper to fix: you can buy more next month.

Find your baseline

Look at hourly compute spend over the last 60 to 90 days, not monthly totals. The baseline is the level your usage rarely drops below, for example the 10th percentile of hourly on-demand-equivalent spend. Commit to a share of that, not the average.

Before buying, remove waste first. Right-size instances, delete idle resources, move suitable workloads to Spot. Committing before cleanup locks in the waste for one to three years.

Ladder your purchases

Instead of one big purchase, buy smaller commitments regularly, for example monthly or quarterly, each covering a slice of the baseline. Benefits:

  • Commitments expire at different times, so you are never forced into a large renewal decision at once.
  • Each purchase reflects your current usage, including recent architecture changes.
  • Mistakes are small.

Our routine: on the first business day of each month, check Cost Explorer's Savings Plans recommendations and our own baseline calculation, and buy a Compute Savings Plan covering up to a third of any uncovered baseline. Larger, stable workloads with fixed instance families get EC2 Instance Savings Plans.

Who decides, who pays

Commitments are bought centrally, usually in the management account, and apply across linked accounts. Decide how savings are shown to teams: our showback distributes the discount to the teams whose usage consumed it, so teams see effective cost, not on-demand list prices. Otherwise teams that already use committed capacity do not benefit from right-sizing, which feels backwards to them.

When not to commit

  • Workloads you plan to migrate to a different compute model within the term (for example, moving from EC2 to Lambda is covered by Compute Savings Plans; moving to another cloud is not).
  • New products without usage history.
  • Usage that is mostly Spot or scales to near zero at night; the baseline is lower than it looks.
  • Any time before a planned architecture change that will reduce compute, like a big right-sizing effort.

A worked example

Our hourly on-demand-equivalent compute spend over 90 days had a median of 310 USD per hour, a 10th percentile of 240 and peaks around 520 during batch windows. Existing Savings Plans covered 150 USD per hour. Rather than buy up to the median, we bought one-year Compute Savings Plans for 60 USD per hour, bringing commitment to 210, below the 10th percentile. Utilisation stayed at 100 percent through the following quarter, including a holiday week when traffic dropped, and coverage rose from 48 to 67 percent. Three months later, after a right-sizing project reduced the baseline, we were glad we had not committed to the median: the new 10th percentile was 225 USD per hour, still above our commitment.

Common mistakes

Mistake Why it hurts Do this instead
Committing to the average, not the baseline Utilisation drops at night and weekends Commit to a low percentile of hourly spend
Buying before cleanup Locks in waste for years Right-size and remove idle resources first
One large purchase Big renewal cliff, big mistakes Ladder small purchases monthly or quarterly
Ignoring utilisation reports Silent paid waste Alert when utilisation drops below 98 percent
Forgetting databases Savings Plans do not cover RDS Separate reserved instance plan for databases

Key takeaways

  • Compute Savings Plans are the flexible default for EC2, Fargate and Lambda.
  • Track coverage and utilisation; protect utilisation first.
  • Commit to the stable baseline, not the average.
  • Clean up before committing, and ladder purchases over time.
  • Handle databases with their own reserved instances.

References