The bill lies about the partial month: projecting AWS cost when the RI lands as a single day-1 charge

The context: validate savings before month-end

A transactional app went through cost optimization: RDS rightsizing and Reserved Instance purchases. Management's mid-month question: "are the savings actually landing?". Trajectory: January US$1,670 (baseline) → March US$1,220 (-27%, partial month) → April projected ~US$724 (-57%). The challenge is projecting partial April without lying.

The trap: naive pro-rata overestimates

The instinct is to take spend-to-date and multiply by the month's fraction. That breaks for two reasons:

Partial benefit of the changes. Rightsizing landed on day 15 (16 days of benefit this month); RIs on day 22 (9 days). The days before were still expensive — projecting from the month's average mixes rates.

No-Upfront RI isn't spread. It shows up as ONE charge, usually on day 1, equivalent to the whole month — not as daily cost. Multiplying the running total by the month's fraction counts the RI twice.

A No-Upfront Reserved Instance is a fixed charge that lands at once, not a diluted hourly cost. Treating it as variable in pro-rata is the most common mistake when projecting a partial month.

The correct formula

Separate fixed from variable and only pro-rate the variable:

Month projection = (RI fixed, full month value)
                 + (variable cost to date ÷ days elapsed × days in month)
                 + (taxes on the total)

RI sanity check as a single charge:
  r6g.xlarge No-Upfront: US$0.248/h × 24 × 30 ≈ US$178.56/mo
  Actual on the bill:    US$178.76   ✓  (lands as 1 line, not 720 hourly)

With the RI out of the pro-rata and the variable projected correctly, the projection hit ~US$724 (-57%) — and management saw the right number, not one inflated by the wrong method.

How to pull the numbers

aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-04-30 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[].Groups[].{T:Keys[0],V:Metrics.UnblendedCost.Amount}' --output table
# HeavyUsage = RI (fixed) ; BoxUsage = on-demand (variable to pro-rate)

Lessons

1. No-Upfront RI is a single charge, not hourly cost. Add the full month value once; never pro-rate it.

2. Pro-rata only applies to the variable (BoxUsage). Separate HeavyUsage from BoxUsage before projecting.

3. Mid-month changes have partial benefit. Rightsizing/RI landing on day 15/22 only save on the following days; don't project from the whole-month average.

Conclusion

Optimizing cost is half the job; proving the optimization without lying is the other half. A partial-month AWS bill mixes a fixed charge that landed on day 1 with daily variable cost — and naive pro-rata counts the RI twice. Separating fixed from variable, the -57% projection held up on the final invoice.