An EC2 t3 instance running a web service performs well for a while and then its CPU flatlines at a low fixed percentage while requests queue up. Explain the burstable T-instance CPU credit mechanism behind this, and what unlimited mode changes.

## What "burstable" actually sells you Every EC2 instance type is a slice of a physical host, but the T family sells a slice that is *smaller than it looks*. A t3.large reports 2 vCPUs to the operating system, and those vCPUs really exist — but your entitlement is only a **baseline** fraction of them over time. The credit system is the accounting mechanism that enforces that entitlement while still letting you exceed it in short bursts. That is the whole idea: most small services idle most of the time and spike occasionally, so AWS can oversubscribe the host and pass the saving on. ## Credits, baseline and the balance cap Three numbers define the behaviour, and all three are per instance **size**: 1. **Accrual rate** — credits earned per hour, fixed for the size. 2. **Baseline utilisation** — the percentage of a vCPU you can sustain forever without spending any net credits. Small sizes have baselines in the low tens of percent; larger T sizes have higher baselines. 3. **Maximum balance** — the cap on banked credits, which corresponds to roughly 24 hours of accrual. One CPU credit equals one vCPU running at 100% for one minute; equivalently, one vCPU at 50% for two minutes. When actual utilisation is below baseline you bank the difference; when it is above, you burn the difference. The 24-hour cap is why the symptom in the question has that particular shape: a freshly launched or long-idle instance carries a full balance, absorbs the traffic beautifully for hours, then falls off a cliff when the bank empties. ## Standard mode: the cliff In standard mode, an empty balance means the hypervisor throttles you to baseline. The signature in CloudWatch is unmistakable and worth being able to describe: - `CPUUtilization` rises, then pins to a flat line at exactly the baseline percentage and stays there. - `CPUCreditBalance` decays to zero just before that flat line begins. - `CPUCreditUsage` shows the burn rate that got you there. - Application latency climbs and queues grow while the CPU graph looks *calm* — which is why teams often misread it as a downstream problem. T2 instances also receive a one-off allowance of **launch credits** so a fresh instance is not throttled during boot and warm-up; those are limited and not replenished, and they mask the problem during exactly the window in which people test. ## Unlimited mode: the bill instead of the cliff Unlimited mode removes the throttle. The instance keeps bursting and accumulates **surplus credits**, tracked as `CPUSurplusCreditBalance`. Surplus is repaid automatically from credits earned in the following hours; anything not repaid within the trailing window, or left outstanding when the instance is stopped or terminated, is charged at a flat published rate per vCPU-hour and surfaces as `CPUSurplusCreditsCharged`. Defaults differ by generation, which is the single most-missed fact here: **T2 launches in standard mode, while T3, T3a and T4g launch in unlimited by default.** So a modern t3 fleet usually does not throttle — it quietly generates a bill line instead. A team that has explicitly set standard mode (or copied an old launch template) gets the throttle behaviour back. ```bash # Check and change the credit mode of a running instance aws ec2 describe-instance-credit-specifications --instance-ids i-0123456789abcdef0 aws ec2 modify-instance-credit-specification \ --instance-credit-specification InstanceId=i-0123456789abcdef0,CpuCredits=unlimited ``` ## Diagnosing it in production The diagnosis is three steps. Confirm the flat CPU line sits at the size's documented baseline rather than at some arbitrary plateau. Overlay `CPUCreditBalance` and check it hit zero first. Then check the credit specification — if it says `standard`, you have found the cause; if it says `unlimited`, look at `CPUSurplusCreditsCharged` on the bill and treat the workload as mis-classified rather than mis-configured. ## The real decision Unlimited mode is a patch, not a design. The credit model is built for **spiky, mostly idle** workloads: dev environments, internal tools, low-traffic sites, bastion hosts. A service with steady CPU demand pays surplus charges every hour it runs and, at that point, a same-size `m` or `c` instance is usually both cheaper and predictable — no cliff, no surprise line item, and a CPU graph that means what it says. Burstable families also compound badly with autoscaling: an autoscaling group that adds T instances under load may add machines whose credit balances are already depleted, so the new capacity is throttled from the moment it becomes healthy. Stating that tradeoff — spiky yes, sustained no — is what an interviewer is listening for, more than the exact accrual numbers.