A strong answer. “First I would establish whether this is actually a problem, because a 60% increase against 25% revenue growth is only bad if the unit economics are getting worse. If we launched a product that is inherently more compute-intensive, or shifted to a workload with different margins, the aggregate number is the wrong lens. So the first thing I want is cost per unit of business value — per customer, per transaction, per active user — and its trend. That is a very different conversation from ‘the bill went up’, and it is the one the CFO is actually having.

To get that I need allocation, which is usually the real blocker. Most organisations cannot attribute more than half their spend to a team or product, so nobody owns anything and every conversation is about the total. Getting tagging enforced — at provisioning time, through policy, not by asking people — is unglamorous and it is the prerequisite for everything else.

Then I would look at where the growth is concentrated, because it almost always is. Typically one or two services, and typically one of three causes: something scaled with usage as designed, something is being retained that nobody needs, or something was provisioned for a peak that never recurred.

Only then the levers, in order of effort: delete what nobody uses, right-size, change storage class or retention, then commitment discounts — and I would deliberately leave commitments until last, because buying a three-year commitment on an architecture you are about to change is how organisations lock in waste.

And I would put the number in front of the engineers who create it, monthly, per team. Visibility with ownership moves more spend than any central optimisation programme, because they know what is safe to turn off and I do not.”