Cloud Capacity Forecasting
Capacity forecasting predicts future resource demand so that supply (instances, reservations, quotas) can be provisioned before it’s needed. Bad forecasts cause either incidents (under-provisioned) or waste (over-provisioned). The goal is not perfect accuracy — it’s bounded uncertainty with explicit confidence levels.
The fatal mistake: average-based planning
Most common capacity incident cause
Forecasting from average demand while capacity must handle peak and failover. Average tells you the typical load. Incidents happen at the tail.
Demand is a superposition of baseline trend, daily/weekly/annual seasonality, step-functions (migrations, launches), and failover shifts. Capturing only the baseline systematically under-estimates peak needs.
Correct approach: forecast at multiple percentiles (P50, P95, P99) and plan capacity for the percentile that matches your risk tolerance.
Forecast horizons
Different time horizons serve different decisions:
| Horizon | Purpose | Data sources | Decision it drives |
|---|---|---|---|
| 1 day | Anomaly detection | Near-real-time usage | Alert on sudden change |
| 1 week | Operational capacity | Recent utilization + ASG headroom | ASG min/max tuning |
| 1 month | Budget burn | Actuals + trend | Budget variance alerts |
| 1 quarter | Planning | Roadmap + migrations + commitments | Capacity requests, budget |
| 1 year | Commitment strategy | Growth model + product roadmap | Savings Plan / RI purchases |
What makes forecasting actually hard
Historical usage is the easy input. The hard inputs are things historical data can’t predict:
- Migrations — a workload moving from EC2 to Kubernetes changes demand shape across families simultaneously. The old family loses demand, the new gains it. If you forecast per-family independently, you miss the correlation.
- Latent demand — approved quota increases and pending capacity requests represent demand that hasn’t materialized yet. Pure time-series forecasting can’t see it.
- Failover demand — planning must include “what if we lose an AZ?” See failover modeling below.
- Commitment coupling — forecasting isn’t just “how much will we use?” but “how much of what we use matches our existing ODCR/SP shape?” A forecast that’s correct on total demand but wrong on family distribution can strand commitments.
Failover modeling
Standard capacity planning asks: “How much do we need during normal peak?” Failover planning asks: “How much do we need when an AZ dies?”
Failover demand = normal peak × (N / (N - failed_units))
For a service running in 3 AZs, losing one means the remaining 2 must handle 3/2 = 150% of normal per-AZ load. This means each AZ needs at least 50% headroom to survive single-AZ failure.
The implications for capacity reservations:
- ODCRs in each AZ must account for failover load from other AZs
- Or a cross-AZ failover pool must exist with enough total capacity
Confidence intervals
Point forecasts (“we’ll need 500 instances”) are less useful than ranges (“we’ll need 400–600 instances at 90% confidence”). Intervals communicate uncertainty and help decision-makers choose their risk tolerance:
- Conservative (high end of interval): more cost, less risk
- Aggressive (low end): less cost, more risk of capacity shortage
- Middle: balanced tradeoff
Forecast error tracking
Forecast quality must be measured to improve over time:
Forecast error = |actual - forecasted| / actual
Track by horizon (was the 1-month forecast better than the 1-quarter forecast?) and by cause (was error from missed migration, wrong growth rate, or unexpected spike?).
Useful decomposition:
- Bias — are forecasts systematically over or under?
- Variance — how much do forecasts fluctuate?
- Shock — how often do unforeseeable events dominate?
Practical forecasting approaches
Simple: trailing percentile + growth rate
Forecast = P95(last_4_weeks) × (1 + monthly_growth_rate) ^ months_ahead
Works well for steady-state services with predictable growth. Breaks down for seasonal or event-driven workloads.
Moderate: seasonal decomposition
Decompose into trend + seasonality + residual. Project trend forward, apply seasonal pattern. Tools: Prophet, statsmodels STL decomposition.
Advanced: capacity simulation
Model specific scenarios:
- “What if traffic grows 30%?”
- “What if we lose us-east-1a?”
- “What if the migration lands 2 weeks early?”
Run each scenario through the capacity model and check whether supply covers demand. This is particularly valuable for quarterly planning.