At a glance
At $10M ARR, a cloud bill that grows with revenue feels like the system is working. By $50M, the same logic produces a ratio that the board starts asking questions about
The workloads driving the cost aren't unpredictable ones. They're the consistent, modelable ones nobody got around to optimizing because the budget wasn't the constraint yet
Egress costs, managed service sprawl, and committed pricing renewals compound quietly until an annual planning cycle makes them impossible to ignore
When go-to-market and infrastructure are competing for the same budget, the cloud bill stops being a line item and starts being a conversation
The cloud bill math that works at $10M and breaks at $50M
At $10M ARR, the cloud bill is a line in the engineering budget that grows with the product, which feels right. More customers mean more compute, more storage, more egress. Revenue goes up, COGS is trending where you want it, and the cloud is doing what it's supposed to do. At $50M, the logic is still intact, but the number on the board slide tells a different story.
It surfaces in the annual planning cycle, it’s not a production incident. Someone pulls infrastructure spend over the past three fiscal years to build the cost model for the board deck. The compound growth rate in the cloud line is running at a multiple of ARR growth. Egress costs grew faster than the user base did. Committed pricing from 18 months ago is due for renewal at current rates. Features added during a growth sprint brought compute-intensive processing, which the team absorbed into managed services because the engineering bandwidth wasn't there to build around it.
At the time, none of these were bad calls. The sum of individually reasonable decisions produced a ratio that's now difficult to explain.
What the CFO needs for the board presentation is a story about how infrastructure spend scales with revenue from here on out. The historical data isn't telling that story. As a percentage of the cost of revenue, the number isn't what anyone planned for when the model was built. It's not a crisis. It's the kind of line item that gets the question: "Is this what it should be?"
The workloads generating the cost aren't the unpredictable ones. They're the consistent ones: data processing pipelines that run every night, real-time scoring models that fire on every customer event, background workers handling integration sync for enterprise accounts. The load profile is predictable, the timing is consistent, and the cost per unit of work has been stable long enough that someone could have modeled it. Nobody did, because the infrastructure budget wasn't what anyone was optimizing when those workloads were designed.
When infrastructure spend starts competing with growth
Infrastructure spend has two chapters. The first is where spending isn't questioned because the product is being built and the scale hasn't arrived yet. The second starts when the scale arrives and the cost structure appropriate for chapter one becomes a constraint. The gap between the two tends to be invisible until the planning cycle catches it.
That second chapter arrives when go-to-market investment and infrastructure spend are competing for the same budget. In a year where customer acquisition is expensive and net revenue retention needs to improve, the infrastructure ratio matters. It's one of the few major costs at this stage that isn't directly moving the business forward.
The question that never gets asked: when did the team last look at whether the compute they're buying is appropriate for what they're running? Not whether it's sufficient. Whether the form factor that made sense at earlier scale, fast to provision, minimal ops overhead, variable billing, is still the right choice for workloads that are now consistent enough to model, stable enough to commit to, and large enough that the cost structure matters.
