03 Cloud economics · Zetsol
An 88% cloud cost reduction, live in production
A national telemedicine platform's Azure bill had outgrown its architecture. I redesigned the infrastructure around Application Gateway, App Services and Azure Functions, taking monthly spend from roughly $12,000 to roughly $1,500 — as an individual contributor, with the platform serving patients throughout.
88%
Monthly run-rate removed. Roughly $126,000 annualised, on a platform that never went down for it.
Where the money was going
The platform had grown the way most production systems grow: each new requirement got the resource that was easiest to provision at the time. The result was a footprint sized for peak load at every hour of the day, with compute permanently allocated to work that was intermittent by nature.
The bill was the symptom. The actual problem was that the shape of the infrastructure no longer matched the shape of the traffic.
Cloud cost work is architecture work wearing a finance costume. You do not get 88% from buying reserved instances. You get it from changing what runs, and when.
The redesign
Three moves, in order of impact:
- Application Gateway as the single ingress. Consolidating entry into one managed gateway removed a layer of per-service public surface and gave one place to handle routing and TLS, rather than paying for that capability repeatedly.
- App Services for the request path. Moving the always-on HTTP workloads onto right-sized App Service plans meant paying for the tier the traffic actually justified, with scaling attached to the plan instead of to a permanently over-provisioned host.
- Azure Functions for everything intermittent. Background jobs, media handling and scheduled work do not need a machine waiting for them. Anything that ran on a trigger rather than a request moved to consumption-billed Functions, which is where the largest share of the saving came from — that workload went from continuously provisioned to billed per execution.
Doing it without an outage
This was a healthcare platform with real consultations happening on it. The constraint that shaped the whole project was that there was no window in which it was acceptable for the system to be unavailable.
So the migration was incremental by design: move one workload class at a time, keep the old path available until the new one is proven under real traffic, and treat the cost graph as the verification signal rather than the goal. A drop in spend that comes with a rise in error rate is not a win, it's a regression with good PR.
What I took from it
Two things I still apply. First, read the bill as a system diagram — a cost breakdown by resource tells you where your architecture disagrees with your traffic, and it is often more honest than the architecture diagram anyone drew. Second, the cheapest compute is the compute that isn't running; the highest-leverage question is usually "does this need to be always-on?" rather than "can this be smaller?"
I later carried the same instinct into a cross-cloud migration onto AWS Elastic Beanstalk at Sehat Kahani, and into a Redshift → ClickHouse warehouse migration at BitsPro. Same shape of problem, different vendors.
A note on attribution
This work belongs to my 2021 — 2022 development stint at Zetsol, when I was an individual contributor, not to a later leadership role. I mention that because cost-reduction numbers have a habit of migrating up someone's résumé to a more senior title, and this one shouldn't.