Cloud bills don't grow because anyone made a bad decision. They grow because nobody made a decision at all. A test environment left running since a project that shipped last year. A database tier sized for a peak that never arrived. Diagnostic logging turned on during an incident and never turned off. Each line item is small enough that no one owns it, and together they compound into a number that makes the CFO wince.
When I took over engineering at OmniMetrix, our Azure spend had that shape. The platform was healthy — 14TB of IoT telemetry flowing, customers happy — but the bill had been growing faster than the business. Over the following months we cut it roughly in half. Nothing we did was clever. All of it was work almost any team could do, which is exactly why I'm writing it down.
Start with attribution, not optimization
The first mistake teams make is jumping straight to reserved instances and rightsizing tools. We started somewhere less glamorous: making the bill legible. Every resource got tagged to a system and an owner. Untagged resources got a two-week grace period, then a review. That alone surfaced the embarrassing stuff — orphaned disks, forgotten environments, a staging cluster nobody could name a user of.
You cannot optimize a bill you can't attribute. Once every dollar had a name next to it, the conversations changed from "cloud is expensive" to "why does this specific service cost more than the product it supports?"
The big rocks were architectural
Tagging pays for the effort, but the halving came from a handful of architectural calls. We consolidated workloads that had each been given their own generously-sized compute onto shared Kubernetes node pools with real resource limits. We moved cold telemetry out of premium storage tiers — data that gets queried once a quarter does not need the same disks as data queried every second. We rebuilt a set of always-on services as scheduled jobs, because "runs continuously" turned out to mean "runs usefully for forty minutes a day."
The cheapest infrastructure is the infrastructure you can prove you don't need.
The pattern in every one of these: the original design wasn't wrong, it was provisional. Someone made a reasonable call under deadline, and the meter kept running long after the deadline passed. Cost work is mostly archaeology — finding decisions that expired and nobody noticed.
Caching is a cost tool, not just a speed tool
One of the larger single wins was unglamorous: caching upgrades in front of our hottest query paths. Every cache hit is a database transaction you didn't pay for and compute you didn't burn. We'd always thought about caching in terms of latency. Framing it in dollars got the work prioritized in a way milliseconds never did.
Make it stay cut
Cost cuts decay. The same forces that grew the bill the first time — deadlines, provisional decisions, nobody owning line items — start growing it again the day you stop looking. So we made looking cheap: spend per system reviewed monthly in the same meeting as reliability, budget alerts owned by the team that owns the workload, and cost as an explicit line in design reviews for anything new.
None of this required a FinOps platform or a consulting engagement. It required treating the bill as an engineering artifact — something you read, understand, and refactor — instead of a tax that arrives by email. Half the bill was waiting there for anyone willing to look.