Explanation
Why the waste happens and who it affects.
T3, T3a, T4g and T8i instances launch in unlimited mode by default, which lets them burst above the baseline for as long as needed by spending surplus credits. If the instance's average CPU over a 24-hour period stays above its baseline, the surplus credits that are not paid down are billed at a flat additional rate per vCPU-hour, on top of the instance's hourly price.
This is common when a T instance chosen for a light workload becomes a steadily busy one, or when T instances are used as a cheap default for build agents, batch jobs or small production services. The extra charge does not appear as a separate resource and performance never degrades, so it is easy to miss. AWS documents a breakeven point beyond which a burstable instance in unlimited mode costs more than an equivalently sized fixed-performance instance; for example, a t3.large costs more than an m5.large above 42.5 percent average CPU, and a T3 bursting continuously at 100 percent costs about 1.5 times the equivalent M5 (us-east-1, Linux).
Billing model
The pricing dimensions that drive this cost.
- Instance hourly price
- Covers CPU usage up to the instance's baseline utilization per vCPU
- Surplus credits
- Credits spent after the earned CPUCreditBalance reaches zero; they are paid down by credits earned when CPU drops below baseline
- Surplus credit charge
- Surplus credits not paid down are billed per vCPU-hour; AWS lists $0.05 for T2 and T3 and $0.04 for T4g on Linux, RHEL and SLES, the same across sizes and Regions
- When charges post
- When spent surplus credits exceed the maximum the instance can earn in 24 hours, when the instance stops or terminates, or when it switches from unlimited to standard
How to detect
5 checks to find it in your estate.
- Query the CloudWatch metric CPUSurplusCreditsCharged per instance; any sustained non-zero value means the instance is paying for CPU above its hourly price
- Track CPUSurplusCreditBalance for unlimited instances; a balance that stays high means the instance is not earning enough credits to pay down its bursting
- Compare 24-hour average CPUUtilization with the instance type's baseline utilization per vCPU from the credit table, and with the breakeven CPU percentage for the equivalent fixed-performance type
- List credit settings with describe-instance-credit-specifications and check the account-level default credit specification per T family and Region
- Review Compute Optimizer recommendations for T instances, whose CPU utilization graph shows the burstable baseline alongside actual usage
How to fix
5 ways to remove the waste.
- Move instances whose average CPU stays above the breakeven point to a fixed-performance type of suitable size (for example M or C family), which removes the surplus charge
- Where occasional throttling to baseline is acceptable, switch the instance to standard credit mode; note that any outstanding CPUSurplusCreditBalance is charged immediately at the switch
- Consider a larger T size only if the workload's average CPU would stay below that size's baseline
- Set the account default credit specification for each T family deliberately, and set the credit option explicitly in launch templates for workloads with known sustained load
- Create CloudWatch alarms on CPUSurplusCreditsCharged so new cases are caught within hours rather than at month end
Documentation
Vendor references for pricing and configuration.