Hello Readers, In this article I want to walk you through one of the more satisfying engagements I’ve worked on in the last couple of years — not because it involved some dramatic technology overhaul, but because it involved almost the opposite. No migration. No re-platforming. No six-month project plan with a new vendor logo at the end of it. Just a careful, methodical look at where money was quietly leaking out of a cloud bill, and a series of unglamorous fixes that added up to a 34% reduction in monthly spend.
I won’t name the client here, and I’ll keep some of the specifics generalized — but the situation itself is worth talking about in detail, because I see versions of it constantly. A mid-market company, growing fast enough that nobody had time to look backward, ends up with a cloud environment that technically works but financially doesn’t make sense anymore. And the instinctive reaction a lot of businesses have — “maybe we need to switch providers” or “maybe we need a full re-architecture” — is usually the wrong first move.
The Situation We Walked Into
The client was a mid-market company running a fairly typical modern stack — a mix of compute instances, managed databases, object storage, and a handful of supporting services, all hosted with a single major cloud provider. They’d grown from a small operation to a few hundred employees over about four years, and their infrastructure had grown right along with them — mostly in the way infrastructure grows when nobody’s specifically responsible for cost: reactively.
Someone needed a new environment for a project, so a new set of instances got spun up. A proof-of-concept from eighteen months ago never got torn down because nobody was quite sure if something still depended on it. Storage kept accumulating because deleting things felt riskier than paying for them. None of this was negligence, exactly — it’s just what happens when a growing engineering team is optimizing for shipping features, not for the monthly invoice.
By the time I got involved, their monthly cloud spend had roughly tripled over two years, while their actual customer-facing workload had grown at a noticeably slower rate. Finance had started asking pointed questions. The engineering leadership’s initial hypothesis was that they’d simply “outgrown” their current setup and needed to consider a different provider, possibly with better enterprise pricing, or a broader infrastructure redesign.
My first response, honestly, was to ask them to hold off on that conversation until we’d actually looked at what they were paying for.
Why We Didn’t Jump to Migration
Migrating cloud providers is expensive, risky, and slow — and in my experience, it’s very rarely where the actual savings live for a company at this stage. It solves a pricing problem by trading it for a much bigger operational problem: months of engineering time redirected away from the product, a real risk of downtime or data issues during the cutover, and a new environment that, without different habits, will often drift back into the same cost patterns within a year or two.
Before recommending anything that disruptive, I wanted to know one simple thing: was this company actually paying a fair price for the infrastructure it needed, or was it paying for infrastructure it didn’t need at all? In the vast majority of cases I’ve worked on, it’s overwhelmingly the second one. This engagement was no exception.
Starting With a Real Cost Audit
We began with what I’d call a proper cost audit — not just glancing at the monthly bill, but actually mapping spend against usage, service by service, and asking “does this line item correspond to something the business actually needs right now?”
This is slower and less exciting than it sounds. It meant pulling detailed billing and usage reports, tagging resources by team and purpose (which, unsurprisingly, hadn’t been done consistently), and cross-referencing what was running against what was actually being used in production versus what was leftover from old projects.
A few things became clear within the first couple of weeks.
Compute was significantly oversized. A large share of their virtual machine instances were running at a fraction of their provisioned CPU and memory capacity — in some cases consistently under 15% utilization. This is an extremely common pattern: teams provision generously “to be safe” during initial setup, and then nobody revisits that decision once the workload stabilizes.
A meaningful chunk of resources had no clear owner. Several instances, a handful of managed database clusters, and a fair amount of storage traced back to projects that had either been deprecated, paused, or fully migrated elsewhere internally — but the underlying infrastructure had simply never been decommissioned. Nobody was actively using them, but nobody had explicitly killed them either.
Storage costs had crept up quietly. Old backups, log files, and snapshots had been accumulating for years without a retention policy, all sitting in premium-tier storage rather than being moved to cheaper, colder storage tiers appropriate for data that’s rarely, if ever, accessed.
They were paying almost entirely on-demand pricing. For workloads that were genuinely steady-state and predictable — which was most of their core production environment — they hadn’t taken advantage of reserved capacity or savings-plan style discounting that most major providers offer in exchange for committing to predictable usage.
None of these findings were exotic. That’s actually the point I want to make here — the biggest cost problems I encounter in these engagements are rarely clever architectural mistakes. They’re accumulated neglect.
What We Actually Changed
Once we had a clear picture, we prioritized changes based on two things: how much savings they’d generate, and how low-risk they were to implement. We deliberately avoided anything that touched core application architecture in this first phase — the goal was to prove out savings without introducing new risk to a system that was, in every functional sense, working fine.
Rightsizing compute instances. Using several weeks of actual utilization data, we resized a large portion of their virtual machines down to instance types that matched real, observed usage rather than provisioned-for-safety guesses. In several cases, this meant moving from larger general-purpose instances to smaller, more appropriately sized ones — sometimes with a burstable or auto-scaling configuration layered on top so capacity could still flex during genuine demand spikes.
Decommissioning orphaned resources. This took real detective work — pinging teams, checking application logs for any recent connections, and in a few cases waiting a defined observation period before shutting things down, just to be sure nothing unexpected broke. We ultimately identified and safely removed a substantial number of unused instances, unattached storage volumes, and old database clusters that had simply been forgotten.
Introducing storage lifecycle policies. Rather than manually managing what got archived or deleted, we implemented automated lifecycle rules — data past a certain age with no access activity automatically moved to a cheaper, cold storage tier, and clear retention limits were set for logs and backups so they wouldn’t accumulate indefinitely going forward.
Shifting predictable workloads to reserved/committed pricing. For their stable, steady-state production workloads — the parts of their infrastructure that weren’t going anywhere and weren’t fluctuating much — we moved them from on-demand pricing to reserved or committed-use pricing, locking in a meaningfully lower rate in exchange for a usage commitment they were realistically always going to meet anyway.
Setting up cost anomaly alerts and ownership tagging. This part mattered as much as any single technical fix. We implemented consistent resource tagging by team and project, along with automated alerts that flag unusual spend spikes as they happen, rather than three months later when someone finally opens the invoice. This was really about preventing the same drift from happening again.
None of this required touching their application code. None of it required downtime beyond a few brief, carefully scheduled maintenance windows for the instance resizing. And none of it required evaluating a single alternative cloud provider.
The Result
Over about a ten-week engagement, these changes brought their monthly cloud spend down by 34% — and importantly, this wasn’t a one-time discount or a temporary promotional rate. It was a structural reduction based on paying for what they actually needed, priced the way it should have been priced from the start.
Just as valuable, in my opinion, was what came alongside the dollar savings: the client’s engineering team now had real visibility into what they were spending and why, tagged by team and project, with alerts in place so cost creep would get caught in weeks, not years. The finance team, for the first time, could actually map cloud spend to specific business units and make informed decisions about where infrastructure investment was justified and where it wasn’t.
I want to be honest that this wasn’t some brilliant, hidden insight nobody else could have found. Every single thing we did here is documented, standard cloud cost optimization practice. The value we brought wasn’t a secret technique — it was the discipline of actually doing the audit properly, prioritizing the changes that mattered most, and executing them carefully enough that nothing broke along the way.
What This Case Says About Cloud Costs More Broadly
I bring this case up often when I talk to other mid-market business leaders, because the pattern is genuinely common, not unique to this one company. Growing businesses accumulate cloud waste the same way any organization accumulates operational inefficiency — not through any single bad decision, but through hundreds of small, individually reasonable decisions made under time pressure, with nobody specifically tasked with periodically stepping back and asking whether the whole picture still makes sense.
A few things I’d genuinely encourage any business leader reading this to take away:
Rising cloud costs are rarely a “wrong provider” problem. Before assuming you need to migrate somewhere cheaper, it’s worth asking whether you’re actually paying a fair price for what you’re using, or paying full price for things you no longer need. In my experience, the second problem is far more common and far cheaper to fix.
Utilization data doesn’t lie, but nobody looks at it by default. Most cloud providers give you the tools to see exactly how utilized your resources are. The problem isn’t a lack of data — it’s that nobody’s job description includes regularly reviewing it, especially in fast-growing companies focused on shipping product.
Orphaned infrastructure is more common than most leadership teams realize. If nobody can quickly tell you, resource by resource, why something is running and who owns it, there’s a very good chance you’re paying for things nobody actually needs anymore.
The fix doesn’t have to be disruptive. Some of the most meaningful cost reductions I’ve helped clients achieve involved zero changes to application architecture and zero downtime beyond brief, planned maintenance windows. Cost optimization and system stability aren’t in conflict when it’s done properly.
This isn’t a one-time project — it’s a discipline. The tagging, alerting, and review habits we put in place matter as much as the initial cleanup, because without them, the same drift that caused the original problem will happen again within a year or two.
Final Thoughts
What I appreciated most about this engagement wasn’t the percentage — 34% is a good number, but it’s not the headline I’d lead with if I were advising you. The real shift was that the client went from having no real visibility into their cloud spending to having a system where cost, usage, and ownership were all connected and monitored. That’s the part that keeps saving money long after the engagement ends.
If your business has watched its cloud bill climb steadily over the past couple of years and the instinctive answer floating around your leadership team is “maybe we need to switch providers” — I’d genuinely encourage you to pause on that and ask a more basic question first: do we actually know what we’re paying for, and why? In most cases I’ve seen, that question alone uncovers more savings, faster and with less risk, than any migration would.
If you’re facing a similar situation and want an honest, no-obligation look at where your cloud spend might be quietly working against you, that’s exactly the kind of conversation I have regularly. Reach out to GlobalITConsultant.com, and we can talk through what a cost audit might realistically uncover for your business.
