While validating reservation savings, I found cases where savings are lower than expected, and some rows that should be positive appear as zero.
Root cause appears to be in reservation price lookup aggregation:
For the same lookup key, there can be duplicate price rows (for example Production and Dev/Test variants).
Current logic uses min for unit price selection.
In these duplicates, min tends to pick the lower Dev/Test price.
That underestimates the on-demand baseline and leads to underreported reservation savings.
👣 Repro steps
Compare outcomes with:
current aggregation using min
alternative aggregation using max
Observe that min picks the lower Dev/Test variant and produces lower savings totals plus more zero rows.
🤔 Expected
When duplicate price variants exist, reservation savings should use the correct production baseline price for comparison, not the lower Dev/Test variant.
🔧 Environment
FinOps hub version: affected in v1_0 and v1_2 transformation paths
Billing account type: observed in MCA scenario
ℹ️ Additional context
Proposed fix:
In reservation reference price summarize:
change ListUnitPrice from min to max
change ContractedUnitPrice from min to max
Why this fix:
Duplicate rows include Dev/Test and Production variants.
min can select Dev/Test (lower) and distort savings.
max selects the expected production baseline in those duplicate scenarios.
While validating reservation savings, I found cases where savings are lower than expected, and some rows that should be positive appear as zero.
Root cause appears to be in reservation price lookup aggregation:
For the same lookup key, there can be duplicate price rows (for example Production and Dev/Test variants).
Current logic uses min for unit price selection.
In these duplicates, min tends to pick the lower Dev/Test price.
That underestimates the on-demand baseline and leads to underreported reservation savings.
👣 Repro steps
Compare outcomes with:
current aggregation using min
alternative aggregation using max
Observe that min picks the lower Dev/Test variant and produces lower savings totals plus more zero rows.
🤔 Expected
When duplicate price variants exist, reservation savings should use the correct production baseline price for comparison, not the lower Dev/Test variant.
🔧 Environment
FinOps hub version: affected in v1_0 and v1_2 transformation paths
Billing account type: observed in MCA scenario
ℹ️ Additional context
Proposed fix:
In reservation reference price summarize:
change ListUnitPrice from min to max
change ContractedUnitPrice from min to max
Why this fix:
Duplicate rows include Dev/Test and Production variants.
min can select Dev/Test (lower) and distort savings.
max selects the expected production baseline in those duplicate scenarios.