A platform's cloud spend has grown faster than traffic for six consecutive quarters, with no single service responsible. What governance changes address this, and why do purely technical optimisations fail to hold?

Why cost grows faster than traffic

Because the default direction of every individual decision is upward, and nothing pushes back:

• Instances sized for peak and never revisited after the peak moved.
• Environments created for a project that ended, still running.
• Log and metric retention set to the maximum "just in case", growing with traffic and with cardinality.
• Data transfer between zones and regions that nobody attributed to a design decision.
• Storage accumulating because deletion requires someone to decide it is safe.
• Redundancy added incrementally by different people for different incidents, never rationalised.

None of these is a mistake. Each was a reasonable local decision. The aggregate is a cost curve that outruns growth.

Why technical optimisation alone does not hold

A cost-reduction sprint finds savings, applies them, and celebrates. Six months later the spend is back, because the mechanism that produced the growth is untouched. Optimisation removes accumulated waste; governance changes the rate at which new waste accumulates. Only the second one persists.

The governance changes that work

1. Attribution before anything else. Every resource tagged to a team and a product, enforced at creation — untagged resources are blocked or automatically flagged for deletion. Without attribution, cost is a single number nobody owns, and everything downstream is impossible.

2. Cost visible to the teams that create it, continuously. Not a monthly finance report. A dashboard in the team's own space, updated daily, showing their spend and its trend. Most reduction comes from engineers seeing a number they did not expect.

3. Unit economics rather than absolute spend. Cost per request, per active user, per gigabyte processed. Absolute spend should grow with the business; unit cost should not. This reframes the conversation from "spend less" — which conflicts with growth — to "improve efficiency", which does not, and is the single most important framing change.

4. Budgets with alerts owned by engineering, not finance. A team that learns in week two that it is tracking 40% over can act. A team that learns in the following quarter cannot.

5. Automated waste removal. Unattached volumes, idle load balancers, orphaned snapshots, stopped instances still holding storage, non-production environments running overnight. Automate the reclamation rather than raising tickets, because tickets do not get closed.

6. Cost as an explicit input to architecture review. New designs state their expected cost at projected volume. This catches the expensive decision before it ships, which is orders of magnitude cheaper than catching it afterwards.

7. Retention policies with defaults that expire. Observability data especially — telemetry cost grows with both traffic and cardinality, and it is the line item that most often doubles without anyone deciding it should.

The organisational point

Cost is a design property, like latency and availability. Teams that cannot see their cost cannot manage it, and teams that are told to reduce cost without owning the number will optimise the wrong things. The governance objective is not to spend less; it is to make the cost of a decision visible to the person making it, at the moment they make it.