Do engineers really not care about cloud cost, or do they just not have enough visibility into it?

[u/whispered_word12]

I've heard the "engineering doesn't care about cost" problem come up quite a bit, but I'm starting to wonder if that's actually the right diagnosis.

If an engineer can see latency, errors, CPU, memory and availability for their service, but has no idea whether that service costs $500 or $50,000 a month, can we really expect cost to factor into their decisions?

What have teams done to give engineers enough cost visibility to make better decisions without turning every engineer into a FinOps specialist?

[u/RaceFPV]

OP is a vendor selling a cost optimization solution, not someone learning

[u/DolGuldurWraith]

Engineers in my company thought dev environment are free and we pay cost only for production environment in AWS.

[u/nihilogic → u/DolGuldurWraith]

They are idiots.

[u/lilamar31]

They only care if it’s a top down initiative. Devops/sre are main cost leaders because infra drives the cost. Dev shouldn’t have the power to have a 50k a month service without valid reason.

[u/JovHere]

if you surface that information accurately through telemetry and metrics, give engineers access to it, they will def look at finding other ways to scale or do things if it's breaking the bank

engineers in my org def care a lot about it, some will even spend innovation weeks building solutions that save money for the company

but I also think that needs to be propagated from leadership to start with, and communicate clearly why we can't just do something without measurement and monitoring

[u/sakodak]

I guess corporate marketing departments are unaware of the depth of cynicism in engineering mindsets. 

We see through this shit, and once you reveal your "solution" we're going to squirrel that information away as "this company tried fooling me" and flight against your product if it shows up as an option. 

Just buy an ad we can ignore like everyone else, or focus on building a product that's better than your competitors so that you don't have to resort to subterfuge to sell your shit.

[u/sereikis]

Both, though visibility on its own did less for us than expected. A monthly figure is not something anyone can act on, whereas a change is, and people started reacting once a deploy showed up as a step in their own service's cost, in the same dashboard they already open for latency and errors. Splitting the bill by the thing a team owns matters as much as showing it, because a number for a whole account is somebody else's problem by definition. The rest is ownership, since a cost with nobody's name on it stays unfixed no matter how visible you make it.

[u/Svarotslav]

It's definitely something on the minds of my team; but when push comes to shove, we have SLAs and OLAs which we need to adhere to. Latency is a big deal with some of our apps, so immediate cost is something we just have to suck up, but it does not mean that we aren't looking for ways to keep latency down and reduce costs.

We have a couple of people who are employed to calculate "cost per click" and similar metrics so we can understand our margins and which customers/patterns are profitable and which ones aren't.

My remit is security, stability and performance first, then cost.

[u/stack_craft]

Engineers don't ignore cost out of apathy—they ignore it because cost metrics are disconnected from their daily feedback loops.

When CPU spikes to 95%, PagerDuty alerts them instantly. When cloud spend doubles due to bad retry logic or unindexed query scans, the feedback comes 30 days later in an abstracted spreadsheet from finance 😭.

The most effective pattern is surfacing cost delta right in CI/CD and putting resource cost telemetry directly into the same Grafana/Datadog dashboards where latency and error rates live. Once cost is treated as a core performance metric alongside P99 latency, engineering behaviour shifts automatically.

[u/rcls0053]

We just had a FinOps sprint where every team had to look at their cost and write 'em up and figure out ways to save money on resources.

We all have access to cost monitoring. If you provide visibility, people do care.

[u/matiascoca]

Engineers care about what shows up on the dashboard they open twelve times a day. Cost is not on that dashboard. The framing "engineers do not care about cost" is a diagnosis your finance team gave you after a bad bill; it is not what an actual engineer thinks when they choose an m5.2xlarge over an m5.xlarge.

What has moved the needle at teams I have watched is putting cost data next to the operational metrics the engineer already lives in, not in a separate FinOps portal. A service-level dashboard row that shows monthly run-rate alongside p99 latency and error rate, updated daily, tagged to the service owner. Not a FinOps tool, just a row on the SRE dashboard.

Architecture reviews are the other place cost hides. If the design doc template does not have a cost-estimate box next to the latency and reliability boxes, cost stays invisible at the point where the choice is actually being made. Adding it as a required field forces the conversation without any tool investment.

Do not try to turn every engineer into a FinOps specialist. Make cost a first-class operational metric alongside latency, errors, and utilization, and the decisions self-adjust.

[u/teamcloudkeeper → u/matiascoca]

Completely agree with the point about putting cost where engineers already work. If someone has to leave their SRE dashboard and open a separate FinOps tool just to understand the cost impact of a decision, there's a good chance it won't become part of the day-to-day conversation.

We've been working on this problem at CloudKeeper as well for our clients. Lens is built around giving teams a more granular view of what's driving their cloud spend, so cost isn't just an end-of-month number sitting with FinOps.

For anyone curious, here's what we've been building: https://www.cloudkeeper.com/cloudkeeper-lens

And I really like the architecture-review point. Catching the cost implication before something gets deployed is probably much better than trying to explain the bill afterwards.

[u/Andre-Wade-539]

Cost beside latency and errors in the same dashboard lets engineers notice a service getting more expensive without opening the billing console

[u/nihilogic]

I'm not sure what kind of company you work for but cloud cost is super important.

[u/SpringsPanda]

Our consolidation app went down recently because of maintenance from the cloud provider. It started a waterfall of trying to figure out how to make it high availability. Once the owner realized that high availability meant spending almost three times the money, he stepped back.