You can take a third off most cloud bills before you ever touch what is actually running. No service restarts. No architecture changes. No performance degradation. The savings come entirely from the gap between what you're paying and what the same infrastructure should cost — a gap that opens the moment you start provisioning under delivery pressure and never systematically close it.
I did exactly this for a Series B insurtech running on Azure. Spend was €112,000 per month. After six weeks of focused FinOps work — no workloads stopped, no environments altered — the run rate dropped to €69,000. That is 38.4% recovered. The CFO asked why it had taken this long to find. The honest answer: nobody was looking.
The Three Levers That Account for Almost All of It
Cloud cost optimisation is discussed as if it requires deep expertise and months of sustained effort. In practice, 90% of recoverable savings come from three straightforward levers. The complexity is in execution discipline, not the concepts.
Lever 1: Commit to what you're already running. Lever 2: Rightsize what you provisioned for peak, not average load. Lever 3: Kill what nobody is using.
Everything else — refactoring to serverless, storage tiering, egress optimisation, caching layers — is real but marginal until you've captured these three. The order matters: do these first, then optimise architecture. Teams that go straight to architectural changes while still paying pay-as-you-go rates at a 40% premium have their priorities inverted.
The audit sequence flows in one direction — each lever builds on the one before:
Lever 1: Commit to What You're Already Running
This is the largest single savings category in almost every audit I run, and it requires zero engineering work.
Azure's pay-as-you-go pricing carries a 39–58% premium over 1-year and 3-year Reserved Instances for identical SKUs. If a workload has been running for six months and you have no reason to believe it will disappear in the next twelve, you are paying 39% more than necessary for that compute. There is no technical justification for this — it is a procurement decision that has not been made.
| VM SKU | Pay-as-you-go (West Europe) | 1-year RI | Saving | 3-year RI | Saving |
|---|---|---|---|---|---|
| Standard_D4s_v4 | ~€130/mo | ~€80/mo | 38% | ~€55/mo | 58% |
| Standard_D8s_v4 | ~€260/mo | ~€160/mo | 38% | ~€110/mo | 58% |
| Standard_D16s_v4 | ~€520/mo | ~€320/mo | 38% | ~€220/mo | 58% |
| Standard_E8s_v4 | ~€370/mo | ~€225/mo | 39% | ~€155/mo | 58% |
In the insurtech engagement, 68 VMs and 12 Azure SQL databases were running entirely on pay-as-you-go. The team had never purchased a Reserved Instance. They had provisioned quickly under delivery pressure and never revisited the purchasing model. Committing 52 of those VMs and 8 databases to 1-year Reserved Instances — the ones with more than six months of stable history — recovered €21,400 per month from this category alone.
Azure Hybrid Benefit stacks on top of Reserved Instances
If your organisation holds active Windows Server or SQL Server licences through an Enterprise Agreement or Software Assurance, Azure Hybrid Benefit lets you apply those licences to Azure VMs and Azure SQL. This removes an additional 20–40% from the compute price — and it stacks on top of Reserved Instance pricing. For an enterprise already paying for Windows Server licences, not enabling Hybrid Benefit is equivalent to buying the same licence twice. In this engagement, Hybrid Benefit added €4,200/month in savings on top of the Reserved Instance conversion.
How to approach the commitment decision
Reserved Instances feel like a risk to engineering teams who haven't made them before. They should not. The question to ask is not "are we sure we'll need this VM in 12 months?" but "has this VM been running continuously for the last 6 months?" If the answer is yes, the commitment risk is near-zero. Azure also allows RI exchanges within the same VM family, so you're not locked to a specific SKU if you rightsize during the year.
The practical approach I use: pull Azure Cost Management's reservation recommendations (under Reservations in the portal). Microsoft's own tool identifies which VMs and databases have sufficient utilisation history to justify commitment. Start with a 1-year term on anything above 70% recommendation confidence.
Lever 2: Rightsize What Was Provisioned for Peak
The second-largest category. Engineers provision for peak load — worst-case concurrency, load test conditions, "future growth headroom." Production systems then run at a fraction of that capacity for the other 90% of their lives.
Azure Advisor surfaces CPU and memory utilisation data over a 7-day or 30-day window and produces automatic rightsizing recommendations. In a typical first audit, I see 40–60% of VMs with average CPU utilisation below 20%. That is not a sign of good capacity planning — it is oversized infrastructure running at idle.
The rightsizing impact per VM depends on SKU, but a common pattern:
- Standard_D8s_v4 at 14% average CPU should be Standard_D4s_v4 — saving ~€100/month per VM
- Standard_D16s_v4 at 18% average CPU should be Standard_D8s_v4 — saving ~€200/month per VM
- Standard_E16s_v4 (memory-optimised) at 22% CPU and 30% memory should be Standard_E8s_v4 — saving ~€250/month per VM
In the insurtech engagement, 24 VMs were flagged and 18 were rightsized after the engineering team reviewed Azure Advisor's recommendations. Monthly saving: €9,800. The two-hour effort to review and action the recommendations was the highest-ROI two hours the team spent that month.
Don't rightsize without a performance baseline first
Before downsizing a VM, capture its p95 and p99 CPU and memory metrics over a 30-day period — not just the 7-day Advisor window. Some workloads are bursty: average utilisation is low, but peak load hits hard during specific windows. Rightsize based on the 30-day peak, not the average. I've seen teams rightsize a batch processing VM based on its average utilisation, then discover the nightly ETL job was now timing out at reduced capacity.
AKS node pools deserve their own pass
Kubernetes environments deserve special attention because node pool sizing is often driven by initial cluster setup decisions, not sustained load data. In most AKS environments I see, the default node pool is a Standard_D8s_v4 or larger with manual scaling, and the actual pod utilisation hovers at 25–35% of allocated capacity.
Two adjustments compound effectively here: switching to Standard_D4s_v4 nodes (doubling node count, halving individual cost — often equivalent total) combined with enabling the Cluster Autoscaler with an aggressive scale-down threshold. Most AKS clusters can shed 30–40% of their node costs with autoscaling properly configured and scale-down delay set to 10 minutes rather than the default 10 minutes of grace that many teams extend to 30 or 60 to avoid perceived instability.
Lever 3: Delete What Nobody Is Using
This category is less dramatic than Reserved Instances or rightsizing, but it is embarrassing — and entirely avoidable. In every environment I audit that is older than 12 months, I find orphaned resources accumulating billing charges for work nobody is doing.
The most common culprits:
Unattached managed disks. When a VM is deleted, Azure does not automatically delete attached managed disks unless delete_os_disk_on_vm_delete was explicitly set. Teams delete VMs; the 1TB Premium SSD persists and bills at approximately €170/month. In one environment I audited, there were 23 unattached managed disks — €2,800/month for storage nobody was using.
Unassociated public IP addresses. Static public IPs in Azure bill continuously whether or not they're attached to a resource. After VM deletions, load balancer reconfigurations, and failed deployments, public IPs accumulate. Each costs approximately €3.50/month — small individually, but I routinely find 50–100 unassociated IPs in an environment that has been running for 18 months.
Stopped VMs. A common misconception: stopped VMs do not bill for compute. True — but a VM that is in a "Stopped" state (not "Deallocated") still holds its IP allocation and its OS disk still bills. Teams stop VMs with the Azure Portal's Stop button thinking they've stopped the billing. They haven't. Deallocate or delete.
Stale dev and test environments. The developer test environment created in July for a feature that shipped in September is still running in March. At €400/month, it has cost €2,400 for nothing. Without automated lifecycle policies with expiry tags and automated shutdown schedules, these accumulate without end.
In the insurtech engagement, Lever 3 recovered €4,600/month. Not the biggest category — but it was the fastest to action. Most orphaned resource cleanup takes a single half-day sprint.
The Full Picture: Where the 38% Came From
| Lever | Action | Monthly saving |
|---|---|---|
| Commitments | Reserved Instances on 52 VMs and 8 databases | €21,400 |
| Commitments | Azure Hybrid Benefit on Windows VMs and SQL | €4,200 |
| Rightsizing | 18 VMs downsized per Advisor recommendations | €9,800 |
| Rightsizing | AKS autoscaler + node pool resize | €3,000 |
| Lifecycle | Orphaned disk and IP cleanup | €2,800 |
| Lifecycle | Dev environment shutdown schedules | €1,800 |
| Total | €43,000 |
No downtime. No architecture changes. No capacity reduction during peak hours. The €112,000 bill was not the cost of the workload — it was the cost of the workload plus the accumulated tax of every provisioning decision made under delivery pressure that was never reviewed.
Why This Keeps Happening
Cloud bills grow in the dark. Provisioning is fast and easy; reviewing cost is slow and boring. Engineers are incentivised to ship features, not to audit infrastructure spend. Finance sees the invoice monthly and escalates; engineering is surprised quarterly.
The pattern breaks when cloud cost becomes a first-class engineering metric — visible in the same dashboards as reliability and performance, owned by the same engineering leads who own service quality, reviewed in the same weekly rituals as deployment frequency.
The CFO can see it; the engineering team cannot
In almost every organisation I work with, finance has Azure Cost Management alerts and can see spend trending upward. Engineering does not have cost visibility at the team or service level. The people making provisioning decisions — engineers choosing VM sizes, spinning up environments — are operating in a cost vacuum. That vacuum is the root cause. Fixing it requires team-level cost dashboards, not a quarterly finance review.
The teams that maintain their optimised cost posture — that don't drift back to €112,000 in eighteen months — are the ones that implement three governance mechanisms: enforced tagging at subscription level so every euro of spend is attributed, a monthly rightsizing review with engineering-lead accountability, and a quarterly Reserved Instance commitment review as a scheduled finance-engineering meeting.
None of this is technically difficult. It requires organisational will to treat cost as an engineering concern, not a finance afterthought.
If you've got a cloud bill that's grown past the point where you know what's driving it, or you suspect there's significant recoverable spend but don't have the bandwidth to find it systematically, let's talk. I run a focused FinOps audit in the first two weeks and put a prioritised savings roadmap in your hands before the end of the month. Book a 30-minute discovery call.