T Instance Credit System

Burstable T instances provide a low baseline level of CPU and the ability to run above it for a while. The mechanism is a credit balance: the instance earns credits continuously while it stays under its baseline and spends them when it goes over.

One CPU credit equals one vCPU running at 100% utilisation for one minute — equivalently, one vCPU at 50% for two minutes, or two vCPUs at 25% for two minutes.

Baseline and earn rate

Each instance size earns a fixed number of credits per hour, and that rate defines the baseline:

baseline utilisation % = (credits earned per hour / vCPUs) / 60 minutes

A t3.nano has 2 vCPUs and earns 6 credits per hour, so its baseline is (6 / 2) / 60 = 5% per vCPU. A t3.large earns 36 credits per hour on 2 vCPUs, so its baseline is 30%.

Instance	Credits per hour	Max accrued credits	vCPUs	Baseline per vCPU
t3.nano / t4g.nano	6	144	2	5%
t3.micro / t4g.micro	12	288	2	10%
t3.small / t4g.small	24	576	2	20%
t3.medium / t4g.medium	24	576	2	20%
t3.large / t4g.large	36	864	2	30%
t3.xlarge / t4g.xlarge	96	2304	4	40%
t3.2xlarge / t4g.2xlarge	192	4608	8	40%

CloudWatch reports CPUUtilization per vCPU, so a t3.large sitting exactly at its baseline shows as 30%.

Accrual limit

Credits on a running instance do not expire, but the balance is capped: the accrual limit is whatever the instance can earn in 24 hours, which is the third column above. Once the balance is full, newly earned credits are discarded. An instance that has been idle for a week has no more burst headroom than one idle for a day.

Burst behaviour

When demand exceeds the baseline the instance spends accrued credits and can run up to 100% CPU for as long as the balance lasts. As the balance approaches zero, performance falls back towards the baseline; the transition is gradual rather than a cliff.

Standard and unlimited mode

Standard mode. The instance bursts only while it has accrued credits. When they run out it sits at the baseline until it earns more. There is no charge beyond the instance price, and no way to exceed the baseline on a sustained basis.

Unlimited mode. When accrued credits are exhausted the instance keeps bursting on surplus credits. If average CPU over a rolling 24-hour window (or the instance lifetime, whichever is shorter) stays at or below the baseline, the surplus is paid off by later earnings and costs nothing extra. If it does not, the excess is billed at a flat rate per vCPU-hour.

T3, T3a and T4g launch in unlimited mode by default. T2 launches in standard mode by default. The mode can be changed at any time. Unlimited mode is not supported for T3 instances on a Dedicated Host.

Launch credits

Launch credits are a one-off allocation that lets a freshly launched instance burst before it has earned anything. Only T2 instances in standard mode receive them. T3, T3a and T4g do not need them: they launch in unlimited mode and can burst immediately.

Stop and start

• T2 — the credit balance is lost entirely when the instance stops.
• T3, T3a and T4g — the balance persists for seven days after the instance stops. Start it within seven days and nothing is lost; leave it longer and the credits are gone.

Monitoring

Four CloudWatch metrics matter:

• CPUCreditUsage — credits spent in the period
• CPUCreditBalance — credits currently accrued
• CPUSurplusCreditBalance — surplus borrowed in unlimited mode
• CPUSurplusCreditsCharged — surplus that was billed rather than paid off

Practical guidance

• T instances suit workloads that are idle or light most of the time with occasional spikes: development environments, low-traffic sites, internal tools, cron hosts.
• Alarm on CPUCreditBalance trending towards zero. A balance that stays at zero means the instance is permanently capped at baseline, which looks like an unexplained performance ceiling.
• If CPUSurplusCreditsCharged is consistently non-zero, the workload is not burstable — it is a steady load on the wrong instance family. Move it to an M or C instance and it will usually be both faster and cheaper.
• Use standard mode where a surprise bill is worse than a slow instance (development, test, non-critical batch); use unlimited mode where the reverse is true.