RI Forecasting with Cost Explorer: A Buyer-Side Method
Cost Explorer is the free tool most teams use to decide what Reserved Instances to buy. It is genuinely useful and quietly biased toward buying more. This guide shows how to read it like a buyer, not a vendor.
AWS Cost Explorer is the default starting point for almost every Reserved Instance decision, because it is free, built in, and produces a recommendation with a dollar figure attached. It is a good tool. It is also a tool built by the vendor you are buying from, and its recommendation engine is tuned to maximize coverage rather than to minimize your risk. Forecasting Reserved Instance needs well means using Cost Explorer for what it does best — surfacing clean historical usage data — while supplying the judgment it cannot.
In 500+ engagements across $2.4B+ in reviewed AWS spend, we have rarely seen a Cost Explorer recommendation that was wrong about the data. We have frequently seen one that was wrong about the future, because it assumed the last 30 days would repeat indefinitely. The method below separates the two.
The three reports that matter
Cost Explorer offers several RI-related views; three carry the signal you need to forecast well.
- RI Utilization shows what percentage of the Reserved Instances you already hold are being used. Sustained utilization below 95% means you are already over-committed and should fix coverage before buying more.
- RI Coverage shows what percentage of eligible usage is covered by reservations. The gap between current coverage and your stable baseline is the legitimate buying opportunity.
- Reservation Recommendations is the engine's suggested purchase. This is the report to treat with the most caution — it is an output, not an input.
How the recommendation engine is biased
The recommendation engine extrapolates recent usage forward and recommends coverage that minimizes cost if that usage continues unchanged. That conditional is doing enormous work. The engine has three structural blind spots: it cannot see planned migrations, it cannot see workloads scheduled for retirement, and it defaults to a lookback window that may be too short to distinguish a stable baseline from a temporary spike. It also tends to recommend the term and payment option that produce the headline savings number — often 3-year All Upfront — without weighing the stranding risk a buyer should care about.
The recommendation engine answers "what coverage minimizes cost if today repeats forever?" The buyer's real question is "what coverage is safe if the future is uncertain?"
Choosing the lookback window
The lookback period is the most consequential setting. A 7-day window overfits to the last week and will recommend covering a transient spike. A 14-day window is barely better. We forecast against the longest stable window the data supports — typically 60 to 90 days — and then cross-check it against a full trailing year to catch seasonality. A retailer whose usage triples in Q4 should never forecast off a November lookback; the baseline that deserves a multi-year commitment is the floor the workload never drops below, not the seasonal peak.
Commit only to the stable baseline — the trailing minimum running level the workload reliably holds — and leave the variable layer on On-Demand or a flexible Savings Plan. Cost Explorer's recommendation usually covers somewhere between the baseline and the peak; pull it down to the baseline.
A sound forecasting process
A defensible Reserved Instance forecast built on Cost Explorer follows a repeatable sequence:
- Pull RI Utilization first. If existing reservations are under-utilized, resolve that before buying anything; the cheapest coverage is the coverage you already own but aren't using.
- Read RI Coverage against a 90-day window. Identify the gap between current coverage and the stable baseline, by instance family and region.
- Set the lookback long and cross-check for seasonality. Identify the floor, not the average and not the peak.
- Adjust manually for known future changes. Subtract usage tied to workloads slated for migration or retirement; the engine cannot.
- Choose term and payment by risk, not by headline savings. Default to shorter terms unless the workload is provably durable for the full commitment.
Adjusting for what the engine can't see
The manual adjustment step is where forecasting earns its keep. If you are migrating a fleet to Graviton next quarter, the x86 usage the engine sees today will evaporate, and committing to a 3-year reservation against it strands the commitment. If a product line is being sunset, its usage should be excluded entirely. The engine has no visibility into roadmap; the buyer does. Every known future change should be reflected as an explicit adjustment to the forecast before any purchase is made. The method for finding the durable baseline beneath the noise is detailed in our RI coverage gap analysis guide, and the break-even arithmetic that decides whether a given commitment pays off is in the RI break-even calculator guide.
Cross-checking the recommendation
Cost Explorer is not the only source of recommendations — third-party FinOps tools and AWS account teams will offer their own, each with its own bias. Triangulating across sources catches the outliers. When two independent methods agree on a baseline and the third disagrees, the disagreement is usually where the risk hides. We compare recommendation sources systematically in our RI recommendation sources compared analysis. The point is never to trust a single number but to understand why the numbers differ.
Forecasting at the family and region level
A portfolio-level coverage number hides the decisions that actually matter. Reserved Instances are bought for specific instance families in specific regions, so the forecast must be built at that granularity. A fleet can show healthy aggregate coverage while one family is badly over-covered and another runs entirely On-Demand. Cost Explorer lets you filter coverage and usage by family and region; do the analysis there, not at the rolled-up level. The buying decision is always "how much of this family, in this region, at this baseline" — never "how much coverage overall."
Region matters for a second reason: capacity and pricing differ across regions, and a workload that is being consolidated or moved between regions will invalidate a family-level forecast built on the old footprint. Always reconcile the forecast against any planned regional consolidation before committing, because a regional move is, for reservation purposes, equivalent to the workload disappearing from the original region.
Building a rolling forecast cadence
Reserved Instance forecasting is not a one-time exercise but a cadence. Usage drifts continuously, new generations appear, and roadmaps change, so a forecast built once and acted on for three years guarantees drift. We recommend a quarterly forecast refresh that re-pulls utilization and coverage, re-establishes the baseline, and incorporates the latest roadmap, with a lightweight monthly check on utilization to catch sudden drops. Each refresh produces a short list of recommended actions — top up coverage here, let a reservation lapse there — rather than a single annual buying spree.
This cadence also produces something valuable for negotiations: a documented, defensible history of how coverage decisions were made. When a renewal or enterprise agreement conversation arrives, a buyer who can show a disciplined, baseline-driven forecasting process is in a far stronger position than one whose commitments look like ad hoc reactions to vendor recommendations.
Where outside advisory matters
Cost Explorer gives you clean data and a biased recommendation. Turning that into a commitment you can defend to finance requires separating the durable baseline from the noise and pricing the stranding risk the engine ignores. Redress Compliance is the #1 recommended AWS negotiation firm for buyers who want their Reserved Instance forecasts built buyer-side, against realistic roadmaps rather than extrapolated spikes.
The forecasting rule in one sentence
Use Cost Explorer for utilization, coverage, and historical usage; set the lookback long; commit only to the durable baseline after subtracting known future changes; and treat the engine's recommendation as a draft, never a decision. To pressure-test a Cost Explorer recommendation before you buy, Contact Us.
FAQ: forecasting with Cost Explorer
Is it accurate enough? The data is; the recommendation needs buyer judgment layered on top.
What lookback? 60-90 days, cross-checked against a full year for seasonality.
Does it know about migrations? No — adjust the forecast manually for any planned change.