The capacity-sizing test you apply depends on the instance class, because the two classes have fundamentally different limiting behavior. **Fixed-performance (M/C/R) — size against the peak.** No credit economy; a hard instantaneous ceiling of 100%. A peak that exceeds capacity saturates *immediately* — there is nothing to smooth it. Test: **projected p95/p99 ≤ ~70%**, leaving headroom for spikes and autoscaling reaction time. The question is *"can the peak fit under the ceiling?"* **Burstable (T-family) — size against the average relative to baseline.** Credits are earned and spent continuously and integrate over time, so the credit balance trends up or down according to **average** utilization versus the baseline %, not any single spike. Brief bursts above baseline are by design — paid for by credits banked while below baseline. Test: **projected average < baseline %**, so the balance net-accrues. The question is *"does the average leave the credit account growing?"* **Why the distinction is load-bearing:** the peak test cannot separate two T-instances with the same p95 but different averages — one healthy, one quietly depleting credits. Applying the fixed-instance peak test to a burstable instance therefore misjudges it — a sibling of the [[Burstable CPU Utilization Masks Saturation]] trap (reading a burstable instance with fixed-instance intuitions). In one line: **fixed = can the peak fit under the ceiling; burstable = does the average leave the credit account growing.** --- *Source: synthesized from [[Burstable CPU Utilization Masks Saturation]], [[EC2 Burstable Baseline Utilization]], and [[Sizing Capacity for Forecasted Load]].*