Your cloud bill is an architecture problem, not a procurement problem

Every cloud cost programme starts the same way: a procurement-led push for commitment discounts and a rightsizing exercise. Both are worth doing and both are one-time. Twelve months later the bill is back where it was, because nothing about the system that generates the spend has changed.

Where the money actually goes

In our audits, three architectural patterns account for the majority of avoidable spend, and none of them show up as a line item you can cancel.

• Always-on capacity sized for a peak that occurs twice a year
• Chatty service boundaries generating inter-AZ traffic that nobody attributes to a feature
• Storage tiers untouched since the first migration — hot storage for data nobody has read in two years

Attribution changes the conversation

Tag everything to a feature or product line, then publish the cost per feature next to its usage. The moment a product owner can see that a rarely used export function costs $9,000 a month in compute, you stop having a cost-cutting argument and start having a product decision. We have watched teams delete features they had defended for years within a week of seeing that number.

The batch job test

Here is a five-minute diagnostic. Find your largest scheduled job. Ask what it costs to keep its infrastructure available for the twenty-three hours a day it is not running. In most estates the answer is between 40% and 70% of that workload's total cost, and the fix — event-driven or scheduled provisioning — is a fortnight of work, not a replatform.

What good looks like

A mature estate has cost as a first-class metric in the same dashboard as latency and error rate, a budget alert that pages someone before the month closes, and an architecture review that asks "what does this cost at 10× volume" as a standard question. None of that requires a FinOps team. It requires the cost data to be visible to the engineers making the decisions.