Every finance team that manages cloud spend has the same experience with forecasting: the numbers are wrong, always, and the variance explanations are unsatisfying. Engineering says the overage was due to “unexpected growth.” Finance says the model was accurate. Both are right, which means neither is useful.
Cloud cost forecasting is genuinely harder than forecasting most other cost categories. But it’s not unsolvable. The failure mode is almost always the same — organizations apply traditional cost forecasting methods to a cost type that doesn’t respond to them.
Why traditional forecasting breaks down
Most enterprise cost forecasting is built on the assumption that costs are driven by identifiable, measurable business inputs. Headcount drives salary expense. Units produced drives material costs. Revenue drives commission expense. The relationship between input and cost is stable and historical data can calibrate it.
Cloud costs have a different structure. They’re driven by technical decisions — architecture choices, deployment patterns, data retention policies, autoscaling configurations — that may have no direct relationship to the business inputs finance teams track. A change in how an application handles caching can cut infrastructure costs by 40% with no change in revenue, users, or transactions.
This means that three traditional forecasting approaches all fail in similar ways:
Percentage-of-revenue models assume cloud costs scale with revenue. They do, loosely, over long time horizons. But quarter-to-quarter, the relationship is too noisy to be useful for budget management. A 10% increase in revenue might produce a 3% increase in cloud costs or a 25% increase, depending entirely on how the application was architected and what the traffic patterns look like.
Year-over-year trend models assume that future costs will follow past trends. They work until they don’t — which is whenever the engineering team makes a significant architectural change, migrates a workload, or commits to reserved capacity. Any of these can produce a discontinuity that makes the historical trend irrelevant.
Bottom-up engineering estimates ask engineering teams to forecast their infrastructure needs for the year. These estimates are almost always optimistic — they assume steady traffic, no incidents, no technical debt remediation, and no one spinning up development environments that don’t get cleaned up.
The actual drivers of cloud cost variance
Forecasting improves when you understand what actually causes variance. The most common sources:
Unplanned workload growth — Applications that receive more traffic than expected generate more infrastructure cost. This is the “unexpected growth” explanation that engineering gives finance. It’s real, but it can be bounded: what’s the cost per unit of workload growth? That relationship, once established, makes growth scenarios modelable.
Architecture changes — Migrating from one database type to another, changing storage tiers, modifying how data pipelines are structured. These can produce step-changes in cost that have no relationship to business volume.
Environment sprawl — Development, staging, and testing environments that are provisioned for a project and never cleaned up. These accumulate over time and become a significant portion of spend in organizations without environment lifecycle policies.
Commitment underutilization — If an organization purchases Reserved Instances or Savings Plans and then changes its architecture, the commitments may not be fully utilized. The cost is locked in regardless of whether the capacity is used.
Data transfer surprises — Egress costs that weren’t anticipated in the original architecture. Often discovered after a new feature is deployed that moves data in ways the original estimate didn’t account for.
AI and ML experimentation — GPU instance costs and model inference costs are highly variable and difficult to forecast based on historical patterns. A new experiment can consume enormous resources in a short time.
A better forecasting model
A finance-grade cloud cost forecast treats cloud spend as a function of two distinct components that need to be modeled separately.
Baseline spend — The cost of running existing workloads at current scale. This is the most predictable component. Once you have a clean baseline (ideally excluding anomalies and one-time costs), baseline spend changes slowly and can be projected with reasonable confidence. The key assumption to validate quarterly: are there any planned architecture changes that would materially shift the baseline?
Growth-driven spend — The incremental cost of additional workload volume. This requires establishing a cost-per-unit relationship for your major workloads. Cost per active user, cost per transaction, cost per GB of data processed — whatever the relevant unit is for your business. These relationships are measurable from historical data and give you a way to model cost scenarios against revenue and volume assumptions.
One-time and non-recurring items — Migrations, large data processing jobs, infrastructure buildouts. These should be identified explicitly in the forecast and tracked as capital-like events, not as part of the run-rate.
The resulting forecast looks like: Baseline + (Volume Growth × Cost per Unit) + One-time Items = Projected Spend.
This isn’t precise. But it’s bounded by identifiable assumptions that can be validated and updated, which makes it defensible in a way that trend models aren’t.
The commitment layer complicates everything
If your organization uses Reserved Instances or Savings Plans, the forecasting problem becomes more complex. You’ve traded variable costs for fixed commitments, which is generally good for budget predictability but creates a new source of variance: utilization.
A 3-year Reserved Instance commitment at $2,000/month is a fixed cost regardless of whether the underlying instance is running. If the workload it was purchased to cover gets retired, the commitment continues. Finance needs to know what percentage of committed spend is currently being utilized, and what the risk is of underutilization due to planned architectural changes.
This is a conversation that needs to happen between finance and engineering before commitments are purchased, not after the utilization rate drops.
Scenario planning over point estimates
The most useful evolution in cloud cost forecasting is moving from point estimates to scenario ranges. Instead of “cloud spend will be $4.2M next year,” a more honest forecast is “cloud spend will be $3.8M–$4.6M next year depending on the following assumptions.”
The assumptions that drive the range:
- Traffic and volume growth (high/medium/low)
- Planned architecture changes and their expected cost impact
- Reserved capacity utilization
- New AI/ML workloads in the roadmap
Presenting these as scenarios rather than a single number has two benefits. First, it’s more accurate — the uncertainty is real and hiding it doesn’t help anyone. Second, it creates a natural framework for the conversation with engineering: “what has to be true for us to land in the low scenario versus the high scenario?”
That conversation is the beginning of cloud cost management as a shared practice between finance and engineering, rather than a reporting exercise that finance does and engineering reacts to.
CostDefender surfaces the cost-per-unit relationships and commitment utilization data that make cloud cost forecasting tractable — without requiring your engineering team to build custom analytics.