Savings Plans and reserved-instance coverage, measured separately
- Savings Plans coverage and utilizationshare of eligible SPEND
- Reserved instance coverage and utilizationshare of eligible HOURS
- Expiry cliffsscheduled cost increases
- Sized purchase recommendationsone per instrument
Coverage versus utilization: two questions, not one
Coverage asks how much of your eligible usage a commitment applies to. Utilization asks how much of the commitment you bought is being consumed. Low coverage means you are paying On-Demand for steady work; low utilization means you are paying for hours or dollars of commitment that nothing uses. They point at opposite remedies, and a tool that reports one number for both has hidden one of them.
Kostrix reads both from AWS Cost Explorer's own coverage and utilization reports rather than estimating them from instance inventories, because that is the figure your bill is settled on. Those requests are charged by AWS at its published per-request rate, which is why the coverage picture is refreshed once a day and cached, and why the Terms of Service say so plainly.
share of eligible HOURS · denominator 18,240 eligible instance-hours
share of eligible SPEND · denominator 12,880.00 USD of eligible spend
blended coverage 52.2% never printed
Savings Plans are bought in dollars, reservations in hours
A Compute Savings Plan is a commitment to spend so many dollars an hour; Cost Explorer reports its coverage as a share of Savings-Plan-eligible spend. A reservation is a commitment to run an instance for so many hours; coverage is a share of reservation-eligible hours. The two have different numerators, different denominators and different sets of services.
Savings Plans coverage and utilization
share of eligible SPEND- How much of your Savings-Plan-eligible compute and database spend over the trailing thirty days is already covered, how much is still paying On-Demand, and how much of what you have committed to is actually being used. Spend, never a blended percentage, because a Savings Plan is bought in dollars per hour.
Reserved instance coverage and utilization
share of eligible HOURS- The same two questions for reservations across EC2, RDS, ElastiCache, Redshift, OpenSearch and MemoryDB - measured in hours, because that is the unit reservations are bought in, and reported separately from Savings Plans because the remedy is a different purchase.
Expiry cliffs
scheduled cost increases- Reservations and Savings Plans whose term ends while the workload they cover is still running. This is a forecastable increase in next month's bill, not a saving, and it is deliberately kept out of the savings total.
Sized purchase recommendations
one per instrument- A Compute Savings Plan for SP-eligible compute and a Reserved Instance recommendation for RDS and Redshift, each sized at 80 percent of the uncovered amount so a quiet week does not leave you holding hours you never use.
Blending the two into one percentage produces a figure that measures nothing. An earlier build of this product added the two in one place and averaged them in another, and quoted 27% and 54.6% coverage for the same account on the same afternoon; that is the defect this design exists to rule out. Kostrix prints each coverage figure with its denominator beside it and never prints an average of the two. Reservation coverage is also reported per service, because a reservation is bought against RDS or Redshift or ElastiCache, not against the account.
Sizing a purchase from the gap, at 80 percent of it
Eligible spend minus covered spend is the On-Demand money a commitment would apply to. Kostrix recommends committing to 80 percent of it, not all of it: a commitment sized to everything running today buys hours that a quiet week would not have used, and an unused commitment is the waste this analysis exists to prevent.
The recommendation comes as one finding per instrument, because they are separate purchases made in separate consoles with different discount curves: a Compute Savings Plan for Savings-Plan-eligible compute (EC2, Fargate and Lambda), and a Reserved Instance recommendation for RDS. Each is stated as an hourly commitment and a monthly amount, with the estimated saving computed from the published 1-year no-upfront discount as an approximation, and the 3-year alternative beside it. Because those rates are list deltas rather than a quote for your account, the finding is held at medium confidence and says so. A gap under 50 dollars a month is not reported at all.
| Savings-Plan-eligible compute, trailing 30 days | 12,880.00 USD |
|---|---|
| Already covered by Savings Plans | 41.9% of eligible spend |
| Uncovered On-Demand | 7,483 USD |
| Commitment sized at 80% of uncovered | 5,986 USD / month |
12,880.00 x (1 - 0.419) = 7,483 USD uncovered
7,483 x 0.80 = 5,986 USD / month to commit
A term ending is a cost increase, not a saving
A Savings Plan or reservation whose term ends while the workload it covers is still running puts that workload back on On-Demand rates the next day. Kostrix lists every such term inside its horizon, 45 days for EC2 reservations and 60 for Savings Plans and the other reservation types, as the scheduled increase in next month's bill that it is.
It is deliberately kept out of the savings total and never summed with a cliff on the other instrument, because the remedy for each is a different purchase. Low utilization of an existing commitment is reported the same way: as commitment you are paying for and not using, which is a reason to buy less next time rather than a saving to claim now.
What Kostrix does not do
Coverage is one of the two halves. The other, the idle and unattached resources the named checks find, is on idle AWS resources and unused EBS volumes; how the two are reconciled against the bill is on how it works.