Introducing Effective Coverage %: the FinOps metric that combines coverage and utilization

If you have ever looked at an AWS Cost Explorer dashboard and seen "95% Savings Plan utilization" you probably felt good about it. You should not have. Utilization on its own tells you a fraction of a story — namely, whether you used what you bought. It tells you nothing about whether you bought enough.

The opposite metric — commitment coverage — has the inverse problem. "We have 80% coverage" sounds great until you find out that a quarter of those commitments are sitting idle. Coverage measures whether you bought enough; it does not measure whether you actually use what you bought.

A healthy commitment program needs both. The metric that captures both is the product of the two numbers: Effective Coverage %.

The formula

Effective Coverage % = Coverage × Utilization

  Coverage     = $ eligible compute on commitments / $ eligible compute total
  Utilization  = $ commitment used / $ commitment purchased

Both inputs are computable directly from CUR. Coverage measures what fraction of your eligible compute ran on a Reserved Instance or Savings Plan rather than on-demand, at on-demand-equivalent rates so the two sides compare like for like. Utilization measures how much of each commitment you actually consumed versus paid for, dollar-weighted across the portfolio.

Why one number

Two numbers force whoever reads the report to multiply them in their head. Most people do not. The same way "100% test coverage" tells you nothing about whether your tests assert anything useful, "95% utilization" tells you nothing about whether you have committed to enough of your compute. Both numbers individually round up in your favor; the product is honest.

A single KPI also gives finance and engineering a shared target. CFOs do not want to debate the merits of coverage vs. utilization; they want to know whether the FinOps function is producing leverage. One number answers that. When it moves, the breakdown tells you which half moved.

Reading the number

A few rough heuristics for what different ranges mean — these depend on workload mix, but they are a starting point for "should I be worried":

• ◦Below 30%: no active FinOps program. Most compute is paid at on-demand rates. Easy wins available.
• ◦30–55%: commitment management is in flight but immature. Typical of orgs in their first year of FinOps.
• ◦55–75%: active FinOps function with regular review. Industry median for orgs with a dedicated FinOps role.
• ◦75%+: mature program, likely using continuous commitment management. The remaining gap is usually structural (bursty workloads that should not be committed).

The example that explains it

Two orgs end up at roughly the same Effective Coverage %. They got there in opposite ways.

• ◦Org A: 95% coverage × 70% utilization = 66.5% EC. Over-committed but disciplined about using what they bought. The remaining gap is wasted commitment dollars — they should shorten terms or move to Savings Plans for flexibility.
• ◦Org B: 40% coverage × 95% utilization = 38% EC. Disciplined utilization but under-committed. 60% of their compute is on-demand at retail. They should buy more.
• ◦Org C: 75% coverage × 90% utilization = 67.5% EC. Healthy on both axes, with a small tuning opportunity on the utilization side.

Org A and Org C are within a percentage point of each other, but the action plan is completely different. Effective Coverage % tells you the score; the breakdown tells you what to do next.

How CloudQuell computes it

Effective Coverage % is live on the Commitments view. CloudQuell computes it from your CUR, weighted by dollars rather than commitment count, and broken down per integration so multi-account orgs can see which sub-account is dragging the average. A 12-month trend chart is the view finance teams use to know whether the function is working.

It is also actionable: underutilized commitments carry plain-English right-sizing guidance, and every commitment recommendation shows its projected impact on the number — "adopt this Savings Plan and your Effective Coverage % moves from 18% to 24%".

The inputs are not new. CUR has had the data since AWS started publishing it. What is new is treating the combination as a first-class metric instead of two metrics shown side-by-side and left for the reader to multiply.