Keeping infrastructure cost from eating your gross margin
Infrastructure spend rarely explodes. It creeps, through defaults nobody revisited, and by the time it is visible it has become a structural margin problem.
Key takeaways
- Cost creeps through over-provisioning, data transfer, log retention and idle environments rather than exploding.
- Track infrastructure cost per active customer monthly; a rising figure signals something scaling worse than linearly.
- Profile before optimising; most of the bill sits in a small number of specific causes.
- Reduce waste before committing to reserved capacity, or you lock in the inefficiency for the commitment period.
Infrastructure cost damages software businesses gradually rather than suddenly. It grows through provisioned capacity nobody reduced, data transfer nobody measured, logs retained forever by default, and environments left running after the project ended. By the time it appears as a margin problem it has usually been growing for a year, and reversing it takes longer than creating it did.
The usual causes, in order
- Over-provisioning for a peak that never arrives. Capacity sized for imagined growth, running at low utilisation continuously.
- Data transfer, particularly between availability zones and out to the internet. It is invisible in architecture diagrams and can become one of the larger lines on the bill.
- Log and metric retention. Defaults are generous and nobody revisits them. Ask what you would actually investigate at ninety days and set retention to that.
- Idle non-production environments. Staging, demo and review environments running through nights and weekends.
- Managed service tiers chosen once and never re-evaluated against actual usage.
Know your cost per customer
The single most valuable number is infrastructure cost per active customer, tracked monthly. It converts an abstract bill into a unit economic you can act on and it exposes problems that a total figure hides. If cost per customer is rising as you grow, something in the architecture scales worse than linearly and you should find it now, while it is a technical problem rather than a financial one.
Tag resources by customer or by feature where you can. Without attribution you can only cut across the board, which usually means cutting the wrong things.
Where the savings actually are
Almost always in a small number of places: one inefficient query running constantly, one job processing far more than necessary, one endpoint with no caching, and a retention setting. Profile before optimising. Engineering effort spent optimising something that is two per cent of the bill is effort spent producing nothing, and it is the common failure mode of cost-reduction projects.
Commitments and their trap
Reserved capacity and committed spend discounts are real savings on genuinely steady baseline load. They are also a way to lock in the cost of an inefficiency for a year. Optimise first, then commit to the reduced baseline. Committing to current consumption and then improving efficiency means paying for capacity you no longer use.
Build the visibility before you need it
Put the monthly bill and cost per active customer in front of the engineering team rather than only in a finance report. Cost is an engineering outcome, and engineers who can see it make different architectural choices without being asked to. Teams that only see cost when it becomes a problem have no opportunity to prevent it.
Set an alert on unexpected daily spend. Most severe cost incidents are a runaway job, a retry loop, or a misconfigured export running continuously, and every one of them is cheap to catch on day one and expensive to discover on the invoice.
When higher cost is correct
Not all infrastructure spending should be reduced. Redundancy, backups, monitoring and staging environments are costs that buy you the ability to recover, and cutting them is borrowing against an incident you have not had yet. Distinguish waste, which is capacity producing nothing, from insurance, which is capacity producing nothing until the day it produces everything.
Optimise first, then commit. Committing to current usage locks in your inefficiency for a year.