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 — some require peak sizing, particularly anything with hard latency SLAs. Most do not. 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.
“We haven’t got round to it” is not a reason. It is a cost. The savings available by moving stable workloads to committed pricing are significant — typically in the range of 30–50% on compute alone. That is not a technical optimisation; it is a procurement decision that requires someone with authority to make it.
[DAN: Add a note about the typical size of saving when you’ve moved a stable workload off pay-as-you-go — even an order of magnitude. This is the number that gets CTOs to ask the question.]
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, 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. The number might be excellent. It might be alarming. Without the denominator, nobody knows.
This question is harder to answer than the first two — and that difficulty is itself useful information. If a team cannot answer it, they are not managing cost; they are managing a budget line.
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 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.
