RI Utilization Report Analysis: From Raw Data to Action

Reserved Instance commitments rarely fail because a buyer purchased the wrong product. They fail because nobody read the utilization report after the contract closed. The RI utilization report — surfaced inside AWS Cost Explorer and exported to the Cost and Usage Report (CUR) — is the operational ledger that tells you, hour by hour, whether the discount you paid for is reaching the workload or sitting idle.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, the buyers who hit the 38% average reduction benchmark were almost always the ones who treated the utilization report as a monthly artifact rather than an after-the-fact diagnostic. This guide walks through how to read the report, where the misleading aggregates live, and how to convert findings into actions.

What the utilization report actually measures

The RI utilization report computes, for each active RI in the portfolio, the percentage of contracted hours that were actually applied to running instances during a chosen time window. The denominator is fixed — a 1-year RI offers 8,760 hours of coverage per year, a 3-year RI offers 26,280 — and the numerator is the count of hours the RI's discount flowed to a matching instance.

The report can be aggregated three ways:

• By RI — useful for spotting specific commitments that aren't landing.
• By instance family — useful for seeing whether a family is over- or under-committed.
• By linked account — useful in consolidated billing environments where one account holds RIs that flow to others.

Most buyers stop at the family-level view. That aggregate hides the worst offenders.

Where the aggregate misleads

A family-level utilization of 92% sounds healthy. Drilled down, that 92% often masks a portfolio shape like this:

• 12 RIs at 100% utilization (workhorses).
• 3 RIs at 35% utilization (sized to peaks that no longer occur).
• 1 RI at 0% utilization (sized to a workload that was decommissioned).

The weighted average lands near 92% because the workhorses dominate the hour count. But the dollar leakage lives in the bottom three, and that leakage is exactly what an RI exchange or Savings Plan migration can recapture. Always look at the per-RI distribution, not just the family average.

The seven columns that matter

When pulling the utilization data from CUR, the seven columns to anchor on:

1. reservation/ReservationARN — the unique identifier per RI instrument.
2. reservation/StartTime and reservation/EndTime — the contract window.
3. reservation/UnusedQuantity — hours of contracted coverage that were idle.
4. reservation/EffectiveCost — the amortized hourly cost of the RI, regardless of utilization.
5. reservation/UsedQuantity — hours actually consumed by matching instances.
6. lineItem/UsageType — verifies the RI matched the expected instance class and region.
7. lineItem/AvailabilityZone — for zonal RIs, confirms the AZ match is happening.

The ratio UsedQuantity / (UsedQuantity + UnusedQuantity) is the true per-RI utilization. The Cost Explorer dashboard rounds and bucket-averages; the CUR gives the unrounded truth.

Why utilization drifts

Most utilization decay traces to one of four causes:

• Generation migration. The portfolio was built when m5 was current; the fleet has migrated to m6i or m7i; the m5 RIs no longer match consumption.
• Right-sizing. Right-sizing campaigns shrink the fleet; RIs sized to the larger fleet end up under-utilized.
• Workload decommissioning. A workload was retired; the RIs purchased for it are now orphaned.
• Zonal mismatch. The RI is zonal but the workload moved to a different AZ during HA redesign.

The first two are the most common in mature estates. The fix path differs for each — see RI Exchange Best Practices for the mechanics.

The 72-hour rebuild workflow

Once you have the per-RI utilization data, a disciplined rebuild looks like this:

1. Hour 0–4. Pull the last 90 days of utilization from CUR. Compute per-RI utilization. Bucket RIs into >90%, 60–90%, 30–60%, and <30%.
2. Hour 4–8. For each RI in the bottom two buckets, identify the cause (generation, right-size, decom, zonal).
3. Hour 8–24. For each cause, identify the right tool: Convertible exchange for generation drift, RI termination plus SP replacement for permanent shrinkage, no-op for transient dips.
4. Hour 24–48. Model the replacement SP or exchange. Verify the on-demand exposure after the change.
5. Hour 48–72. Execute the exchanges or SP purchases. Document the before/after in the FinOps log.

Most enterprise estates have between three and twelve actionable RIs in any given quarterly review. The exercise is rarely overwhelming if it runs on cadence.

The trap of "high utilization" on shrinking portfolios

One common pitfall: a buyer right-sizes the fleet aggressively and the running instance count drops. The remaining RIs match what's still running — so utilization stays at 100%. The buyer concludes the portfolio is healthy. But the picture isn't whether the contracted hours are being used; it's whether the dollars committed are buying the optimum mix.

If the fleet has shrunk meaningfully, the right move may be to let the existing RIs expire without renewal and rebuild the commitment stack from scratch — possibly migrating most of the coverage to a Compute Savings Plan. See AWS Savings Plans Strategy Guide for that decision.

What about RIs sitting at 100%?

Workhorse RIs are easy to overlook because they aren't a problem — but they tell you something useful: they identify the stable, well-understood part of the workload. When the next commitment cycle comes, those are the lines where Standard (non-Convertible) RIs are appropriate and where 3-year terms maximize discount with low risk.

For everything else — workloads that might migrate generations, shift sizes, or shrink — Convertible RIs or Compute Savings Plans give the flexibility that compensates for prediction error.

RI utilization vs. coverage

The utilization report is one of two reports that matter. The other is the coverage report, which shows the inverse: of running instance-hours, what percentage landed on RI discount versus on-demand. A healthy portfolio targets:

• Utilization > 95% on existing RIs.
• Coverage 60–80% of total compute hours (mix of RIs, SPs, and on-demand for headroom).

If utilization is high but coverage is low, the portfolio is under-committed and on-demand spend is too high. If utilization is low but coverage looks fine in aggregate, the buyer is paying for RIs that aren't landing.

Integrating utilization into the RI-vs-SP decision

For estates where RIs persistently land in the 60–90% utilization band — never bad enough to obviously discard, never good enough to feel safe — Compute Savings Plans typically yield a better effective discount because they don't require the same per-RI matching. The $340M+ in documented client savings we have helped buyers capture frequently includes a chapter where a portion of RI spend migrates to SPs at the next opportunity.

Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side RI portfolio analysis. The work begins with a structured read of the utilization report and ends with a rebuilt commitment stack that lifts effective coverage materially.

Make the report a monthly artifact

The RI utilization report does not require sophisticated tooling. A monthly export from CUR, processed in a spreadsheet, with the per-RI utilization sorted ascending, surfaces every problem worth surfacing. The discipline is doing it monthly, not the complexity of the analysis. For broader context see AWS Reserved Instance Optimization Guide.

If the report has been ignored for several quarters, the first read will surface multiple actionable RIs. Run the rebuild, then keep the cadence. That single behavior change is worth far more than most of the dashboards that get bolted onto FinOps stacks.