The 34% number, and why it is achievable for almost every mid-market estate
A mid-market SaaS client arrived with an Azure monthly spend around USD 180,000 and a recently appointed CFO who had read three FinOps blog posts and a McKinsey report. The CFO's ask was straightforward: prove the cloud spend is under control. The engineering team's position, equally straightforward, was that it already was. The truth, as usual, sat between them.
Over 90 days we delivered 34 percent in annualised savings against the run-rate at engagement start. Nothing in what we did was novel. The playbook is mostly public. What separated this engagement from the dozen others where we have seen the same numbers is sequencing and discipline, not ingenuity. This piece walks through what we actually did, in the order we did it, with the specific decisions that moved the dial.
For context: the client was running roughly 60 percent on virtual machines and managed databases, 25 percent on App Service and AKS, 10 percent on storage and bandwidth, and the remainder spread across PaaS data services, monitoring and miscellaneous. Multi-region across Azure UAE North and West Europe. Production, non-production-with-prod-data, and three separate development environments. A reasonably typical mid-market Azure estate.
Why most cloud cost programmes fail
The instinctive reaction to a cloud overspend is behavioural. Tag everything. Train the engineers. Build a culture of cost-awareness. Send weekly reports. These are all reasonable things to do. They are also, in most mid-market estates, where about 30 percent of the savings live, and they take six to twelve months to deliver.
The other 70 percent is structural. Right-sizing, commitment-based pricing, lifecycle automation. None of it requires culture change. All of it can ship in 90 days. The reason most cloud cost programmes underperform is they invert this order: they spend the first quarter building a tagging strategy and an engineering culture, and the structural fixes that would have produced visible value land later. The CFO loses patience. The programme stalls.
The order that works in practice is structural first, behavioural second. Get the visible wins on the board. Use the credibility to fund the longer-cycle behavioural work.
Lever 1: Right-sizing produced the largest single saving
The mid-market Azure estate we audited was running about 38 percent over-provisioned on compute. This is not an outlier. Most mid-market estates we walk into are between 25 and 50 percent over-provisioned on virtual machines, and between 30 and 60 percent over-provisioned on database SKUs.
The audit took four working days. Azure Advisor surfaces right-sizing candidates with a 14-day data window, but the recommendations need engineering judgement before action. Some workloads are seasonal and the 14-day window misses peaks. Some workloads have specific I/O profiles where downsizing the VM SKU degrades I/O performance non-linearly. Some are legitimately over-provisioned by design (the application owner asked for headroom). The right-sizing pass needs an engineer who can read the workload, not just an Advisor dump.
After the audit, we ran a phased right-sizing programme over three weeks. Non-production environments first (faster to verify, lower blast radius). Then production tier-3 workloads. Then production tier-2. Production tier-1 workloads were excluded from this pass. Those go into a separate workstream with the application owner because the risk-reward is different.
The right-sizing programme delivered around USD 27,000 in monthly savings, by itself almost half the eventual 34 percent number.
Lever 2: Reserved Instances and Savings Plans
The client had zero Reserved Instances and zero Savings Plans at engagement start. Their entire estate was running pay-as-you-go pricing. This is bizarrely common in mid-market estates that grew organically. The team that built the environment two years ago was focused on getting the workloads running, and the commitment-based pricing decision got deferred.
The decision framework for commitments is not complicated. For workloads with stable utilisation patterns over a 1-year horizon, 1-year Reserved Instances deliver about 30 to 40 percent savings versus pay-as-you-go on the equivalent compute. For workloads with stable utilisation over 3 years, 3-year Reserved Instances deliver about 55 percent savings. Azure Savings Plans (a more flexible alternative introduced in 2022) deliver slightly less savings than RIs but allow workload migration between SKUs without forfeiture.
After the right-sizing pass, the remaining stable workloads got Azure Savings Plans on a 1-year term. We did not go to 3 years for two reasons: the client's 3-year roadmap was uncertain enough that the commitment risk was real, and the additional savings from year 2 to year 3 are smaller than the savings from year 0 to year 1.
Savings Plans delivered around USD 14,000 in monthly savings on top of the right-sizing work.
Lever 3: Shutdown schedules for non-production
Non-production environments run 24/7 in most mid-market estates. They are used during working hours by an engineering team in one or two time zones. They run on weekends because nobody set up the shutdown automation when the environment was created.
The remediation is mechanical. Azure Automation accounts with start/stop runbooks scheduled against business hours for development and test environments. Tagging discipline that identifies which environments are subject to the schedule. An opt-out mechanism for the rare engineer who needs to run an overnight job. The whole setup is a one-week project for a competent Azure engineer.
For this client, the shutdown schedules cut non-production compute spend by roughly 60 percent on the workloads that adopted them. The total monthly saving was around USD 8,000, smaller than the previous two levers but disproportionately easy.
The behavioural layer, where the remaining 30 percent comes from
With the three structural levers delivering around USD 49,000 per month in savings, the CFO got the visible result the conversation needed. That credibility funded the behavioural workstream.
Tagging discipline. Every Azure resource now carries owner, cost-centre, environment and lifecycle-stage tags. The tagging is enforced via Azure Policy at the subscription level (resources cannot be created without the required tags) and reported on monthly. New resources comply automatically. Existing resources were back-filled over the engagement.
Cost visibility for engineering teams. Each team got a monthly cost report scoped to their resources. The first month's reports surfaced about a dozen orphaned resources that had been forgotten: old test databases, unused storage accounts, public IPs without an associated workload. We decommissioned them. Small win, real money, and a culture signal.
Architecture reviews for net-new workloads. New workloads now go through a 30-minute cost review before deployment. The reviewer checks SKU sizing, storage tier choice, region selection and reserved/savings plan applicability. The intervention point is before the workload goes live, when changes are cheap.
These three changes do not deliver dramatic monthly savings the way right-sizing does. They prevent the next round of overspend from accumulating, which compounds over the multi-year horizon.
UAE-specific context, Azure UAE North pricing and residency trade-offs
Azure UAE North and UAE Central pricing sits slightly above some international regions for the same SKUs. For workloads with no residency requirement, running them in West Europe or East US saves around 5 to 10 percent on equivalent compute pricing. For workloads with UAE residency requirements (most regulated UAE workloads), UAE region is non-negotiable and the pricing premium is the cost of compliance.
The FinOps engagement therefore included a residency classification pass: which workloads must stay in UAE regions, which can move to international regions for cost reasons, which are running in UAE regions out of habit rather than necessity. For this client about 15 percent of the estate moved to West Europe based on the classification. The remaining 85 percent stayed in UAE North and UAE Central.
This is the kind of decision that mid-market clients defer because they cannot find the right person to make the call. Putting the residency analysis on the FinOps workstream gave the work a forcing function.
What we would do differently next time
Three things, against the next engagement.
Start the tagging policy enforcement on day one, not day thirty. The first thirty days of the engagement, new resources were still being created without proper tags because the policy enforcement had not been turned on yet. Cleaning this up at day thirty was unnecessary work.
Push the application owners on tier-1 right-sizing earlier. We carved tier-1 production workloads out of the right-sizing pass to manage risk. That was the correct call in 90 days, but it left savings on the table. The next engagement would run a parallel tier-1 conversation with application owners from week two so the tier-1 right-sizing lands in month four rather than month six.
Treat the FinOps engagement as the start of an operating model, not as a one-off project. The 34 percent savings delivered in 90 days will erode by 3 to 5 percent over the following year if no ongoing FinOps discipline exists. The client renewed into a managed FinOps retainer at the end of the engagement; we would build the conversation about ongoing operations into the original engagement scope rather than treating it as a follow-on conversation.
Why this matters for any mid-market Azure estate
The 34 percent number is not unusual for a mid-market Azure estate that has never had a structured FinOps engagement. We see numbers in this range consistently. What varies is how much of the saving is right-sizing versus commitments versus lifecycle. That mix depends on what the existing estate looks like, but the total available saving is typically 25 to 40 percent of the run-rate.
The engagements that fail to deliver in this range almost always fail for the same reason: they invert the structural and behavioural order. The structural levers are mechanical, fast and high-confidence. The behavioural work is slower, harder to measure and harder to sustain. Ship the structural wins first.
Bottom line
Most mid-market cloud overspend is structural, not behavioural. Right-sizing, Reserved Instances or Savings Plans, and lifecycle automation deliver about 70 percent of the available saving with about 30 percent of the effort. Tagging discipline, cost visibility and architecture review deliver the remaining 30 percent over the following year and prevent the next round of overspend from accumulating.
For UAE-based clients there is an additional residency-and-region analysis worth folding into the FinOps engagement. Some workloads must stay in UAE regions for compliance; some are there out of habit. Separating the two is part of the savings story.
For any mid-market enterprise with an Azure spend over USD 50,000 per month and no structured FinOps practice in place, the 25 to 40 percent saving is achievable in 90 days if the work is sequenced right.
