Revenue is climbing, customers are happy, and the cloud bill is somehow climbing faster than both. A line item that used to sit quietly on a finance spreadsheet now has its own slot on the board agenda, and you would like to have a clear answer ready when someone asks why.
We have seen this pattern many times, both with clients and in the years we spent running global SaaS operations ourselves. The honest diagnosis is almost never one dramatic mistake. It is dozens of small, reasonable-sounding decisions that compound quietly for months, until the gap between what the infrastructure costs and what it needs to cost is impossible to ignore.
That matters because it changes the fix. A one-time clean-up deals with last quarter's waste and does nothing to stop next quarter's waste from building up the same way. What works is a set of habits that keep spend proportional to growth. If you want the full unit-economics walkthrough, our guide on how to control cloud costs as a SaaS company scales covers it, and this article looks at why the bill spirals in the first place.
The bill that outran revenue
Think about how the small decisions actually look when they are made. A database gets sized generously for a traffic spike that happened once. A test environment is spun up for a sprint and never shut down. A storage tier is picked because it was convenient at the time, not because anyone checked the price.
None of these looks like a problem on its own. Together they erode the gross margin that investors and boards watch most closely, and they rarely show up as a single line item anyone can point to.
Why SaaS cloud spend is so elastic
A fixed office lease does not change shape depending on how customers behave. Cloud infrastructure does, constantly, which is what makes it both powerful and risky for a scaling SaaS company.
Demand, usage, and pricing all move the number
Cloud costs shift with customer demand, with how intensively those customers use the product, and with whatever pricing model your own company has chosen to offer. That flexibility pays off in quiet periods, because infrastructure can scale down and save money when traffic is light. It becomes a liability the moment growth runs ahead of what anyone modeled, because the same systems that saved money in slow months can spike costs just as fast when usage surges, egress grows, or committed-pricing contracts renew without anyone revisiting the terms.
Small decisions that quietly compound
The habits that create waste are rarely deliberate. A team provisions extra compute for a launch and forgets to scale it back. A monitoring tool is added for one project and never reviewed again. Managed services multiply as new features ship, each one reasonable on its own, until the combined footprint is much larger than any single decision would suggest.
One question we keep coming back to with teams in this position: who owns the decision to turn something off? There could be a good reason nobody does, such as fear of breaking something nobody fully understands, but in our experience it is usually just that nobody was asked.
Where the waste actually hides
Two areas account for a disproportionate share of wasted spend in growing SaaS companies, so they are the best place to start looking.
Overprovisioned capacity and idle resources
Capacity planned for peak load and never resized afterward is one of the most common sources of overspending. Idle development and test environments, stale workloads that outlived their purpose, and storage tiers chosen for convenience all fall into the same bucket.
Catching it starts with auditing what is actually running, measuring real usage against what was provisioned, and attributing costs to the teams and services responsible. Once that visibility exists, rightsizing can begin with non-production workloads, where the risk of disruption is lower. Watch for out-of-memory errors or throttling as you bring resource limits down.
Kubernetes waste: oversized nodes and orphaned volumes
Teams running Kubernetes tend to see some of the widest gaps between what is provisioned and what is used. Resource requests that were guessed once and never revisited inflate the capacity a cluster carries, because autoscalers treat those requests as genuine demand and add nodes to match them, whether or not the workload ever uses that much. A handful of patterns show up again and again in cost reviews:
- Unattached persistent volumes: storage that keeps costing money long after the workload that created it is gone.
- Unused load balancers: left behind by services that were retired or migrated.
- Abandoned namespaces and container images: leftovers from deployments that no longer run.
- Oversized node pools: sized for peak demand and never scaled back during quieter periods.
Setting a cluster's minimum node count to match its real minimum-capacity period, rather than its busiest moment, is one of the more direct ways to stop paying for capacity that sits unused most of the time. Our guides on Kubernetes cost optimization on AWS EKS and Kubernetes cost monitoring and management go further on the tooling side.
Not sure where your bill is leaking?
We can walk through your spend with you, find the idle and oversized resources first, and teach your team the habits that keep them from coming back.
Review Your Cloud Spend →Tracking cost per customer
Finding waste matters, but it only solves half the problem. The other half is a metric that connects infrastructure spend to the business outcomes your board cares about.
Why an even split across customers misleads
Dividing the total cloud bill evenly across every customer is a tempting shortcut, and it is one of the more misleading ones. An even split hides which customers actually drive the most usage and cost, so a heavy user and a light user look identical on paper even though one of them costs far more to serve. A usage-based metric built from real allocation data, rather than an average, gives a much clearer picture of where margin is being made or lost.
Choosing a usage-based unit for your product
Cost per customer, sometimes called cost per tenant, tends to be the easiest starting metric for most SaaS organizations, because it maps onto how the business already talks about growth. The right unit varies by product:
- B2B workflow platform: start with cost per customer and look closely at database rightsizing.
- Analytics product: cost per gigabyte processed may track better.
- Video or AI-driven product: cost per video hour or cost per inference follows what really drives compute spend.
For shared infrastructure, an allocation driver such as API requests, compute seconds, gigabytes stored, or gigabytes transferred ties the shared cost pool back to real tenant usage far more accurately than seat count or revenue share would.
Phasing in cloud, then tools, then everything else
Trying to build a unit cost model all at once tends to stall before it delivers anything useful. A phased approach keeps it moving:
- Start with cloud-only costs, sometimes split into direct and shared categories if the architecture is already complex.
- Add the SaaS tools and licenses running alongside the infrastructure, such as monitoring platforms or bring-your-own-license software.
- Bring in human capital and any remaining on-premise systems last, which is typically when a company starts tracking more than one metric across a growing system.
Each phase forces a decision about what counts. Whether discounts, shared costs, support costs, and other operational costs belong inside the unit figure is a choice the team has to make explicitly. It will not resolve itself by default.
Turning allocation into action
A cost model only matters if it changes decisions, which means moving from a single number to something engineering and finance can both act on.
Assigning costs to teams, products, and customers
Cost allocation means assigning every line item on a cloud bill to the team, product, or customer that generated it. That turns a provider invoice from a mystery total into a model you can act on. It gets harder with SaaS vendor spend, because many third-party tools show up as a single line on an invoice instead of something tagged and traceable like cloud-native resources. Getting an accurate picture often means pulling in vendor billing data alongside standard cloud tags, rather than relying on tags alone.
Forecasting from usage, workload, and commitments
Once allocation is solid, forecasting becomes grounded in real data rather than guesswork. A useful forecast draws on historical usage patterns, expected changes in workload as the product grows or shifts, and whatever spend is already locked in through commitment discounts or reserved pricing. Skip any one of those inputs and the forecast looks precise while missing the thing that actually moves next quarter's number.
Engineering habits that keep spend proportional
Cost data changes very little on its own. It has to reach the engineers making provisioning decisions, and it has to arrive early enough to matter.
Infrastructure as code to flag idle resources
Tools like Terraform give teams a consistent, repeatable way to manage cloud resources instead of relying on manual configuration that drifts over time. They can also enforce cost-centric policies directly, flagging idle resources before they inflate the next invoice. That moves cost awareness from a monthly finance review back to the moment a resource is provisioned, which is where it does the most good. Our piece on cost effective infrastructure as code with Terraform shows what this looks like in practice.
SRE reviews comparing provisioned versus actual use
Site reliability engineering practices add a complementary layer of discipline, focused on monitoring real usage rather than assumptions about what a workload needs. A recurring review that compares provisioned resources against actual use tends to surface the over-allocation that happens when a team provisions headroom nobody ends up needing. Pair it with autoscaling policy checks, because autoscalers can keep adding capacity even when real demand never asked for it. For the wider practice, see our overview of site reliability engineering practices.
Proportional growth starts with visibility
A cloud bill that grows faster than revenue is rarely a mystery once someone looks closely. It is the sum of demand that shifts constantly, usage that scales unevenly across customers, and small provisioning decisions that nobody revisits after the moment they are made. None of that calls for alarm. It calls for visibility, built through a usage-based cost metric, allocation that ties spend to the teams and customers generating it, and engineering habits that catch waste before it compounds.
Companies that build this early tend to defend their margins far more easily going into their next stage of growth. A sensible first step is small and defined: pick one unit, allocate your cloud-only costs against it, and see what surprises you. If it would help to have a second pair of eyes on that, we are happy to take a look and teach your team along the way.
FAQ
Why does my cloud bill grow faster than my revenue?
Cloud spend shifts with customer demand, usage intensity, and your own pricing model, and it picks up small provisioning decisions that nobody revisits. Oversized databases, forgotten test environments, and storage tiers chosen for convenience compound quietly until costs outpace growth.
Where does most cloud waste hide in a SaaS company?
Mostly in overprovisioned capacity and idle resources. In Kubernetes environments, common culprits include unattached persistent volumes, unused load balancers, abandoned namespaces, and node pools sized for peak demand that never scale back down.
Why is splitting the cloud bill evenly across customers a problem?
An even split hides which customers drive the most usage and cost, so heavy and light users look identical. A usage-based unit such as cost per customer, or an allocation driver like API requests or gigabytes stored, shows where margin is actually made or lost.
How can engineering teams stop cloud costs from creeping back?
Pair infrastructure as code tools such as Terraform, which can flag idle resources at provisioning time, with recurring SRE reviews that compare provisioned resources against actual use. Together they catch over-allocation before it reaches the next invoice.