To segregate which T-instances tend to exceed their credit **budget** (the baseline earn rate), measure net credit consumption over a window. Exceeding baseline is the **leading indicator**; draining to zero, throttling, and surplus charges are the **lagging consequences** — catch the cause, not the symptom. **The metric — burn ratio:** - `total_spent = SUM(CPUCreditUsage)` over the window - `total_earned = earn_rate_per_hour(size) × window_hours` (t3.large 36/hr, t3.xlarge 96/hr, t3.medium 24/hr, …) - **`burn_ratio = total_spent ÷ total_earned`** — `>1` = net over budget, and the value is *how far* over (1.5 = spends 50% more than it earns → will deplete). Rank the fleet by `burn_ratio` descending. Simpler proxy: **`avg CPUUtilization − baseline %`** per instance (positive = over budget). **The trap — never rank by raw CPU% across a mixed-size fleet.** Baseline is per-size, so a t3.large at 35% is *over* its 30% baseline while a t3.xlarge at 35% is *under* its 40% baseline — same number, opposite verdict. Always compare each instance to *its own* baseline, or use the size-normalized burn ratio. (Baselines: [[EC2 Burstable Baseline Utilization]].) **Why a window aggregate is the right "tend to" measure:** brief above-baseline bursts are normal and self-funding; the budget is only blown when consumption exceeds earning *on net over time* — exactly what `burn_ratio > 1` over a ≥2-week window captures. A single spike won't tip it. For chronic-vs-occasional, count the % of 5-min periods where `CPUCreditUsage` exceeds the per-period earn rate. **Output tiers:** `>1` → over budget (upgrade candidate, severity ∝ ratio); `≈1` → at baseline (watch under forecast); `<1` → accruing (healthy; very low → downsize). Feeds [[EC2 Capacity Planning for Burstable Fleets]]. --- *Source: synthesized from [[EC2 Burstable Instance Credit Model]], [[EC2 Burstable Baseline Utilization]], and [[EC2 Capacity Planning for Burstable Fleets]].*