Azure cost · field note
We cut a client's Azure bill by 65%. Here's why that number was available.
The percentage makes a good headline. The useful part is understanding how a functioning production environment became expensive enough for that saving to exist.
We did not discover a secret Microsoft discount. We found an Azure estate that had been provisioned for urgency, protected from cost pressure, and then left without a deliberate second pass.
That distinction matters. If I only tell you we cut a client's Azure bill by 65%, you can reasonably assume one of two things: the original setup was reckless, or the final setup was fragile. Neither was true.
The original decisions were understandable when they were made. The company had grant funding, deadlines, and a product to ship. Capacity was cheap compared with delay. What changed was the context—not the infrastructure. Funding stopped cushioning the bill, production patterns became clearer, and yesterday's safety margin became today's fixed overhead.
01 / The headline
65% was not a pricing trick
A cost reduction that large rarely comes from one dramatic deletion. It comes from several ordinary decisions compounding: a generous VM here, an App Service Plan sized for a launch there, a database tier nobody revisits, a disk that outlives its machine, and a test environment that quietly becomes permanent.
Each line item looks defensible in isolation. The total is not.
This is a real result, documented in the full Azure cost reduction case study. It is not a universal savings promise. An efficient estate may have 5% available. A neglected one may have far more.
02 / The mechanism
The waste did not arrive wearing a name badge
The person choosing capacity was not the person who would eventually feel the bill. That is common in grant-funded and investor-funded infrastructure. The delivery team is rewarded for making the application work now. The economic consequence arrives later, often under different leadership.
Azure also makes expansion easier than contraction. Scaling up takes minutes and feels safe. Scaling down requires context: what runs here, when does it peak, who owns it, and what happens if the margin disappears? Without an owner for those questions, the higher SKU becomes the new normal.
Buy enough capacity to remove delivery uncertainty.
The temporary safety margin becomes permanent infrastructure.
Nobody wants to resize a resource they cannot confidently explain.
The estate has not suddenly become wasteful. The waste has become painful.
03 / The estate
The money was spread across the environment
We found savings in the unglamorous places: compute with far more headroom than the workload used, hosting plans carrying capacity their apps did not need, database tiers inherited from an earlier phase, and detached or forgotten supporting resources.
- Oversized compute: VMs and App Service capacity provisioned for possible demand rather than observed demand.
- Stale service tiers: databases and platform services still priced for an old performance assumption.
- Orphaned resources: disks, snapshots, public IPs, and supporting components that no longer served a live workload.
- Duplicate safety margins: extra capacity at several layers, each independently justified as protection.
- No economic owner: technical ownership existed, but nobody was accountable for the relationship between cost and business value.
This is why a useful Azure cost review cannot stop at “top services by spend.” The invoice tells you where money landed. It does not tell you why the resource exists or whether the business still needs what it buys.
04 / The work
We put every meaningful line item on trial
The working session was simple and occasionally uncomfortable. Resource by resource, we asked: What is it? Who owns it? What depends on it? What demand does it actually see? What is the smallest safe change? How do we reverse that change?
We removed things that were demonstrably unused. We rightsized services where representative metrics and workload knowledge agreed. We changed tiers where the original performance assumption no longer applied. And we did it in a sequence that separated easy, reversible savings from production-sensitive changes.
- Establish a clean cost and utilisation baseline.
- Assign a workload and owner to every material resource.
- Remove abandoned resources with clear evidence.
- Rightsize active services and validate the new baseline.
- Only then evaluate Reservations or Savings Plans.
That fourth step is where context beats automation. Azure Advisor can identify an oversized VM. It cannot tell you whether that VM closes payroll, runs a month-end batch, or holds a dependency nobody documented.
05 / The safety
The objective was not a smaller bill. It was a smaller bill with the same business outcome.
Cost work becomes dangerous when the percentage is the only target. The cheapest architecture is the one that does not run. That is not optimisation; it is deletion.
We protected the outcome by treating each change as an operational decision. We checked real usage windows, business peaks, application dependencies, service limits, and rollback options. The client's team applied the plan with context, not a blind list of recommendations. Nothing broke because the change sequence respected the workload.
The same logic is why Reservations should come after rightsizing. A discount can make the wrong shape cheaper, but it cannot make the shape right.
06 / The takeaway
A large saving is usually evidence of a missing management loop
The 65% was available because provisioning had an event, but optimisation did not. Resources were approved, deployed, and kept alive. Nobody had installed the recurring loop that asks whether capacity still matches reality.
That is the durable fix: cost allocation, ownership, representative metrics, regular rightsizing, expiration rules for temporary resources, and a safe change process. Use the Azure waste calculator for an initial estimate if you need one. Then replace estimates with evidence.
Primary references
Sources and further reading
- Microsoft: Start using Cost Analysis — official guidance for analysing Azure cost and usage
- Microsoft Azure Well-Architected Framework: Cost Optimization — principles for aligning workload cost with business value
- Microsoft: Azure Advisor cost recommendations — how Advisor identifies potential cost opportunities
Questions teams ask
Frequently asked questions
Is a 65% Azure cost reduction normal?
No. A 65% reduction is an unusually large result, not a benchmark to promise every company. It was possible here because several years of overprovisioning, stale resources, oversized services, and weak cost ownership had accumulated in the same environment.
How do you reduce an Azure bill without creating production risk?
Start with billed resources, map each one to its owner and workload, review representative utilisation and dependencies, and rank changes by value and operational risk. Make reversible changes first, monitor the result, and keep an explicit rollback path for production rightsizing.
What usually creates the biggest Azure savings?
The largest savings often come from correcting the operating model: oversized compute, idle App Service capacity, excessive database tiers, orphaned disks and IPs, duplicate environments, and commitments bought against the wrong baseline. The exact mix varies by workload.
Should Azure Reservations be part of a cost reduction project?
Often, but only after rightsizing and validating the new baseline. A reservation discounts a quantity of usage; it does not make an oversized resource efficient.