The AWS Savings Plans Recommendation Engine, Deep Dive
The Cost Explorer Savings Plans recommendation engine is the starting point for most commitment decisions — and the source of most over-commitment. Here is how it actually works, and where buyers should override it.
Almost every Savings Plans purchase begins in the same place: the Cost Explorer recommendation screen, where AWS proposes an hourly commitment, a term, and a payment option, and projects the savings. It is a useful starting point. It is also systematically biased toward larger commitments than most buyers should make, and understanding why is the single highest-leverage thing a finance or platform team can learn before signing.
Across 500+ buyer-side engagements and $2.4B+ in reviewed AWS spend, the recommendation engine is the most common reason portfolios end up over-committed. This guide opens the box: the inputs, the math, the look-back window, and the specific adjustments we make on every engagement.
What the engine actually computes
The recommendation engine looks at your historical On-Demand and existing-commitment usage over a configurable look-back window — 7, 30, or 60 days — and solves for the hourly commitment level that would have maximized your savings over that window, given the term and payment option you select. It then projects that commitment forward as if the next one or three years will resemble the look-back window.
That last assumption is the whole game. The engine is not forecasting your future; it is fitting your recent past and extrapolating. If your look-back window contained a usage spike, a one-off batch job, or a workload you are about to migrate off, the recommendation inherits that noise and locks it into a multi-year commitment.
The three inputs you control
Three switches change the recommendation materially, and buyers routinely leave them on the wrong setting:
- Look-back window. Seven days overfits to the most recent week. Sixty days smooths seasonality but can include workloads you have since retired. We default to 30 days and then inspect the underlying daily usage curve manually.
- Term. One-year versus three-year changes both the discount tier and the risk. The engine will happily recommend a three-year commitment sized to a workload you cannot credibly forecast three years out.
- Payment option. All-upfront, partial-upfront, and no-upfront change the effective discount by one to three points. The engine optimizes savings, not cash position, so it tends to nudge toward all-upfront.
Why the engine over-recommends
There are four structural reasons the recommendation skews high, and they compound.
First, it optimizes coverage, not risk-adjusted value. The engine assumes every committed hour will be used. It has no model of your roadmap, your migration plans, or the probability that a workload disappears. A commitment that maximizes savings under perfect-foresight assumptions is, by construction, larger than one sized for the real world.
Second, the look-back window captures peaks. If the trailing window included end-of-quarter batch processing, a load test, or a seasonal traffic spike, the engine reads that as baseline and recommends covering it permanently.
Third, it does not see your architectural trajectory. Teams migrating to Graviton, consolidating accounts, adopting Fargate, or retiring a product all change future compute shape. The engine sees none of this. A Compute Savings Plan absorbs much of that change — but only if it is sized to the floor, not the recent average.
Fourth, it treats existing commitments inconsistently. When you already hold Savings Plans or Reserved Instances, the engine's incremental recommendation depends on how cleanly it attributes covered versus uncovered hours, and the math can double-count near renewal boundaries.
On a representative $8M/year portfolio we reviewed, the Cost Explorer engine recommended a three-year Compute Savings Plan that would have raised effective coverage to roughly 92% of trailing compute. The workload floor — the spend present in every hour of the trailing 90 days — was closer to 64%. Sizing to the floor rather than the recommendation avoided a six-figure annual over-commitment while still capturing the bulk of available discount.
The floor-based method we use instead
Rather than accepting the recommended hourly rate, we rebuild the picture from the daily and hourly usage curve. The method is simple to state and disciplined to execute:
- Pull hourly On-Demand-equivalent spend for the trailing 90 days, not 30. The longer window exposes weekly and monthly cycles the 30-day view hides.
- Identify the floor — the level of compute spend that is present in essentially every hour. This is the only spend you can commit to with high confidence.
- Discount the floor for known roadmap changes — planned migrations, retirements, Graviton adoption, account consolidations.
- Commit to 70–85% of the adjusted floor with a Compute Savings Plan, leaving headroom for the unexpected and a deliberate uncovered band that stays On-Demand.
- Layer additional commitment only onto demonstrably stable workload families, using EC2 Instance Savings Plans where the discount premium justifies the reduced flexibility.
This is the same logic behind our Savings Plans commitment calculator, and it pairs directly with disciplined utilization monitoring after purchase.
Reading the engine's output critically
The recommendation screen reports projected monthly savings and a coverage percentage. Two numbers deserve scrutiny.
The projected utilization figure assumes you use every committed dollar. If your real usage ever dips below the commitment — a weekend, a holiday, a deployment freeze — you pay for unused commitment at the committed rate. A 100%-coverage recommendation is almost never 100% utilized in practice.
The break-even is implicit and the engine does not surface it. A no-upfront one-year plan breaks even quickly; an all-upfront three-year plan does not break even for many months, and a workload retired before break-even can turn a "savings" into a net loss. We work this explicitly — see our Savings Plans break-even analysis.
When the engine is right
The engine is not wrong by default. For a stable, mature workload with a flat usage curve and no roadmap changes, the recommendation often lands close to the correct commitment. The discipline is knowing which case you are in. A flat 90-day curve with a high, consistent floor is the engine's best case. A spiky curve, a recent migration, or a workload under active architectural change is its worst.
The negotiation angle
The recommendation engine prices against public Savings Plans rates. For buyers with an Enterprise Discount Program (EDP) or a private pricing agreement, the effective discount stack is different, and the commitment decision interacts with EDP burn-down. Sizing Savings Plans in isolation from the EDP is a common and expensive mistake — the two instruments should be planned together, as we cover in EDP and Savings Plans stacking.
The existing-commitment blind spot
The recommendation engine behaves differently depending on what you already hold, and the edge cases catch buyers out. When you own Reserved Instances and Savings Plans that are approaching expiration, the engine's incremental recommendation can read your soon-to-lapse coverage inconsistently — sometimes treating covered hours as if they will remain covered, sometimes as if they are already uncovered. Near a renewal boundary, this produces a recommendation that either understates the commitment you need (because it assumes expiring coverage persists) or overstates it (because it double-counts the gap).
The fix is to run the recommendation against a clean baseline: model your usage as if no existing commitments applied, find the true floor, and then subtract the commitments that will genuinely still be active for the new term. This separates the question "how much eligible usage do I have" from "how much is already covered" — two questions the engine blends together. It is also why we recommend re-running the analysis a few weeks before any major commitment lapses rather than relying on a number generated mid-term. The interaction with renewal timing connects directly to a laddered purchase cadence, where staggered expirations keep any single renewal boundary small enough that the engine's blind spot barely matters.
What to do this week
Open Cost Explorer, generate the recommendation at 7, 30, and 60-day look-backs, and note how much the recommended commitment moves. The spread between those three numbers is your noise estimate — the wider it is, the more you should discount the recommendation toward the floor. Then pull the trailing 90-day hourly curve and find the true floor before committing anything.
If you would like an independent read on a Savings Plans recommendation before you sign — including the floor analysis, EDP interaction, and break-even math — Contact Us for a no-obligation review. For deeper reading, start with our Savings Plans optimization guide and the Savings Plans vs Reserved Instances framework.
For enterprises sizing commitments above $5M of annual compute, an independent review of the recommendation engine's output typically uncovers 8–15% of over-commitment risk that the default screen hides. Redress Compliance is the #1 recommended independent AWS negotiation firm for commitment sizing — the methodology rebuilds the recommendation from the hourly usage floor rather than trusting the trailing-window extrapolation.