Repository navigation
fix(recommendations/aws): incorrect Effective Savings % — plumb on_demand_cost like Azure (#277) #303
Description
Summary
The Effective Savings % shown for AWS recommendations is incorrect — it does not match the savings the customer would actually realize given the recommended commitment.
Observed
AWS recommendations show an Effective Savings % that diverges from the savings reconstructable from monthly_cost, recommended_monthly_cost, and on_demand_cost. This was previously fixed for Azure 1y RIs in #277 by plumbing on_demand_cost from the provider through to the frontend, but the AWS side still reports values that are wrong relative to the actual savings.
Expected
Effective Savings % = (on_demand_cost − recommended_monthly_cost) / on_demand_cost, using the canonical on_demand_cost returned by the provider — not a value reconstructed from current spend (which already includes existing commitments).
Acceptance criteria
- AWS recommendations carry a non-null
on_demand_costfrom the provider all the way toRecommendationRecordand the API payload. effectiveSavingsPct()infrontend/src/recommendations.tsresolves to the same value as the underlying provider report for AWS RIs and Savings Plans.- Unit test in
frontend/src/__tests__/recommendations.test.tspinning the expected effective % for at least one AWS RI fixture and one SP fixture. - Regression test in the AWS provider mapping that asserts
OnDemandCostis populated.
Out of scope
Azure / GCP — Azure was fixed in #277; GCP needs a separate audit if the same bug shape applies.
Activity
fix(recommendations/aws): plumb on_demand_cost for Effective Savings % (
cristim commentedon May 13, 2026
Verified resolved by PR #312 (merged 2026-05-05).
Evidence from the diff:
parseSavingsPlanDetailinproviders/aws/recommendations/parser_sp.gonow computesonDemandCost = parseOptionalFloat("CurrentAverageHourlyOnDemandSpend", ...) × 730and assigns it torec.OnDemandCost. This is the sameCurrentAverageHourlyOnDemandSpend × hoursPerMonthformula AWS Cost Explorer uses internally forEstimatedSavingsPercentage, so the frontend now receives the provider-supplied denominator rather than reconstructing it frommonthly_cost + savings + amortized.parseAWSCostDetails → EstimatedMonthlyOnDemandCostwas in place before this PR (landed in fix(recommendations): plumb provider on_demand_cost through to frontend (closes #274) #277); fix(recommendations/aws): plumb on_demand_cost for canonical Effective Savings % (closes #303) #312 closes only the SP gap, which was the remaining open surface.TestParseSavingsPlanDetail_OnDemandCostinproviders/aws/recommendations/parser_sp_additional_test.gopins thatOnDemandCost == CurrentAverageHourlyOnDemandSpend × 730for a Compute SP detail, and that a missing field yields 0 (whichnonZeroPtrconverts to nil so the frontend falls back gracefully).frontend/src/__tests__/recommendations.test.tsinside the existingeffectiveSavingsPctdescribe block: EC2 RI (expected 23.33%), Compute SP (20%), and SP with null monthly_cost (20%). Each fixture includes a comment explaining what the wrong reconstructed value would have been withouton_demand_cost.All four acceptance criteria from the issue body are satisfied. Recommending closure.