Skip to content
iSquareLabsImagination to Implementation
Cloud

Cloud cost is an architecture decision, not a finance one

By the time the invoice arrives, the decision that caused it was made six months earlier. Here is how to move the feedback loop upstream.

iSquare Labs Engineering

18 June 2026 · 9 min read

Cloud cost programmes usually start in finance, which is already too late. The invoice is a lagging indicator of decisions made months earlier by engineers who had no visibility into what those decisions would cost. Optimising the bill afterwards is salvage work.

The structural fix is to move the signal upstream so that the person choosing an instance type, a replication strategy or a data retention window can see the price of that choice while they are still making it. That means per-team tagging, budgets that alert before they are breached, and cost surfaced in the same pull request as the infrastructure change.

This is not primarily a tooling problem. Every major provider offers the data. The problem is that the data sits in a console that engineers have no reason to open, owned by a team with no authority over architecture. The fix is organisational as much as technical.

When we set up a landing zone, cost governance ships with it rather than following later. Accounts map to ownership. Tagging is enforced by policy, not convention. Anomaly alerts route to the team that caused the anomaly, not to a central group that has to go and find out who did.

The result is not dramatic month one. It compounds. Teams that can see the cost of a design choice make different design choices, and after two or three quarters the architecture itself is cheaper — which is a far more durable saving than any amount of reserved-instance arbitrage.

What should we build together?

Tell us the outcome you need and the date it has to land. We will tell you honestly whether we can hit it — and exactly what it will take.

Typical response within one business day · No-obligation architecture review