Most organisations treat infrastructure cost as a finance problem. The monthly cloud bill arrives, finance investigates, engineering gets a memo asking for "cost optimisation," and for two weeks everyone is conscious of their resource usage. Then the cycle repeats.
This approach has a fundamental flaw: the people who receive the bill (finance) are not the people who made the decisions that created the bill (engineers). And the people who made the decisions made them weeks or months ago, in a context they no longer remember, without any visibility into the cost implications at the time.
The fix is conceptually simple: put cost information where engineering decisions are made. For modern software teams, that means the CI/CD pipeline.
The feedback loop that changes behaviour
When an engineer opens a pull request that changes a Kubernetes deployment manifest — increasing replica count, upgrading to a larger instance type, adding a new sidecar container — they are making a cost decision. They almost certainly don't think of it that way. They're solving an application problem.
Now imagine that the CI pipeline runs a cost estimate and posts a comment on the PR:
The engineer now has the information they need to make a decision. They can ask: is the performance improvement worth twice the cost? Can I achieve the same result with 4 replicas instead of 6? Should I talk to my team lead before merging this?
None of this stops the engineer from merging the change. It gives them information. That is the entire intervention — information, at the moment when it is useful.
Three things that happen when you do this
1. Engineers start thinking about cost as a design parameter
Within weeks of deploying cost estimates in pull requests, we consistently see the same pattern in our customer deployments: engineers start designing around cost efficiency without being asked. They choose smaller instance types when they can. They set appropriate resource requests. They ask whether they actually need the replica count they were about to set. This is not because they're being forced to — it's because they now have the context to make informed tradeoffs.
2. Budget conversations move from retrospective to prospective
Cost reviews stop being "why was last month's bill so high?" and start being "this planned change to the payments service will cost an extra ₹18,400/month — do we approve it?" Finance and engineering are now having the same conversation, about the same decision, at the same time. The budget review cadence doesn't have to change; the quality of the conversation changes entirely.
3. Cost anomalies are caught before they compound
A misconfigured deployment that consumes 10x expected resources will appear as a large cost delta in the CI pipeline at deployment time. In the traditional model, it appears as a line item in the monthly bill three to four weeks later, by which time it has been running at 10x cost for the entire period. Early detection is not a marginal improvement. It is the difference between a ₹50,000 anomaly and a ₹15,00,000 one.
What the implementation looks like
AravaliStack implements this through a combination of OpenCost (for resource pricing data), Kubernetes resource request parsing (from the manifest diff), and a pipeline plugin that calculates the delta and posts the comment.
The key implementation decisions:
- Use resource requests, not limits. Limits are theoretical maximums. Requests are what the scheduler actually allocates. Cost should be calculated on what the cluster commits, not what the application might theoretically consume.
- Show the delta, not just the absolute cost. An engineer doesn't need to know the total cost of every deployment. They need to know what their change adds. The delta is the signal.
- Show budget status. The delta is meaningless without context. Knowing that you're spending an extra ₹18,400/month means something very different if you have ₹10,000 remaining in your budget versus ₹2,00,000 remaining.
- Don't block deploys on cost. Information, not gates. Gates create resentment and workarounds. Information creates culture change. (Exception: if a change would breach a hard budget limit, the pipeline can post a warning that requires explicit override — but this should be rare by design.)
Extending it to AI workloads
As LLM-based features become part of enterprise applications, the same principle extends to AI inference costs. An engineer adding a "summarise this document" feature backed by an LLM inference call should see, in their PR, an estimate of the token cost at the expected usage volume.
This is increasingly important: at scale, LLM inference costs can easily exceed compute infrastructure costs. An enterprise application making 500,000 LLM API calls per day at ₹0.15 per call is spending ₹75,000 per day on inference alone — a cost that is completely invisible in the traditional model until it appears on the bill.
Infrastructure cost is an engineering problem that has been delegated to finance for decades. The right fix is not better financial reporting — it is better engineering feedback loops. The CI/CD pipeline is where engineers spend their time. That is where cost information belongs.