I lead the org that builds pricing systems for EC2 at AWS. So I’ve thought about this a lot — and I can tell you that the engineering leaders who struggle most with cloud costs are almost never struggling because of a technical problem. They’re struggling because of a cultural one.
Here’s the pattern I see repeatedly: cloud spend grows faster than expected, finance sends an alert, leadership schedules a meeting, someone produces a spreadsheet showing which teams are spending what, and then there’s a conversation about “rightsizing” and “optimization” that produces a short-term reduction and almost no lasting change. Three quarters later, the same meeting happens again.
The root cause isn’t that engineers don’t know how to reduce cloud spend. It’s that they don’t feel the cost of what they build.
When you’re writing code on a laptop, spinning up an EC2 instance feels free. You click a button, something appears. You forget to turn it off. You provision a large instance because you’re not sure what size you need and erring on the side of bigger feels safer than having to deal with a bottleneck. You run a service in three environments and two of those environments see almost no traffic, but bringing them down means a conversation about risk and nobody wants that conversation. None of this feels like spending money, even though it is.
The fix isn’t a FinOps tool, though those help. It’s building cost awareness into how engineers think about their work — and that only happens when leadership treats it as their problem to solve, not finance’s.
What does that actually look like?
First, the people spending the money need to see it. This sounds obvious, but many engineering teams have no visibility into their own cloud costs in any regular, accessible way. If cost data only lives in a dashboard that finance reviews, cost becomes finance’s concern. When cost is part of a team’s weekly metrics — alongside latency, error rates, and deployment frequency — it becomes the team’s concern.
Second, the conversation has to be framed correctly. If engineers experience cloud cost as something leadership uses to criticise them, they’ll hide it. If they experience it as a resource they have agency over — one they can spend wisely or waste — they’ll start making better decisions. The framing matters enormously. I’ve found it’s useful to talk about cloud spend the same way you’d talk about headcount: not as a line item to cut, but as a resource to deploy deliberately.
Third, the architecture reviews need to include cost. AWS makes its pricing publicly available and the trade-offs are well understood: On-Demand pricing gives you flexibility at a higher per-hour cost, Reserved Instances and Savings Plans reduce that cost significantly in exchange for a commitment, Spot Instances offer even deeper discounts for workloads that can handle interruption. These aren’t exotic concepts — they’re choices engineers make every time they stand up infrastructure. The question is whether those choices are being made consciously or by default.
Something that changes behaviour faster than anything else: giving a team ownership of a budget and letting them keep the savings. When a team reduces their spend by twenty percent through rightsizing and retiring idle resources, and that savings gets redirected into headcount or tooling the team actually wanted, cost optimisation stops feeling like a tax and starts feeling like a skill worth developing.
The teams I’ve seen do this well share a few traits. They talk about cost in the same breath as performance and reliability. Their engineers can tell you, roughly, what their services cost to run at a given scale. They review their Reserved Instance coverage and Savings Plans commitments as part of normal planning, not as a crisis response. And their leaders treat a surprising cloud bill as a signal worth investigating — not an embarrassment to manage.
Cloud spend is not a finance problem. It’s a product of thousands of engineering decisions made across your organisation every week. You’re the one who can change the culture around those decisions, and no spreadsheet from finance will do it for you.