AWS Reserved Instance coverage measures how much of your eligible usage is covered by a commitment, while utilization measures how much of the commitment you bought is actually being used. Coverage answers "how much of my bill am I getting the discount on", and utilization answers "am I wasting any of the discount I paid for". They trade off against each other: push coverage too high and you risk buying commitments you cannot fully use, dropping utilization; keep utilization at a safe 100 percent by under-buying and you leave coverage, and therefore savings, on the table. Reading both together is what separates a healthy commitment portfolio from an expensive one.
This explainer sits under our complete guide to AWS cost optimization, the pillar for this cluster. Once you understand these two numbers, the natural next step is turning them into a buying plan, which we cover in how to build an AWS Savings Plan purchase strategy and in the broader question of Savings Plans versus Reserved Instances.
High coverage of an oversized fleet just locks in waste at a discount. Always rightsize and clear idle resources first, so the baseline you are committing to is the baseline you actually need.
What utilization actually measures
Utilization is the share of your purchased commitment hours that are matched to running usage. A Reserved Instance or Savings Plan you bought but did not fully consume in a given hour is wasted for that hour: you paid for the discount but had nothing eligible to apply it to. Utilization at or very near 100 percent means every dollar of commitment is being used. Anything meaningfully below that is a direct loss, because the unused portion is money spent for no benefit. This is why utilization is the number to protect first: it represents savings you have already paid for and might be throwing away. AWS reports utilization in Cost Explorer, and reading it is covered in using Cost Explorer like a practitioner.
What coverage actually measures
Coverage is the share of your eligible on-demand-equivalent usage that a commitment is discounting. If you run a steady fleet and only a third of it sits behind commitments, your coverage is roughly a third, and the other two thirds is paying full on-demand rates. Low coverage is opportunity left unclaimed: stable, predictable usage that could be discounted but is not. Raising coverage increases savings, but only up to the point where the next commitment would outrun your stable baseline and start sitting idle, which is where utilization begins to fall. Coverage is the growth lever; utilization is the safety check on how far you can pull it.
How the two trade off
The art is finding the coverage level that captures most of the discount while keeping utilization high. The reliable way to do this is to commit only to your stable baseline, the floor of usage that is present essentially all the time, and leave the variable portion on demand or on shorter, more flexible instruments. Because Savings Plans and convertible commitments apply more broadly than rigid standard Reserved Instances, they let you push coverage higher without risking utilization, since the discount can move as your usage shifts. Laddering purchases over time, rather than buying one large commitment, also protects utilization as your fleet changes.
Want your coverage raised without dropping utilization?
Our AWS cost audit measures coverage and utilization across every account, rightsizes the baseline first, and builds a commitment plan that captures the discount while keeping utilization at target. On the performance model you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →The targets we aim for
There is no universal number, because the right balance depends on how stable your usage is. As a working guide, we treat utilization below the high nineties as a problem to fix immediately, since it is paid-for savings going unused, and we treat coverage as a dial to turn up on genuinely stable workloads until the next increment would threaten utilization. A fast-growing or spiky environment carries lower coverage on purpose, because over-committing to usage that might move is a worse outcome than paying some on-demand premium. The point is to set both targets deliberately and watch them monthly, not to chase a single headline figure.
| Number | Answers | If it is low |
|---|---|---|
| Utilization | Am I using what I bought? | Direct waste, fix first |
| Coverage | Am I discounting what I could? | Savings left unclaimed, turn it up carefully |
| Both high and balanced | Healthy commitment portfolio | Maintain and re-check monthly |
| High coverage, low utilization | Over-committed | Shift to flexible instruments, ladder buys |
Reserved Instance and Savings Plans reporting, including coverage and utilization metrics in Cost Explorer, reflects AWS as of May 2026. Confirm current commitment types and reporting in the AWS documentation, as the product set evolves.
The AWS Cost Optimization Field Guide includes the coverage and utilization targets we set by workload type and the monthly review cadence we run. It is the downloadable companion to this explainer.
The short version
Utilization is how much of your commitment you actually use; protect it first because the unused part is pure waste. Coverage is how much of your eligible usage you discount; raise it on stable workloads until utilization would start to fall. Commit to the baseline, leave the variable part flexible, and ladder your buys. Getting both numbers right is the core of any AWS cost optimization commitment plan, the approach behind the savings in our SaaS on AWS case study.