Most cloud cost forecasts are built by extrapolating last month's bill forward with a growth multiplier — and most of them are wrong within a quarter. Actual usage patterns don't scale linearly, and a forecast that ignores that gives finance teams false confidence heading into budget season. Here's the methodology we use instead.
Why Linear Extrapolation Fails
A SaaS company's compute cost doesn't scale 1:1 with customer count. Some costs (base infrastructure, shared services) stay relatively flat as customers grow. Others (per-customer data storage, API compute) scale roughly linearly. A few (cross-region data transfer, certain database read replicas) scale super-linearly past specific thresholds. Averaging all of this into a single growth multiplier hides where the real cost risk sits.
Our Forecasting Approach: Cost Driver Decomposition
Instead of forecasting the total bill directly, we decompose it into cost drivers tied to actual business metrics:
- Fixed infrastructure costs — networking, shared services, base compute floor — modeled as roughly flat unless a specific scaling event is planned
- Per-customer variable costs — storage, compute-per-active-user — modeled against projected customer growth curves, not calendar time
- Usage-spike costs — batch processing, seasonal traffic — modeled against known business cycles (e.g., end-of-month reporting jobs, seasonal demand)
- Step-function costs — costs that jump at specific scale thresholds, like adding a read replica or upgrading a database instance class — modeled as discrete events tied to a specific projected trigger point, not smoothed into the average
def forecast_monthly_cost(
fixed_costs: float,
variable_cost_per_customer: float,
projected_customers: list[int],
step_function_events: list[dict]
) -> list[float]:
forecast = []
for month, customers in enumerate(projected_customers):
base = fixed_costs + (variable_cost_per_customer * customers)
step_costs = sum(
event["cost"] for event in step_function_events
if event["trigger_month"] <= month
)
forecast.append(base + step_costs)
return forecast
Grounding the Model in Actual Historical Data
Before projecting forward, we fit the cost-driver model against 6-12 months of historical AWS Cost and Usage Report (CUR) data, using Athena queries against the CUR to isolate cost by service, tag, and usage type. This calibration step is what separates a credible forecast from a guess — the model's per-customer variable cost assumption should match what actually happened historically, not an estimate pulled from a pricing calculator.
Building in Confidence Intervals, Not Single Numbers
A single-number forecast implies false precision. We present forecasts as a range — typically a base case, an aggressive-growth case, and a conservative case — so finance teams can budget against a realistic range rather than being blindsided when actual spend lands outside a single point estimate.
Tracking Forecast Variance Over Time
The forecast isn't a one-time deliverable. We set up a monthly variance report comparing actual spend against the forecast, broken down by cost driver, so any drift gets caught and the model recalibrated before it compounds into a large annual budget miss.
Results
For a client with historically volatile and hard-to-predict AWS spend, this methodology reduced forecast variance from a wide historical swing to within a much tighter band of actual spend across the following two quarters — giving their finance team a budget number they could actually plan around instead of padding heavily for uncertainty.
Want a cost forecast your finance team can actually trust? Get a free AWS cost review — 907-841-8407 or contact@rutagon.com.
Frequently Asked Questions
Why do most cloud cost forecasts turn out to be wrong?
Most forecasts extrapolate the total bill using a single growth multiplier, which ignores that different cost categories scale differently — some flat, some linear, some in step-function jumps at specific thresholds. This produces forecasts that look reasonable but diverge quickly from reality.
What data do you need to build an accurate cost forecast?
At minimum, 6-12 months of historical AWS Cost and Usage Report data, plus business growth projections (customer count, usage volume) that the cost drivers can be modeled against.
How often should a cloud cost forecast be updated?
We recommend monthly variance tracking against the forecast, with a full model recalibration at least quarterly or whenever a significant architecture or business change occurs.
Can this forecasting approach work for multi-cloud environments?
Yes, the cost driver decomposition methodology is cloud-agnostic. It requires pulling equivalent usage and billing data from each provider (AWS CUR, Azure Cost Management exports, GCP Billing export) and modeling drivers per platform.
Does a cost forecast help with reserved capacity purchasing decisions?
Yes. A driver-based forecast with confidence intervals gives a much stronger basis for deciding how much Reserved Instance or Savings Plan capacity to commit to than guessing off last month's bill alone.