RI Coverage Gap Analysis: Finding the Compute You Are Overpaying For

Coverage gap analysis is the single most cost-effective exercise in AWS compute FinOps. It identifies the running workloads that are being charged at full On-Demand rates while comparable, predictable compute elsewhere is sitting under Reserved Instance or Savings Plan coverage. Closing these gaps is usually the difference between an EC2 bill at full list and one running at a steady 40-50% off.

In our experience across 500+ engagements at $2.4B+ in AWS spend reviewed, almost every buyer with a non-trivial EC2 footprint has an exploitable coverage gap. The buyers who run a quarterly gap analysis routinely capture 5-15% of monthly EC2 spend back through better commitments.

What "coverage" actually measures

AWS reports two related metrics:

Utilization is the percentage of an existing RI or Savings Plan that is actually being consumed. A 1-year RI with 95% utilization is a healthy RI — it is matching to running workload almost continuously. A 50% utilization RI is sitting idle half the time.

Coverage is the inverse view: what percentage of your eligible compute is being absorbed by RIs or Savings Plans, vs. running at On-Demand rates. A 70% coverage figure means 30% of eligible compute is paying full On-Demand pricing.

Gap analysis focuses on coverage. The question is: which On-Demand compute is stable enough to warrant commitment, and how big is the wedge of unreserved-but-reservable compute?

The four categories of running compute

For a coverage analysis, every running EC2 hour falls into one of four buckets:

1. Already covered. Discount applied via Savings Plan or RI. No action.
2. Covered but mismatched. Discount applies but at less-than-optimal coverage (e.g., a zonal RI in AZ-A when workload migrated to AZ-B; a Convertible RI applying suboptimal pricing). Action: modify or exchange.
3. Reservable but uncovered. Stable, predictable workload running On-Demand. Action: add Savings Plan or RI coverage.
4. Genuinely On-Demand. Spiky, unpredictable, or short-lived workload that should remain at On-Demand pricing. No action (commitment would over-buy).

The gap analysis sorts running compute into these buckets and gives you a target for new commitment. Buckets 1 and 4 are healthy. Buckets 2 and 3 are where the savings live.

Data inputs for a gap analysis

A useful gap analysis requires:

• Cost and Usage Report (CUR) with hourly granularity, preferably 90+ days of history.
• Current RI inventory by family, AZ, region, and term.
• Current Savings Plan inventory by type (Compute SP vs EC2 Instance SP), commitment rate, term.
• Reservation utilization reports showing where existing commitments are matching or not matching.
• Workload roadmap from engineering — what is changing, retiring, or scaling in the next 6-12 months.

The CUR is the source of truth. The reservation utilization reports are useful but lossy. The workload roadmap is non-negotiable — without it, you will over-commit on workloads that engineering is about to migrate or retire.

The mechanical gap analysis

The mechanical analysis runs three sweeps:

Sweep 1: stable baseline identification

Compute, per instance family, the minimum number of running instances over the trailing 30, 60, and 90 days. This minimum represents the steady-state baseline that has been running every hour. By definition, it is reservable.

If the 90-day minimum for m6i is 240 instances, you have a 240-instance baseline that has been continuously online for at least 90 days. This is the most defensible commitment target.

Sweep 2: coverage overlap

Compare the baseline to existing RI + Savings Plan coverage in the same family/region. If you have 180 instance-equivalents of coverage for m6i and a 240-instance baseline, the gap is 60 instances. That gap is paying On-Demand for 90+ days continuously — exactly the workload that should be moved under commitment.

Sweep 3: roadmap adjustment

Engineering may have plans that change the baseline. If 80 of those 240 m6i instances are scheduled to migrate to Graviton in Q3, you should not commit 1-year coverage on workload that will not exist in Q3. Adjust the commitment target down accordingly.

The output is a defensible commitment recommendation: family, quantity, term, and Savings Plan vs RI choice.

Savings Plans vs RI for closing the gap

The next decision is what instrument to use. For most buyers, the right answer is:

• Compute Savings Plans for general-purpose compute (m, c, r families) that may evolve across generations.
• EC2 Instance Savings Plans for highly stable, family-specific compute where you want a deeper discount.
• Convertible RIs for legacy portfolios already on RIs that are being modernized.
• Standard RIs for very stable, AZ-pinned workloads (rare in 2026).
• Zonal RIs for capacity-reserved workloads in specific AZs.

Compute Savings Plans dominate new commitment in modern buyer portfolios for one reason: their broad applicability protects against the architecture shifts that strand RIs.

Sizing the commitment

A common error is committing to 100% of the baseline. This is over-commitment because the baseline includes workload that will eventually rotate or retire. The safer target is 85-90% of the trailing-90-day minimum, leaving a buffer for natural workload churn.

A second common error is committing in single large blocks. Three smaller commitments staggered across the year (a "rolling commitment" approach) gives you better termination diversity at year 2-3 of multi-year terms. If one workload retires, only one commitment is affected — not the whole portfolio.

The 1-year vs 3-year decision in coverage gap context

For closing a coverage gap, 1-year terms are usually correct as a first move:

• The workload is provably stable for 90+ days but not necessarily for 3 years.
• The 1-year commitment captures most of the discount (typically 75-80% of the 3-year discount value).
• The 1-year term lets the buyer adjust as the architecture evolves.

Once a workload has been stable under a 1-year commitment for a full term and engineering confirms long-term continuity, conversion to 3-year terms makes sense.

The cadence: monthly or quarterly?

Coverage drift is constant. New workloads launch, old ones retire, instance families rotate. A coverage gap analysis run once and forgotten will be stale within 6-12 months.

Recommended cadence:

• Monthly: coverage and utilization report review. Spot mismatches early.
• Quarterly: full gap analysis. Adjust commitments.
• Annually: portfolio review. Renewals, term decisions, SP vs RI rebalancing.

The monthly review prevents drift. The quarterly analysis enables action. The annual review captures strategic shifts.

Common gap-analysis errors

• Ignoring the workload roadmap. Engineering plans matter more than CUR data for forward-looking commitments.
• Over-relying on the AWS RI Recommendation tool. AWS recommends commitments aggressively because aggressive commitment is good for AWS. The recommendations are a starting point, not a target.
• Treating coverage as a vanity metric. 95% coverage is not automatically better than 85% coverage. The right number depends on workload stability.
• Skipping the SP-vs-RI evaluation. Default to Compute SP unless there is a specific reason to use an RI.
• Ignoring the cross-account portfolio. Coverage in a consolidated billing family flows across accounts; gap analysis should be done at the consolidated level, not per account.

The capacity layer

Coverage gap analysis focuses on the discount layer. Capacity is separate — On-Demand Capacity Reservations (ODCRs) can be layered on top of Compute Savings Plans to add the capacity guarantee that a zonal RI would provide. For mission-critical workloads with AZ pinning, the ODCR + Compute SP pattern is increasingly the right answer.

The cross-account view

In an AWS Organization with consolidated billing, RIs and Savings Plans are shared across linked accounts by default. This means gap analysis must be done at the consolidated billing family level. Looking at coverage account-by-account understates true coverage and leads to double-commitment.

The exception: accounts opted out of RI/SP sharing. Some organizations isolate specific business units' coverage for chargeback clarity. Gap analysis for these accounts is per-account.

What the savings look like

For a typical $5M/year EC2 spend with 65% existing coverage, closing the gap to 90% via Compute Savings Plans at a 25-30% discount produces approximately $375K-$450K in annual savings. The work to identify and execute the gap closure is typically 1-2 weeks of analysis plus the operational steps to purchase the commitments.

That ROI on advisory work is one of the highest in cloud cost management. A skilled coverage analysis pays for itself many times over.

Where outside advisory matters

Coverage gap analysis sits at the intersection of usage data, workload roadmap, and commitment instrument selection. Buyers who do it well have a coherent view of all three. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side coverage gap analysis and is independent of any RI or SP product agenda — recommendations are made on the buyer's behalf, not AWS's.

RI coverage gap analysis in one sentence

Identify the 90-day stable baseline, subtract existing coverage, commit at 85-90% of the gap on 1-year Compute Savings Plans by default, and re-run quarterly. For the broader framework see AWS Reserved Instance Optimization Guide, AWS Savings Plans Strategy Guide, and Savings Plans Amortization. To benchmark your coverage, Contact Us.

Tooling for gap analysis

The analysis can be done with native AWS tools, third-party FinOps tools, or custom SQL on the Cost and Usage Report. Each has trade-offs.

AWS Cost Explorer Reservation Recommendations. The native AWS tool surfaces commitment opportunities at 1-year and 3-year terms with All Upfront / Partial Upfront / No Upfront options. It is free, integrated, and accurate for simple portfolios. Its limitation: the recommendations are AWS-biased — they tend to recommend longer terms and aggressive upfronts.

AWS Compute Optimizer + Cost Explorer. Compute Optimizer adds right-sizing recommendations on top of the gap analysis. The combination is powerful for buyers who have not run a recent right-sizing exercise.

Third-party FinOps platforms. Tools like CloudHealth, Spot.io, ProsperOps, and Vantage offer coverage gap analysis with cross-account portfolio views and what-if modeling. For buyers above $1M monthly AWS spend, the cost of these tools is usually offset by the discovered savings.

Custom SQL on the CUR. For sophisticated FinOps teams, building gap-analysis SQL on Athena over the CUR provides the most flexibility. The queries can be tailored to the buyer's specific workload patterns, tagging conventions, and roadmap.

Tagging hygiene as a prerequisite

A gap analysis is only as useful as the tags on the running compute. Without good tagging:

• Workloads cannot be attributed to teams or applications.
• Commitment recommendations cannot be tied to organizational owners.
• Roadmap inputs cannot be reliably matched to running instances.

If tagging hygiene is poor, the first sprint of any FinOps engagement is tag remediation. Common standards:

• cost-center — financial owner.
• application — the application or service.
• environment — prod, staging, dev.
• owner-team — the engineering team.

For the tagging framework see AWS Cost Allocation Tags Guide.

Case study: $2.1M gap closure

A SaaS buyer with $8M annual EC2 spend ran a coverage gap analysis and found:

• Existing coverage: 52% (mix of legacy Standard RIs and one Compute SP).
• Stable 90-day baseline: 92% of running compute (the workload was very stable).
• Gap: 40 percentage points of stable, uncovered compute.

The team purchased Compute SPs at the No Upfront 1-year tier to cover 35 percentage points of the gap (leaving 5 percentage points for natural churn). Discount: 27% on the previously-uncovered compute. Annual savings: $2.1M.

The legacy Standard RIs were left in place until expiration (they were already producing higher discount than the new SPs would on the same workload). At expiration, those workloads transition to the Compute SP umbrella.

The cross-cluster portfolio view

Buyers with multiple AWS Organizations (often from acquisitions) face cross-Organization gap analysis. RIs and SPs cannot be shared across Organizations — each Organization is a separate billing family. This produces apparent coverage gaps that are really structural artifacts.

The fix is either consolidation (merging Organizations, which is operationally non-trivial) or independent gap analysis per Organization with the understanding that the apparent gap is not closable.

Gap analysis in the EDP context

EDP renewal is the highest-leverage moment for gap closure. The EDP includes a commitment level that AWS expects you to consume; gap closure helps you hit that commitment efficiently. Renewing an EDP without a gap analysis usually leads to over-commitment.

The right sequence:

1. Run the gap analysis 6 months before EDP renewal.
2. Close the operational waste and right-sizing items first.
3. Use the resulting baseline to negotiate the EDP commitment level.
4. Post-EDP, layer Compute SPs to hit the commitment efficiently.

The "right-sized" trap

Right-sizing and gap analysis interact in non-obvious ways. If you right-size aggressively before running gap analysis, the baseline shrinks and the apparent gap may close — but you may also have left over-committed RIs or SPs that no longer match. The result: high utilization on a smaller footprint, but with stranded commitment.

The recommended sequence: right-size first, let the new baseline stabilize for 30-60 days, then run the gap analysis. Premature gap analysis on an un-right-sized baseline over-commits.

FAQ: RI coverage gap analysis

What coverage percentage should I target? 85-90% of trailing-90-day minimum. 100% over-commits.

Should I use AWS's recommendations directly? Use them as a starting point, not a target. AWS recommends aggressively because aggressive commitment is good for AWS.

How often should I run a full gap analysis? Quarterly. Monthly review of coverage and utilization metrics. Annual portfolio reset.

Does coverage gap analysis apply to Fargate and Lambda? Yes, via Compute Savings Plans. The same analysis pattern applies; the math is just on aggregated Compute SP units rather than instance counts.

What about Spot capacity? Spot is separate from the gap analysis. Spot pricing is below SP/RI pricing and stacks differently. Gap analysis focuses on the On-Demand-priced compute that should move under commitment.