Keystone

Cloud Cost Optimization Is Dead. Long Live Cloud Unit Economics.

Every quarter, somewhere in your company, a Slack message goes out that reads something like:

“Hey team, finance wants us to look at the AWS bill. Can we find some savings before EOQ?”

What follows is two weeks of frantic resource tagging, RI purchases, and S3 lifecycle rules. The bill comes down 15-20%. Everyone celebrates. The Slack thread is archived. And then, six months later, the same message goes out again.

This is the cloud cost optimization treadmill, and most engineering organisations are still on it.

It needs to die.

The problem with “optimization” as a frame

Cost optimization treats your AWS bill as a number that needs to be smaller. That framing has three fundamental problems:

  1. It is reactive. Optimization only starts when the bill is already painful.
  2. It is one-directional. Lower is “better”, regardless of what the spend is producing.
  3. It is decoupled from the business. A 20% cost cut means nothing if your revenue grew 80% in the same period — you should probably be spending more.

Optimization is what you do when you’ve lost control. It’s a recovery exercise. It is not a strategy.

Unit economics: the actual question worth answering

The question that matters is not “how much did we spend on AWS this month?” It is:

How much does it cost us to serve one customer? One transaction? One API call? One AI completion?

This is unit economics. It is the framing that every serious infrastructure team — at Stripe, Shopify, Anthropic, Snowflake — has converged on. Not because they are cheap, but because they are scaling, and the only way to scale profitably is to know what each marginal unit of work actually costs.

A useful unit cost metric has three properties:

  • It maps directly to something the business cares about (revenue, users, calls)
  • It can be calculated automatically from your cost data
  • It moves in a meaningful way when your engineering decisions change

“AWS bill per month” satisfies none of these. “Infrastructure cost per active customer per month” satisfies all three.

What changes when you measure unit cost

Three things happen, in roughly this order.

1. Engineering conversations get more honest

Once you have a unit cost, engineering trade-offs become quantifiable. “Should we switch to GraphQL?” stops being an architectural debate and becomes a measurable bet: does it move cost-per-request up or down? “Should we add a caching layer?” same question.

2. Finance stops asking about the bill

Counter-intuitive, but consistent. Finance teams don’t actually care about the AWS bill. They care about gross margin. Once you can show them cost-per-customer trending the right way, the monthly bill stops being interesting.

3. Optimisation becomes continuous, not episodic

When unit cost is on a dashboard, it gets watched. A regression — say, a deploy that adds 8% to cost-per-request — gets caught the day it ships, not six months later in an audit.

A simple model to start with

You don’t need a FinOps platform to start. You need three numbers, refreshed weekly:

-- 1. Total infrastructure cost for the period
SELECT SUM(unblended_cost) AS infra_cost
FROM cur_data
WHERE billing_period = '2026-05';

-- 2. The unit (customers, transactions, etc.) for the same period
SELECT COUNT(DISTINCT customer_id) AS active_customers
FROM events
WHERE event_time BETWEEN '2026-05-01' AND '2026-05-31';

-- 3. Divide. That's your unit cost.

Watch it for three months. You will learn more about your business in that quarter than you did in the previous year of cost dashboards.

The hard part isn’t the maths

The hard part is choosing the right denominator. “Cost per customer” works for a SaaS. “Cost per API call” works for an infra product. “Cost per inference” works for an AI company. “Cost per shipped order” works for e-commerce.

Pick the unit that maps to how your business actually makes money. If you sell seats, measure per seat. If you sell volume, measure per unit of volume. Anything else is theatre.

Optimization isn’t gone — it’s a side effect

To be clear: the savings still happen. Idle NAT gateways still get deleted. RIs still get bought. Snapshots still get cleaned up. But these stop being the goal and start being natural consequences of measuring the right thing.

When cost-per-customer is going up, you investigate. When it’s going down, you keep doing what you’re doing. The bill takes care of itself.

Engineering organisations that make this shift tend not to go back. The quarterly cost panic gets replaced by a steady, boring metric on a dashboard. The Cost Explorer tab stops being a place you dread opening. And the conversation moves from “what does our infrastructure cost?” to “what is it worth?”

If your organisation is still doing cost optimization sprints, the work to do is probably different from what you think. Let’s talk about what that looks like for your team.