Skip to content
CloudPouch Docs

How to measure AWS cost optimization results with a KPI

Comparing this month’s AWS bill to last month’s is the wrong way to measure an optimization — in a live account the comparison measures everything that changed, not just your work. The fix is a unit KPI: in one real EBS optimization, average monthly storage cost per EC2 instance fell from $14.20 to $5.82 (−59%), and that number stayed true no matter what else happened in the account.

Why raw bill comparison fails

Section titled “Why raw bill comparison fails”

An AWS account under optimization does not hold still. Teams launch new workloads, delete old ones, and traffic shifts — all while you work.

  • If the total bill rises during your project, your optimization may still have succeeded; new workloads simply added cost faster than you removed it. Now you get to explain why “savings” made the bill bigger.
  • If the total bill falls, you cannot prove your work caused it — maybe another team decommissioned something.

In the engagement behind our EBS snapshot case study, the risk was concrete: had the client launched 5,000 new EC2 instances mid-project, the new EBS costs would have swallowed the savings in the total bill, and there would have been nothing to show for months of work. This is also why FinOps practice recommends unit economics over absolute spend.

Build a unit KPI

Section titled “Build a unit KPI”

Divide the cost you are optimizing by the unit that drives it:

KPI = cost of the optimized area / number of driving units

For the stopped-instance EBS work in the case study, the KPI was average monthly storage cost per EC2 instance:

monthly EBS storage cost / EC2 instance count

When working from daily cost data, convert to months with a consistent convention — the case study used 365/12 (~30.4 days) as the average month length. Whatever convention you pick, use the same one for the before and after measurements; the KPI’s value is comparability, not precision.

The unit should be whatever scales with the cost: instances for storage work, requests for Lambda, GB processed for NAT Gateways, active users or transactions for whole-account KPIs shared with finance.

What the case study measured

Section titled “What the case study measured”

With the per-instance KPI, the snapshot-parking optimization reported cleanly even as the fleet changed:

MetricBeforeAfter
Avg. monthly storage cost per EC2 instance$14.20$5.82 (−59%)
Avg. EBS volumes per EC2 instance1.920.46

Absolute savings were $109,926 per month — but the KPI is what proved the optimization caused them.

Workflow with CloudPouch

Section titled “Workflow with CloudPouch”
  1. Use CloudPouch to find the cost driver — for storage work, that is the EC2 - Other area and the EBS and snapshot Cost Insights.
  2. Record the “before” values: the cost of the target area and the unit count.
  3. Calculate and write down the KPI, formula included, before you change anything.
  4. Optimize.
  5. Recalculate with the identical formula and time convention. The delta is your result.

What makes a KPI hold up

Section titled “What makes a KPI hold up”
  • Tied to the goal — it moves when your optimization works and not when unrelated things change.
  • Recalculable — anyone with the formula and the data gets the same number six months later.
  • Normalized — per instance, per volume, per workload, per team; never a raw total.
  • Legible to finance — “storage cost per instance dropped 59%” needs no AWS knowledge to land.
Section titled “Related pages”