The burstable CPU credit trap: when T instances cost more than M

Published May 18, 2026

AWS T-series instances are the default choice for millions of developers. When you need a quick virtual machine, t4g.medium ($0.0336/hr in us-east-1) or t3.medium ($0.0416/hr) looks dramatically cheaper than an M-series dedicated instance.

The catch is in the fine print of AWS burstable performance. T instances do not give you full, uninterrupted CPU cores for that sticker price. Instead, they give you fractional baseline compute capacity, plus a credit bucket for short bursts.

Since AWS launched T3 in 2018 and T4g in 2020, burstable instances run in Unlimited mode by default. When your CPU credit balance drops to zero, the instance does not throttle. It keeps running at 100% clock speed and bills surplus credits directly to your AWS invoice at $0.05 per vCPU-hour (for Linux).

Under steady load, that surplus charge turns T-series into one of the most expensive ways to buy compute on AWS.

How CPU credit accounting works

A CPU credit equals one vCPU running at 100% utilization for one minute (or any equivalent slice, such as two vCPUs at 50% for one minute). Over an entire hour, one vCPU running at full throttle consumes 60 CPU credits.

Every T-series instance earns credits continuously at a fixed hourly rate determined by its size. This rate dictates its baseline CPU performance.

Standard vs. Unlimited mode

• T2 (Standard by default): When your credit balance hits zero, your CPU is hard-throttled down to the baseline percentage. Your web server drops connections, response latency spikes into seconds, and SSH sessions freeze.
• T3 / T4g (Unlimited by default): Your instance never throttles. When the credit balance is exhausted, AWS tracks a negative credit balance (CPUSurplusCreditCharged). If you do not earn those credits back within a rolling 24-hour window, AWS bills each surplus credit at $0.05 per vCPU-hour ($0.000833 per credit).

For dev machines or staging servers, Unlimited mode prevents sudden performance cliffs. For production workloads with sustained CPU activity, it creates an unmonitored billing leak.

The $0.05/vCPU-hour surcharge math

Let’s walk through what happens when you run a sustained workload on a t3.xlarge (4 vCPUs, 16 GiB RAM).

1. Base instance cost: $0.1664 per hour.
2. Baseline allowance: 40% baseline per vCPU = 1.6 vCPUs (96 credits earned per hour).
3. Consumption at 100% CPU: 4.0 vCPUs = 240 credits spent per hour.
4. Deficit per hour: 240 spent - 96 earned = 144 surplus credits needed per hour.
5. Surplus vCPU-hours: 144 credits / 60 credits per vCPU-hour = 2.4 vCPU-hours per hour.
6. Surplus cost: 2.4 vCPU-hours * $0.05 = $0.1200 per hour.

Add the base price and surplus charge together:

$0.1664 (base) + $0.1200 (surplus) = $0.2864 per hour ($209.07/month)

Now compare that $0.2864/hr figure against dedicated general-purpose instances with the same 4 vCPUs and 16 GiB of RAM:

At 100% CPU utilization, running a burstable t3.xlarge costs 46% more than a dedicated Graviton2 instance (m6g.xlarge) and 30% more than a top-tier Intel instance (m7i.xlarge). You pay a heavy premium for older hardware with shared hypervisor noisy-neighbor characteristics.

Even more striking: m6g.xlarge ($0.1540/hr) and m7g.xlarge ($0.1632/hr) have lower base prices than t3.xlarge ($0.1664/hr) even at zero percent CPU utilization. Running a t3.xlarge when your software can compile for arm64 is an immediate overpayment before the instance executes a single instruction.

The crossover threshold: where T loses

You don’t need 100% CPU utilization to trigger the penalty. Every burstable instance has a mathematical crossover point: the exact sustained CPU utilization percentage above which a dedicated M-series instance costs less.

The crossover formula is straightforward:

Crossover CPU % = Baseline % + (Dedicated Hourly Price - Burstable Base Price) / (vCPUs * $0.05)

Here are the crossover thresholds for common configurations in us-east-1 (Linux):

If your t3.xlarge runs an average sustained CPU load higher than 52.8%, switching to a dedicated m6i.xlarge or m5.xlarge cuts your bill. If your t4g.large runs above 44.4% sustained CPU, moving to m7g.large saves money while delivering dedicated compute.

Workloads that trigger the trap

Burstable instances work well for spiky, low-duty workloads. Problems start when developers treat them as general-purpose compute.

1. Background worker fleets (Sidekiq, Celery, BullMQ)

Queue workers pull jobs from Redis or SQS. When a backlog accumulates, workers peg CPU at 100% until the queue clears. On T Unlimited, a burst of 100,000 image resizes or PDF generations consumes all credits in minutes, running the rest of the batch on $0.05/vCPU-hour surplus billing.

2. Microservice and web APIs with sustained baseline traffic

A web service that handles steady daily traffic at 40-60% average CPU will steadily drain its credit bucket. Once empty, every daytime traffic bump runs on surplus credits.

3. Databases and in-memory caches (PostgreSQL, MySQL, Redis)

Database engines need predictable I/O and consistent CPU scheduling. When query volume grows, database processes burn credits maintaining connections, processing vacuum jobs, and running analytics queries. If you run self-managed databases or Redis instances on T3/T4g in production, check your surplus metrics immediately.

4. CI/CD runners running long compilation loops

Burstable instances work for occasional quick test runs. If your CI worker processes a continuous queue of TypeScript, Rust, or Go builds, CPU stays pinned near 100%. Dedicated compute or autoscaling ephemeral instances on Spot will cost a fraction of T Unlimited surcharges.

Sizing rules: when to use T vs. M

Follow these guidelines when picking instance types:

                          Average Sustained CPU Utilization
                          
  0% ──────────── 20% ──────────── 40% ──────────── 60% ──────────── 100%
  ┌───────────────────┐
  │  T-Series Ideal   │
  │  (t4g / t3)       │
  └───────────────────┘
                      ┌─────────────────────────────────────────────────┐
                      │  M-Series Dedicated (m7g / m6g / m7i)           │
                      │  Predictable performance, lower total cost      │
                      └─────────────────────────────────────────────────┘

Keep on T-series (t4g / t3):

• Development and staging environments: Servers that sit idle outside working hours easily accumulate maximum credit reserves.
• Low-frequency cron jobs: Tasks that execute once an hour for 90 seconds.
• Internal admin tools and low-traffic backends: Dashboards accessed by a dozen internal employees.
• Bastion hosts and jump boxes: Pure connection proxies with near-zero CPU requirements.

Move to dedicated compute (M-series / C-series):

• Any production service averaging >40% CPU utilization.
• Long-running batch processors and queue consumers.
• Production databases, message queues, and cache clusters.
• Workloads with strict p99 latency SLAs: Burstable instances share physical CPU cores with other tenants; dedicated instances eliminate noisy-neighbor latency jitter.

Auditing your AWS fleet

To verify if your account is paying hidden burstable surcharges:

1. Check CloudWatch Metrics: Open CloudWatch and chart CPUSurplusCreditCharged and CPUCreditBalance across all running EC2 instances over the last 30 days.
2. Review Cost Explorer: Filter by Usage Type containing CPUCredits:vCPU-Hours.
3. Compare Specs and Pricing: Use the instance explorer to review current generation pricing, or drop your active instance list into the comparison tool to inspect dedicated alternatives side by side.