Most Azure cost problems are invisible to leadership until a bill arrives that needs explaining. By that point, the decisions that caused it were made months ago — in architecture reviews, sprint planning sessions, or procurement conversations that the CTO was never in.
Three questions, asked consistently, surface most of those problems before they become budget conversations.
1. Is This Sized for Peak Demand or Average Demand?
Almost every Azure service can be configured for the worst case or the typical case. Services sized for peak run at full cost 24 hours a day, even when demand is a fraction of that.
The right answer depends on the workload. When a workload owner cannot answer this question, that is itself the answer: nobody has made the sizing decision deliberately. It was made once, at deployment, and never revisited.
2. Is This Still on Pay-as-You-Go, and If So, Why?
Pay-as-you-go is the right choice for new and changing workloads — and a costly default for stable ones. If a workload has been running unchanged for more than six months, there should be a specific reason it is not on committed pricing.
The Cost of Hesitation: I’ve seen stable production environments where simply moving from Pay-as-You-Go to a 3-year Reserved Instance slashed the compute bill by over 60% overnight. For a medium-sized enterprise, that’s not just a rounding error; it’s often the equivalent of £100k+ in annual savings that was previously being set on fire for the sake of “flexibility” that nobody was actually using.
3. What Does It Cost per Unit of Business Output?
The total Azure cost of a workload is a number. Cost per transaction, cost per customer, or cost per API call — those are metrics.
When a workload costs £10,000 per month but nobody knows the cost per unit, the organisation cannot make an informed decision about whether that spend is justified. If a team cannot answer this, they are not managing cost; they are managing a budget line.
Why This Matters
These questions do not require technical knowledge to ask. They require that someone with authority is asking them consistently. The teams that answer them well have already thought through cost as part of the design. The teams that struggle with them have not — and that is where the architecture conversation needs to go.
If these questions are surfacing problems in your organisation, get in touch — they are solvable architecture problems, not permanent budget lines.
