Picture the quarterly cost review.
Someone shares the dashboard, the bar chart loads, and everyone looks at the same place: the top.
"Compute is 62% of the bill. Start there."
It is the obvious instinct, and it is usually the wrong place to start.
A cost ranking answers one question: where does the money go. It does not answer the question you actually care about: where is the money wasted.
Those are different questions, and only one of them has an action attached.
The top of the chart is load-bearing
Your largest service is normally largest because it is doing the most work.
Production compute is expensive because production is where the traffic is. The database is expensive because it holds the data everyone queries. Egress is expensive because customers are downloading the thing you sell them.
That spend is not waste. It is the product.
You can still optimise it. Commitments, instance families, storage tiers, better query patterns. All real. But the realistic saving on a heavily utilised, already committed compute line is a few percent, and it costs weeks of engineering time and a load of risk to get there.
Meanwhile, further down the same chart, there are lines where the realistic saving is one hundred percent and the risk is a delete button.
Waste is not the same thing as expensive
Waste is not "this costs a lot". Waste is "we are paying for this and nothing needs it".
That shows up in three shapes, and none of them sort to the top of a service breakdown.
Nothing is using it
A managed disk detached from a VM that was decommissioned six months ago. A public IP reserved for a load balancer that no longer exists. A NAT gateway with no subnets routed through it. An App Service plan on a dedicated tier hosting zero apps. A private DNS zone that nothing resolves against. A SQL elastic pool with no databases in it.
Each bills on a schedule, quietly, forever. Each is individually small. None will ever appear near the top of a service chart, because they are spread across storage, networking, compute and database, and each contributes only a slice.
But the removable percentage on every one of them is one hundred.
That is the number worth ranking by. Eighty dollars a month where all of it is removable beats forty thousand dollars a month where three percent is.
Something is using it, barely
This one hides best, because the resource is genuinely in use. It is just wildly over-specified.
A Kubernetes workload requests 2 CPU and 4 GiB per replica. Over the last thirty days, its p95 of daily peaks is 0.3 CPU and 900 MiB.
The cloud bills you for the node either way. But the request reserves capacity on that node that nothing else can schedule onto, so the workload carries the cost of 2 CPU and 4 GiB in any honest attribution, and whatever nobody requested at all shows up as idle capacity you are also paying for.
Nothing is broken. Nothing is anomalous. No spike, no alert, no incident. The configuration is simply six times larger than the workload needs, every hour of every day.
It only needs to exist part of the time
The staging environment running at full size through the weekend. The batch worker sized for a nightly job that spends twenty-two hours a day idle. The host service whose CPU peak has not crossed a fraction of a core in three weeks while its share of the VM keeps accruing.
The cost is justified for the hours the work happens. It is not justified for the hours it does not.
Rank by removable dollars
For any line, removable dollars is roughly:
current cost x the share you could actually remove x how confident you are in that share
The share is different for each shape:
- Orphaned resources: the share is 1.0. Nothing is attached, so there is nothing to break. Confidence comes from how much of the observation window you actually watched it bill.
- Over-provisioned workloads: the share is
1 - (observed peak + headroom) / requested. Confidence comes from how many distinct days of usage you have, not from a single reading. - Idle or schedulable capacity: the share is the fraction of hours nobody needs it running.
Sorted that way, the list looks nothing like the cost chart. Resources you have never thought about move to the top, and the compute line everyone wanted to attack drops to somewhere around fifteenth.
The small findings are not small together
The objection is predictable. "That unattached disk is nineteen dollars a month. Who cares."
On its own, nobody. In aggregate, it is a different conversation.
A first production run of orphaned resource detection against a single Azure tenant surfaced 73 findings worth roughly $1,687 a month. Not one of those resources belonged to a service in the top ten by spend. Ten unlinked private DNS zones at fifty cents each is real money that no cost chart will draw your eye toward, because five dollars does not render as a visible bar next to forty thousand.
Which is why a detection floor set at some tidy threshold is a mistake. The value is in the sum, and the sum is invisible unless you count the small things.
How to look instead
Start from resources, not services. A service total aggregates hundreds of resources with wildly different utilisation. The aggregate cannot tell you which of them is doing nothing.
Ask what is attached, not what it costs. Orphan detection is a graph question, not a billing question. Which disks have no owner, which gateways have no connections, which plans host no sites. Join that answer to the bill afterwards to find out what it is worth.
Compare requests to usage across a window, not a snapshot. A single reading at 3am makes everything look idle. A single reading at peak makes everything look healthy. A percentile of daily peaks over thirty days is the smallest honest unit of evidence.
The question for the next review
Not "what is our most expensive service?"
Ask: for each of our top twenty lines, how much of it could we remove tomorrow without anyone noticing?
The biggest number on the chart usually answers close to zero. Something much further down answers one hundred.
CostOptix ranks findings by what you can remove, not by what you spend. Every saving figure comes from your sealed daily cost ledger rather than list price, so the number you see is the number you were billed.
See it running on live multi-cloud data at demo.costoptix.com, read-only and no signup required.
Start free, no credit card required.