Why

A forecast built on trend lines misses 20–50% of spend changes. Without documentation, the forecast is not repeatable — it lives in one person’s head and dies when they leave. A documented methodology with defined inputs (baseline + planned changes + trend adjustments) produces a projection that Finance and Engineering can act on.

What

Build a forecast model with three inputs: historical baseline, planned changes from demand intake, and trend/seasonality adjustments. Produce a forecast range (low/base/high) that feeds into budgeting.

How

Build the Baseline from Historical Data

The baseline answers: what will spend look like if nothing changes?

Choose your lookback period:

Scenario	Lookback	Why
Stable, predictable spend	6–12 months	Captures seasonality
Rapidly changing environment	3 months	Older data is misleading (post-migration)
New workload, no history	0 months	Use estimate from demand intake. Label as Low confidence.

Pull historical data per provider:

AWS — Use Cost Explorer CLI:

aws ce get-cost-and-usage \
  --time-period Start=2025-10-01,End=2026-04-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json > baseline_by_service.json

Pull by linked account for BU-level breakdown:

aws ce get-cost-and-usage \
  --time-period Start=2025-10-01,End=2026-04-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT \
  --output json > baseline_by_account.json

Azure — Use Cost Management exports or the portal: Cost Management → Cost Analysis → set granularity to Monthly → group by Subscription or Meter Category → Export CSV.

GCP — Query BigQuery billing export:

SELECT
  FORMAT_DATE('%Y-%m', usage_start_time) AS month,
  service.description AS service,
  SUM(cost) AS monthly_cost
FROM `billing_dataset.gcp_billing_export`
WHERE usage_start_time >= '2025-10-01'
GROUP BY month, service
ORDER BY month, monthly_cost DESC

Identify top cost drivers: The top 5 services typically drive 70–80% of total cost. Forecast these individually. Lump the rest into “other.”

Calculate growth rates: Compute month-over-month growth rate per service. This is your organic trend. Exclude anomaly months (any month 2×+ the average warrants investigation — common causes: bulk data transfers, load tests, forgotten dev instances).

Overlay Planned Changes

Layer the demand summary from S3-01 through S3-04 on top of the baseline:

FORECAST = BASELINE + PLANNED ADDITIONS - PLANNED REDUCTIONS
         ± COMMITMENT RATE CHANGES
         × TREND ADJUSTMENT

Apply Confidence Buffers

Not all estimates carry the same weight. Apply buffers to produce a forecast range:

Confidence Level	Buffer	Rationale
High	0–5%	Architecture finalised, team experienced
Medium	10–15%	Architecture in progress, some unknowns
Low	20–30%	Greenfield, new tech stack, unclear requirements

Present the base estimate to Engineering (they manage to the plan). Present the range to Finance (they set budgets with buffers).

FORECAST RANGE (Q3 2026)
═══════════════════════════════════════════════════════════════

                        Low         Base        High
  Jul:                 $460K       $477K       $498K
  Aug:                 $462K       $479K       $500K
  Sep:                 $464K       $481K       $503K
  Q3 Total:           $1,386K     $1,437K     $1,501K

Document the Methodology

Write down: lookback period, baseline calculation method, how planned changes are sourced, confidence buffer rules, anomaly exclusion criteria. This makes the forecast repeatable regardless of who runs it.

Deliverable Checklist

Historical baseline calculated per provider (by service and BU)
Growth rates computed per major service
Anomaly months identified and excluded
Planned changes overlaid from demand summary
Confidence buffers applied (low/base/high range)
Methodology documented and versioned