# Credit Burn Ratio Explained **Parent Topic**: [[Software/README]] A teaching explainer for the **CPU-credit burn ratio** on AWS burstable (T-family) instances — the intuition, the formula, a worked example, and the traps. The terse analytical version is [[Credit Burn Ratio for Burstable Fleets]]; the principles behind it are [[EC2 Burstable Capacity from First Principles]]. Earn rates and baselines below are verified against AWS official docs (2026-06-18). ## One sentence Burn ratio asks "**is this instance spending CPU credits faster than it earns them?**" — above 1 means yes, and the value is *how far* over. ## The bank-account analogy A burstable instance has a **salary**, **savings**, and **spending**: - **Salary (earn rate)** — credits earned per hour, fixed by size. This *is* the baseline: the CPU level it can sustain forever. - **Savings (credit balance)** — banked credits, spent to burst above baseline. Caps at **24 hours' worth of salary** — you can't save more than that. - **Spending (credit usage)** — credits burned by the actual workload. Spend under salary → savings grow. Spend over salary → savings drain. Hit zero → throttled down to baseline (standard mode) or charged overdraft fees (unlimited mode). ## The formula ``` total_spent = SUM(CPUCreditUsage) over the window total_earned = earn_rate_per_hour(size) × window_hours burn_ratio = total_spent ÷ total_earned ``` - `< 1` → living within means, accruing — **healthy** - `≈ 1` → breaking even at baseline — **watch under load growth** - `> 1` → spending over income, will deplete — **upgrade candidate** (severity ∝ ratio: 1.5 = spending 50% over) Rank the fleet by burn ratio descending; the top is the shortlist. ## Verified earn rates & baselines (AWS official, 2026-06-18) | T3 size | vCPUs | Credits/hr | Baseline /vCPU | |---|---|---|---| | t3.small | 2 | 24 | 20% | | t3.medium | 2 | 24 | 20% | | t3.large | 2 | 36 | 30% | | t3.xlarge | 4 | 96 | 40% | | t3.2xlarge | 8 | 192 | 40% | T3a and T4g share the same rates. **1 credit = 1 vCPU × 100% × 1 minute.** Baseline is **per vCPU**, and CloudWatch `CPUUtilization` is also per vCPU — so the baseline % is directly comparable to the CloudWatch number. ## Worked example (illustrative usage) A **t3.large** earns 36 credits/hr → over a 2-week window (336 h) it earns `36 × 336 = 12,096` credits. | If it spent... | burn ratio | verdict | |---|---|---| | 9,000 | 0.74 | accruing — healthy | | 12,000 | 0.99 | at baseline — watch | | 18,000 | 1.49 | over budget — will deplete, upgrade | ## Unlimited mode: when the burn ratio becomes a dollar figure In **standard** mode an over-budget instance throttles to baseline. In **unlimited** mode (the T3/T3a/T4g default) it keeps bursting and **bills you instead** — surplus credits at a flat **$0.05 per vCPU-hour** (Linux; Windows $0.096; varies by region — check the pricing page). The conversion is `surplus_credits ÷ 60 = vCPU-hours`, since 1 credit = 1 vCPU-minute. **AWS's micro-example** (mechanism anchor): a t2.nano spends ~25 surplus credits → `25 ÷ 60 = 0.42` vCPU-hours → `0.42 × $0.05 = $0.02`. You're only charged once the surplus balance passes the 24h-earnable max and can't be paid down by earned credits. **Worked example tied to the burn ratio** (steady-state, illustrative): a **t3.large** in unlimited mode held at a sustained **80% CPU** (per vCPU), well above its 30% baseline: ``` spent = 2 vCPU × 80% × 60 min = 96 credits/hr earned = 36 credits/hr burn ratio = 96 ÷ 36 = 2.67 ← chronically over budget net surplus = 96 − 36 = 60 credits/hr → 60 ÷ 60 = 1.0 vCPU-hour/hr charge = 1.0 × $0.05 = $0.05/hr ≈ ~$36/month surplus ``` That ~$36/month rides *on top of* the base instance price — invisible on the CPU graph, easy to miss until the bill arrives. The teaching point: **a sustained burn ratio > 1 in unlimited mode is not "fine, it just bursts" — it is a recurring bill.** Burn ratio is the early-warning; `CPUSurplusCreditsCharged > 0` is the lagging confirmation you're already paying. Either right-size to a fixed-performance family (M/C) or accept the surplus cost deliberately, not by accident. ## The trap to hammer home **Never rank a mixed-size fleet by raw CPU%.** Baseline is per-size, so the same number means opposite things: > t3.large at 35% CPU → **over** its 30% baseline (bleeding credits) > t3.xlarge at 35% CPU → **under** its 40% baseline (banking credits) Same 35%, opposite verdict. Compare each instance to *its own* baseline — which is exactly what dividing by that instance's earn rate does. That normalization is the whole point. ## Why a window, not a snapshot Brief bursts above baseline are normal and self-funding — that's what savings are *for*. The budget is only blown when spending exceeds earning **on net over time**, which a ≥2-week window captures and a single spike won't tip. For chronic-vs-occasional, count the % of 5-minute periods where `CPUCreditUsage` exceeds the per-period earn rate. ## Punchline for the team Burn ratio turns "is this instance healthy?" from a CPU-graph guess into one comparable number across the whole fleet — a **leading** indicator (over budget) instead of a **lagging** one (already throttled, already paying surplus charges). Catch the cause, not the symptom. --- *Source: [[Credit Burn Ratio for Burstable Fleets]] (analytical definition) plus AWS EC2 burstable documentation — [Key concepts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html) (earn rates / baselines) and [Unlimited mode examples](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/unlimited-mode-examples.html) (surplus billing: $0.05/vCPU-hour Linux, credits ÷ 60 = vCPU-hours). All figures verified 2026-06-18.*