Sizing for a **near-term load increase** is a two-input method: get the growth factor, then project current utilization forward and test it against a headroom target. **1. Get the growth factor.** - **Known event** (launch, campaign, migration): use its expected load multiple directly — +40% → factor 1.4. - **General growth**: extrapolate the trend slope over a representative window (≥2 weeks) and project to the target date. **2. Project and test headroom.** Work from a peak statistic (**p95/p99**), never the average — averages hide the spikes that actually breach capacity. `projected_p95 = current_p95 × (1 + growth)` - **Fixed-performance instances** (M/C/R): target projected p95 ≤ **70%** — leave ~30% for spikes and autoscaling reaction time. Above that → upsize or scale out before the event. - **Burstable (T-family): the binding test is different.** Projected *average* utilization must stay **below the instance's baseline %** so CPU credits keep accruing. A T-instance can pass a p95 check and still deplete credits if its sustained average crosses baseline under the new load — so check the average against baseline, not just the peak. (Baseline = (credits/hr ÷ vCPUs) ÷ 60; see [[EC2 Burstable Baseline Utilization]].) **Act before the event, not during it.** Provisioning isn't instant — new capacity, credit re-accrual, and ASG warm-up all take time — so the change must land *ahead* of the forecasted increase. The per-instance output is a projected-load verdict feeding [[EC2 Capacity Planning for Burstable Fleets]]. --- *Source: synthesized from [[EC2 Capacity Planning for Burstable Fleets]] and [[EC2 Burstable Baseline Utilization]], plus general capacity-planning practice.*