EC2 burstable instances (T-family: T4g/T3a/T3, previous-gen T2) serve workloads that are mostly idle with occasional spikes. You pay for a low **baseline CPU %** — set by instance size — and bank unused capacity as **CPU credits** to spend on bursts. Cheaper than a fixed high-core instance you rarely fully use. **Earn and spend.** One CPU credit = one vCPU at 100% for one minute (or an equivalent mix of vCPUs, utilization, and time). Running **below baseline** earns more credits than it spends, so `CPUCreditBalance` grows — capped per instance size, with excess discarded. Running **above baseline** spends faster than it earns, draining the balance. The balance behaves like a savings account: idle time deposits, bursts withdraw. **Zero-balance fork — the defining behavior.** What happens when credits run out depends on the mode: - **Standard mode** — CPU is throttled down to baseline; bursts stop, no extra charge, performance degrades. - **Unlimited mode** — the instance keeps bursting by borrowing *surplus* credits, auto-repaid once it drops below baseline. Surplus exceeding the 24-hour maximum-earnable is billed (`CPUSurplusCreditsCharged`, per vCPU-hour). Trades the performance cliff for a cost cliff. **Credit persistence on stop:** T3/T3a/T4g retain accrued credits for 7 days; T2 loses them immediately. **Decision rule.** Burstable fits load that is spiky and averages below baseline. It is the wrong family for sustained above-baseline load — you either throttle constantly (standard) or pay surplus indefinitely (unlimited), where a fixed-performance M/C/R instance is cheaper and more predictable. A steadily declining `CPUCreditBalance` is the signal you've outgrown it — see [[EC2 Burstable CPU Credit Monitoring]]. --- *Source: [[AWS EC2 Burstable Key Concepts (AWS Docs)]] — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html*