Keeping Your Cloud Bill From Eating Your Runway

I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

The cloud bill is one of the quietest ways a growth-stage company burns its runway. It doesn't announce itself as a crisis on day one. It just grows — with your users, your data, your team's experiments — and if nobody's watching, it grows faster than the business does. Most writing on this treats it as a performance-tuning exercise for AI labs training their own models. For you it's simpler and more existential: don't let the bill outrun your growth.

I learned this at scale — the hard way, and then the disciplined way.

The habit that kept the bill from running away

At Videology we went through massive growth — we scaled to more than three billion transactions and four terabytes of data a day on AWS, as early adopters. At that size, our cloud bill would climb by tens of thousands of dollars a year on its own if we did nothing. So we didn't do nothing. Every quarter, our systems engineering team took a hard look at our architecture and how we were actually using our cloud services, and came back with specific recommendations to hold the same quality and service at a lower cost. That one habit — a standing quarterly review, not a one-time cleanup — is what let us actually afford the cloud and keep the costs from running away.

That's the whole game, and it scales down to a ten-person company as cleanly as it scaled up for us.

Why bills actually blow up

Here's the mechanism underneath it, and it's the thing most teams miss. Cloud bills don't usually explode because of one dumb mistake — they explode because your planned usage and your actual usage quietly stop following the same path. You provisioned for the growth you expected; the real growth took a different shape, in a different service, at a different rate. The gap between the plan and the reality is where the runaway cost lives — and you will never see it if you're not tracking usage patterns against expectations.

So the first thing to build isn't a savings tactic. It's the ability to see your usage and cost, by service, over time.

FinOps-lite: the version for a company with no FinOps team

You don't need a FinOps function or a wall of dashboards to do this. The right-sized version is four cheap habits:

• Tag everything, so you can see spend by service, feature, team, and customer.
• Set budgets and alerts, so an overrun pings you before it's a surprise on the invoice.
• Watch the plan-vs-actual gap, not just the total. The total going up is fine if the business is going up with it; the shape diverging is the warning sign.
• Run a regular review cadence — quarterly like we did, or monthly if you're moving fast — where someone actually looks and proposes changes.

That's it. The goal isn't to obsess over every dollar while your engineers' time is worth far more; it's to have enough visibility and rhythm to catch the divergence before it becomes a crisis.

Where the money usually is

When you do look, these are the usual culprits:

• Over-provisioning. The most common one by far. You picked instances bigger or more numerous than the workload needs and never revisited it. Right-size down when utilization is consistently low; scale up only when there's a real bottleneck.
• Storage and data transfer. Not all data needs expensive hot storage — tier it, and set lifecycle policies to move or delete stale data. And watch egress: moving data out of a region or between services is a sneaky, recurring charge. Keep compute and data in the same place when you can.
• Idle, always-on resources. Serverless and containers let you pay for what you actually use instead of paying for machines that sit warm doing nothing. For sporadic or event-driven work especially, that shift alone can cut a line item dramatically.

Commit, or stay flexible?

Then there's the pricing-model question, where cloud providers dangle big discounts — reserved instances, savings plans, spot capacity — for committing ahead of time. My honest rule: reserve when you can and it genuinely makes sense; stay pay-as-you-go when you can't.

If a workload is stable and predictable, a commitment is basically free money — take it. But when your growth is unknown, or the business is still figuring out its model and plan, don't lock yourself into a one-to-three-year commitment to chase a discount. I've watched companies over-reserve and then spend real energy figuring out what to do with capacity they didn't need — which is just a slower way of wasting the money they thought they were saving. Uncertain usage is worth paying a premium to stay flexible. It's a balance, and it tips toward flexibility earlier than the discount calculators want you to believe.

Two edges

If AI is in your product, its per-call cost is its own runaway risk — a bad actor or a bug can spike it instantly — and I covered that specifically under "denial of wallet" in my piece on right-sized AI governance.

And if you're actually training or self-hosting models, there's a whole additional lever in optimizing the models themselves — quantization, pruning, distillation. But almost nobody at growth stage does that; you're calling someone's API. File it under "later."

The honest goal

Cloud cost isn't a one-time cleanup, and it isn't a reason to panic-optimize while your team should be building. It's a cheap, standing habit: enough visibility to see your real usage, a regular cadence to look at it, and the judgment to right-size and to commit only where commitment is safe. Do that, and the bill grows with your business instead of ahead of it — which, when runway is the thing keeping you alive, is exactly the point.

If your cloud bill is climbing faster than you can explain, or you're weighing a big reserved-capacity commitment you're not sure about, that's a good thing to think through with someone who's managed it at scale. Book a call and we'll look at where your money's actually going.