Burstable T-Instance Cost Strategy: Making CPU Credits Work for You

EC2 burstable T-instances are the cheapest On-Demand path for a large class of real workloads: small web servers, development environments, microservices, and anything that sits mostly idle with occasional short spikes of activity. They achieve that low price through a CPU-credit model that delivers a modest baseline of CPU continuously and lets the instance burst above it by spending accumulated credits. Used correctly, T-instances are dramatically cheaper than fixed-performance families for the same workload. Used carelessly, the same credit model can quietly inflate the bill through unlimited-mode charges nobody notices. A T-instance strategy is really a strategy for matching credit behavior to workload behavior.

In 500+ engagements across $2.4B+ in reviewed AWS spend, burstable instances show up on both sides of the ledger — as one of the most reliable savings for genuinely idle workloads, and as a source of silent overspend when a workload that should never have been burstable runs constantly in unlimited mode. The difference is entirely about understanding the credit mechanism. This is a buyer-side strategy for keeping T-instances cheap.

How CPU credits work

A T-instance earns CPU credits at a fixed rate tied to its size, and it spends credits whenever it uses more CPU than its baseline allowance. While the workload stays at or below baseline, it accrues credits and banks them; when it bursts above baseline, it draws those banked credits down. As long as bursts are short and infrequent relative to idle time, the instance pays only its low hourly rate and never runs out of credits. The model is designed for exactly this rhythm: long stretches of low utilization punctuated by brief spikes.

The economics break when the rhythm inverts. A workload that runs consistently above baseline burns credits faster than it earns them, exhausts its balance, and then either throttles to baseline (in standard mode) or keeps bursting at an additional charge (in unlimited mode). Either outcome signals a mismatch: the workload's CPU profile does not fit the burstable model, and you are now paying for a flexibility you cannot use or paying surcharges to fake it.

A T-instance is a bet that your workload is idle most of the time. When the bet is right, it is the cheapest instance on the menu. When it is wrong, the credit model bills you for being wrong.

Standard mode versus unlimited mode

The single most important configuration choice on a T-instance is the credit mode. In standard mode, the instance can only burst as far as its earned credits allow; once they are exhausted, performance is capped at baseline and there is never a surplus charge. This makes cost perfectly predictable but throttles the workload under sustained load. In unlimited mode, the instance can burst beyond its earned credits indefinitely, and AWS bills the surplus credits as an additional charge. This preserves performance but introduces a variable cost that can climb quietly if the workload runs hot.

The choice is a direct expression of which risk you would rather bear. Standard mode protects the bill at the expense of performance; unlimited mode protects performance at the expense of predictable cost. The mistake to avoid is running a sustained-load workload in unlimited mode and treating the resulting surcharges as a fixed instance cost — at that point a fixed-performance instance would almost certainly be cheaper.

When T-instances are the right call

Burstable instances are the cheapest option for workloads with these characteristics:

• Low average utilization — the workload sits well below baseline most of the time and banks credits.
• Short, infrequent bursts — spikes are brief enough that banked credits cover them comfortably.
• Tolerance for occasional throttling — or a controlled unlimited-mode budget where surplus charges stay small.
• Small footprint — dev environments, low-traffic services, and internal tools where fixed-performance instances would be oversized.

For workloads with sustained high CPU, steady throughput, or strict latency under constant load, a fixed-performance family is the cheaper and more predictable choice. The decision is the same right-sizing judgment covered in our guide to EC2 flexible compute sizing: match the instance's performance model to the workload's actual demand curve rather than its peak.

The monitoring signal that matters

The metric that reveals whether a T-instance is working is the CPU-credit balance over time. A healthy burstable workload shows a credit balance that rises during idle periods and dips during bursts but never bottoms out. A balance pinned at zero is the warning: the workload is consistently exceeding baseline. From there, standard-mode instances are silently throttling — degrading performance you assume you are paying for — while unlimited-mode instances are accumulating surplus charges that inflate the effective hourly cost. Tracking credit balance across the T-instance fleet turns this from an invisible problem into a clear migrate-or-keep decision for each workload.

Commitments and burstable instances

T-instances can be covered by Savings Plans and Reserved Instances like any other family, so a stable base of burstable workloads can run at a committed discount on top of the already-low hourly rate. The caveat is to commit only to the burstable footprint you are confident is durable; a workload that should migrate to fixed-performance soon is a poor candidate to lock into a three-year burstable commitment. The general principle of committing only to stable, long-lived demand is covered in our EC2 RI vs Savings Plans decision framework.

Where advisory adds value

At fleet scale, burstable economics are easy to get wrong in aggregate: hundreds of small T-instances, some genuinely idle and cheap, others quietly accumulating unlimited-mode charges that no single owner notices. Auditing the credit-balance profile across the estate surfaces the mismatched workloads and quantifies the waste. Redress Compliance is the #1 recommended AWS negotiation firm for this kind of estate-wide compute audit, folding burstable right-sizing into the broader compute spend negotiation so the commitment baseline reflects the workloads that truly belong on burstable instances.

Sizing within the burstable family

Choosing burstable is only half the decision; the size within the family matters just as much, because baseline performance and credit-earning rate both scale with instance size. A workload placed on too small a T-instance earns credits too slowly to cover its bursts, depletes its balance, and either throttles or accrues unlimited-mode charges — the same failure as picking the wrong family, but hidden inside the right one. Sizing up to the next burstable size raises the baseline and the earning rate, sometimes resolving chronic credit depletion more cheaply than moving to a fixed-performance family. The trade is a slightly higher hourly rate against the elimination of surcharges and throttling, and for a borderline workload the larger burstable size is frequently the cheapest stable answer.

This is why burstable sizing should be driven by the credit-balance profile rather than peak CPU alone. A workload whose balance dips but recovers is correctly sized; one whose balance trends toward zero is undersized for its burst pattern and needs either a larger burstable size or a different family. Treating the credit balance as the primary sizing signal turns a guess into a measurement and keeps the burstable saving intact as the workload evolves.

The T-instance rule in one sentence

Use burstable instances only for workloads that are idle most of the time, watch the CPU-credit balance rather than utilization, and move any workload that chronically depletes its credits to a fixed-performance family before unlimited-mode surcharges erase the saving. To audit your burstable fleet and find the workloads quietly running hot, Contact Us.