Infrastructure

Cloud costs that scale with revenue: modelling the fixed and variable parts

By Assaf Schwartz · 10 September 2026 · 9 min read

An infrastructure bill is two costs wearing one invoice. Part of it exists whether or not anybody logs in, and part of it is bought fresh every time a customer does something. They behave nothing alike over five years, and a plan that models the whole bill as one number gets the growth cases wrong in the direction that feels best.

A floor and a slope

The engine splits infrastructure into exactly those two pieces, using the two controls in the infrastructure group:

infra = Baseline cloud spend × price index + Cloud cost per $1k MRR × MRR ÷ 1000

Baseline cloud spend is the floor: the cost of existing. Control planes, the always-on database primary, load balancers, log retention, the staging and CI estates, reserved capacity you have already committed to, the observability contract with a minimum. None of it responds to a customer signing up, and none of it stops if they all leave. It is multiplied by the Cost inflation control, because vendors reprice.

Cloud cost per $1k MRR is the slope: the marginal cost of serving revenue. Request compute, egress, per-seat storage, queue throughput, model inference, the read replicas you add because the load is real. It is expressed per thousand dollars of monthly recurring revenue, which makes it directly comparable to a margin point — $55 per $1k of MRR is 5.5% of revenue.

At the defaults the split starts at $3,209 fixed and $6,679 variable — $9,888 in month one, with the floor accounting for 32.5% of the bill. By month 60 the floor has drifted to $3,782 while the variable half has reached $15,775, and the floor is only 19.3% of a $19,557 monthly bill. The composition inverts on its own. That is the whole point of separating them.

Why the floor-only model flatters you

The common shortcut is to take this month's cloud invoice, type it into Baseline cloud spend, leave the slope at zero, and move on. It is defensible for a single month and wrong for every month after it, because the fixed line grows at Cost inflation while revenue grows at your growth rate, and those are not close.

Run the default company both ways. Correctly modelled it spends $815.7K on infrastructure over 60 months. Enter the identical month-one bill of $9,888 entirely as a floor, with the slope at zero, and the model reports $646.7K — an understatement of $169K. Ending cash comes out $184.7K too high, break-even arrives in month 22 instead of month 24, and the final month's infrastructure bill reads $11,687 against a true $19,557.

Sweeping the slope

Hold everything else at the defaults and move only the Cloud cost per $1k MRR control.

The span is not subtle. At $0 per $1k the company finishes with $2.1M and breaks even in month 15. At $200 — a perfectly ordinary figure for an inference-heavy or data-heavy product, at 20.0% of revenue — it ends at -$224.4K, never repays its cumulative losses, and does not reach operating break-even until month 51. The gap in ending cash across the sweep is $2.3M.

Note that ending ARR falls as the slope rises — $3.9M down to $3M — even though nothing about demand, churn or CAC changed. Infrastructure eats operating profit, operating profit funds the Re-investment rate, and the re-investment buys the customers. A steep slope does not merely cost money; it slows the machine that makes it.

Sweeping the floor

Now the other control, with the slope back at its default.

The floor is the more dangerous of the two at small scale and the less dangerous at large scale, which is the opposite of how most teams treat it. Removing the floor entirely saves $201K across the projection and pulls break-even forward from month 24 to month 20. A $50,000 floor — a single-tenant enterprise deployment, a data platform with committed capacity, a multi-region estate built before the customers arrived — takes the same company to -$1.7M and removes break-even from the horizon altogether.

The difference in character matters more than the magnitudes. A floor is a decision you already made and can usually unmake: consolidate regions, drop the pre-production estate, renegotiate the commitment at renewal. A slope is a property of the architecture, and changing it is engineering work with a lead time.

Getting both numbers off a real bill

You do not need a model to split your own invoice. You need twelve to twenty-four months of history and ten minutes.

1. Pull the monthly cloud total for each of the last eighteen months, and the MRR for the same months. Use the total bill, not the tagged production subset — the untagged remainder is real money.
2. Plot bill against MRR, one point per month. You are looking for a straight line, and you will usually get one, because usage tracks revenue far more closely than anyone expects.
3. Fit a line through the points. The intercept — where the line crosses zero MRR — is your Baseline cloud spend. The gradient, expressed per thousand dollars of MRR, is your Cloud cost per $1k MRR.
4. Sanity-check the intercept against reality. If the fitted floor is larger than the total bill you would face with every customer switched off, the fit is being dragged by a step change and you should re-fit on the months since that step.

Two points are enough for a first pass. If the bill was $6,000 at $80,000 of MRR and $9,000 at $130,000, the gradient is $3,000 over 50 thousand of MRR — $60 per $1k — and the implied floor is $6,000 minus $4,800, or $1,200. Those are the two numbers to type in.

• Strip out one-offs before fitting. A migration month, a runaway backfill, a load test that ran all weekend. They inflate the gradient and they are not a property of your architecture.
• Regress on usage if revenue and usage have diverged. If pricing changed mid-period, fit the bill against the physical driver — requests, active users, gigabytes stored — and then convert to a per-$1k figure using current ARPA.
• Expect the floor to look too high. Most teams discover an intercept of 30 to 50% of today's bill, and most are surprised. Idle capacity is the normal state of a growing platform.

Where this meets gross margin

Hosting is a cost of revenue in your accounts, so the obvious question is why it is not simply inside the margin. The answer is that a margin percentage cannot express a floor. A fixed cost represented as a percentage of revenue implies a cost that vanishes when revenue does, and the whole character of Baseline cloud spend is that it does not.

Which creates the trap. In this engine, infrastructure is charged in operating expense, not inside the Gross margin control. Enter a margin taken straight off the P&L — already net of hosting — and then fill in these two controls, and you have deducted infrastructure twice. At the defaults infra runs 8.1% of revenue in month one and 6.8% by month 60, averaging 7.4% across the projection: that is the size of the double count.

Set the Gross margin control from support, payment fees, third-party per-customer costs and delivery-side customer success, with hosting removed, and let these two controls carry the cloud bill. The full argument, including what else belongs in cost of revenue, is in SaaS gross margin explained.

What efficiency work actually changes

Cloud efficiency programmes are sold as one thing and are really two, and the two have completely different half-lives.

• Floor work is a one-time reset. Killing idle environments, right-sizing over-provisioned instances, deleting orphaned volumes, consolidating regions, moving to committed-use pricing. It lands quickly, it is visible on the next invoice, and it does not repeat: once the waste is gone it stays gone, and the line resumes drifting up with Cost inflation.
• Slope work compounds. Caching, query and index work, tiered and lifecycle storage, batching, smaller or quantised models, moving hot paths off the expensive service. Every point of slope you remove keeps paying, and it pays more each year, because it is a share of a revenue line that is growing.

The sweep above puts a price on the second kind. Take the slope from $55 to $44 per $1k — a 20% cut in marginal cost, which is one focused quarter for one engineer on caching and storage tiering — and it is worth $117.7K of infrastructure spend across the projection and $137.1K of ending cash, which is more than the saving because the profit gets re-invested. Weigh that against what an engineering hire costs and slope work is one of the few pieces of engineering that can be justified on the cost line alone.

A last note on conservatism. The engine does not inflate the slope: Cost inflation is applied to Baseline cloud spend only. Leaving Cloud cost per $1k MRR flat across the projection therefore assumes your marginal cost of service falls 15.4% in real terms over the five years — roughly what a competent team achieves through volume discounts and ordinary optimisation, and no more. That is the right default. Modelling a declining slope commits you to efficiency gains you have not made yet, and the failure mode of understating infrastructure is the one that arrives as a surprise in the month you can least afford it.

Educational content, not financial advice. Figures here are illustrative and exclude taxes, financing and one-off items. Model your own numbers in the simulator and check them with a qualified accountant before acting.