A tale of cutting costs

I was brought in by a customer who needed to reduce spend. Their Azure bill was growing every month, and nobody could explain why. The built-in tools only gave them surface numbers. What they needed was a way to see actual consumption patterns and how services related to each other.

Gaining Visibility
The first priority was to get beyond the standard Azure portal. The cost analysis blade can show subscription-level charges and break them down by resource group, but it does not explain dependencies or highlight unused services.

We built a visibility stack with:

• Pointfive to map cross-service spend and dependencies. It correlated actual consumption patterns with billing and made hidden chains of resources visible.
• Azure Resource Graph queries to pull resource inventory at scale and identify orphaned services.
• Custom tagging scripts to enforce ownership, so every resource had a clear accountable team.
• Log Analytics with targeted queries to track utilization of expensive resources over time.

Together this gave us a view not just of what was running but also of how those resources were driving spend. Once teams saw data linked directly to their services, the waste stood out.

What We Found
Once the data was in front of us, the issues became clear:

• OpenAI provisioned throughput running in development, costing about $35,000 per month. The provisioned model tier does not auto-scale down, so unless someone actively checks, it continues billing at full rate even when idle.
• Dozens of unused Log Analytics tables. The portal only shows spend at the workspace level, so storage costs from individual tables are hidden. Unless you query the tables directly, you cannot see which ones are driving the bill.
• Machine learning instances left idle after experiments. These VMs stay allocated until deleted or deallocated, and the portal does not flag them as inactive, so they quietly continue charging.

These problems had been invisible in normal reporting and had gone unnoticed for months.

Working Through It
Finding the problems was only half the work. We then had to assign ownership, right-size or shut down waste, and put checks in place to stop it happening again. Each team took responsibility for their own services. We added regular reviews tied to architectural decisions. Old “optimizations” were often increasing costs instead of reducing them, so those had to be unwound.

Updating Processes
Technical fixes will not hold if the organization continues with the same habits. To prevent waste from creeping back, we introduced new guardrails:

• Automated lifecycle policies to deallocate or delete idle VMs after a set period with no activity.
• Spend alerts per environment, so any unexpected increase in cost is flagged quickly.
• Mandatory tagging for ownership, environment, and purpose, with automated enforcement through policies.
• A lightweight approval step before provisioning high-cost resources like ML clusters or provisioned AI throughput.
• Regular reviews of Log Analytics workspaces to confirm which tables are still needed and which can be retired.

These measures were not about adding bureaucracy. They gave teams a clear framework that made cost control automatic rather than reactive.

The Result
It took about four months to implement changes and handle the fallout, but the outcome was a reduction of roughly $280,000 per year. More important than the number was the process. The customer gained clear visibility, accountability, and a way to stop costs from creeping back.

Conclusion
Cost management in cloud is not just about turning things off. It is about putting systems in place that let you see what is happening, question assumptions, and adjust before waste becomes normal.