If a deploy doubled your p99 latency, you would know within minutes and someone would own the fix by lunch. If the same deploy doubled your cloud bill, most organisations find out weeks later, in a spreadsheet, in a meeting the engineers are not invited to. That gap is the whole problem. Cost is a runtime property of your system, exactly like latency — and it deserves the same instrumentation, the same budgets, and the same owners.
The quarterly cost review is a post-mortem
The traditional setup treats cloud spend as a finance artefact: it accrues silently, gets aggregated by account rather than by service, and surfaces once a quarter as a variance to explain. By then the architecture decision that caused the jump has been in production for months and has grown dependencies. Nobody in the room can connect the line item to the commit.
FinOps that lives in finance is archaeology. FinOps that lives in the sprint is engineering: spend per service sits on the same dashboard as error rate and latency, cost anomalies open tickets in the same backlog as bugs, and “why did this service get expensive on Tuesday” is answered by the team that shipped Tuesday’s change — that week, not next quarter.
Put budgets in CI
Performance budgets in CI are normal now: a change that blows the bundle size or the latency envelope fails the check, and the author decides whether the regression is worth it before it merges. Cost deserves identical mechanics.
- Estimate infrastructure diffs — every change to Terraform or Kubernetes manifests gets a projected monthly cost delta posted on the pull request, the same way a coverage report is.
- Give each service an envelope — a monthly spend budget owned by the team, with a failing check when a change is projected to break it.
- Fail loudly, override deliberately — the point is not to block spending. It is to move the conversation to review time, when the change is one click from being undone. A failing check costs a conversation; an invoice costs a quarter.
Right-sizing is hygiene, not a project
An annual “cost optimisation initiative” is a symptom, the way an annual “dependency upgrade project” is. It means the routine work was skipped for a year. The actual work is unglamorous and continuous: the instance class nobody revisited after the traffic pattern changed, the orphaned volumes from deleted environments, log retention set to forever because nobody chose a number, staging clusters running full-size through the weekend.
Treat it like dependency updates: a small, standing slice of every sprint, owned by the team, boring by design. Teams that do this never need the heroic quarterly cleanup, for the same reason teams that patch weekly never need the heroic security sprint.
Cost belongs to the people who own performance
Look at the levers: caching, batching, query shape, instance selection, autoscaling policy, data lifecycle. Every one of them moves cost and performance together. Split the two concerns across different owners and you get two teams pulling the same lever in opposite directions — one adding replicas for latency, the other deleting them for spend, neither seeing the whole trade.
The engineer who profiled the query is the only person who knows whether it genuinely needs that instance class. Give that engineer the cost graph and the budget, and right-sizing stops being a negotiation with a platform team and becomes ordinary engineering judgement.
AI workloads make this worse, faster
Everything above gets sharper the moment inference enters the stack. Token spend is metered per request, so cost now scales with usage and with prompt design at the same time. Retries multiply it silently. Agent loops multiply it geometrically. A one-line prompt change can triple the bill with no functional diff to review.
And AI systems drift into expensive paths on their own: retrieval quietly returns more chunks, a fallback route starts sending traffic to the largest model, context windows creep. This is why our AI practice gives drift, cost and latency explicit budgets, monitored the same way quality is — we wrote about the production discipline in RAG: from demo to production. A cost regression gates a release exactly like a quality regression, because that is what it is.
Latency taught us this already
The industry spent a decade learning that performance cannot be a separate team’s problem, inspected after the fact. Cost is the same lesson with a currency sign. Instrument it per service, budget it in CI, right-size it every sprint, and give it to the engineers who already own the levers.
Our dedicated teams run this discipline as standard — cost on the dashboard next to latency, budgets in the pipeline, no surprise invoices. If your cloud bill is a quarterly mystery, book a technical call, not a sales call.