What Happens When an EC2 Instance Exhausts CPU Credits?

When a burstable Amazon EC2 instance running in Standard mode exhausts its accrued CPU credit balance, its CPU performance is gradually throttled down to its baseline utilization level. The instance does not shut down, reboot, or incur extra usage charges. Instead, the underlying hypervisor restricts the vCPUs from bursting above their designated baseline capacity until the instance uses less CPU than its baseline and begins accumulating a positive credit balance again.

Understanding Burstable Performance Instances

Amazon EC2 T-series instances (such as T2, T3, T3a, and T4g) are designed to provide a baseline level of CPU performance with the ability to burst to higher levels when required by your workload. These instances are ideal for workloads that do not use the full CPU often or consistently, such as web servers, developer environments, and small databases.

The governance of this bursting capability relies on a credit system. Every burstable instance continuously earns CPU credits at a fixed rate determined by the instance size. When the instance requires less CPU capacity than its baseline, the unused credits are stored in a credit balance for later use.

How CPU Credits Are Earned and Spent

A single CPU credit represents the performance of a full vCPU core running at \(100\%\) utilization for one minute. This metric can also be divided across multiple vCPUs or different utilization percentages. For example, one CPU credit is equivalent to:

\[\text{1 CPU Credit} = \text{1 vCPU} \times 100\% \text{ utilization} \times \text{1 minute}\]

\[\text{1 CPU Credit} = \text{2 vCPUs} \times 50\% \text{ utilization} \times \text{1 minute}\]

\[\text{1 CPU Credit} = \text{1 vCPU} \times 25\% \text{ utilization} \times \text{4 minutes}\]

The net change in an instance's credit balance over a given minute can be expressed with the following formula:

\[\Delta \text{Credits} = \text{Credits Earned} - \text{Credits Spent}\]

If the CPU utilization of your instance stays below its baseline threshold, \(\text{Credits Earned} > \text{Credits Spent}\), and your accrued balance grows up to a maximum cap defined by the instance type. Conversely, when traffic spikes or a heavy background job runs, \(\text{Credits Spent} > \text{Credits Earned}\), and the instance draws down from its accrued balance to sustain high CPU performance.

The Mechanics of Credit Exhaustion in Standard Mode

In Standard mode, an instance relies strictly on its accrued credits (and launch credits, if applicable to T2 instances) to burst above the baseline. When a sustained high-CPU workload drains the credit balance to \(0\), several distinct behaviors take effect:

Gradual Performance Reduction

Rather than dropping instantly from \(100\%\) utilization to the baseline level, Amazon EC2 lowers the instance's CPU utilization incrementally over a 15-minute interval. This gradual step-down prevents abrupt application hangs and gives monitoring alarms or auto-scaling groups a brief window to respond before the instance hits its hard baseline ceiling.

Baseline Throttling

Once the gradual step-down completes, the instance is strictly capped at its baseline performance level. Depending on the specific T-series size, this baseline ranges from \(5\%\) (on a t3.nano) to \(40\%\) (on a t3.xlarge or t3.2xlarge) per vCPU. While throttled, the instance cannot consume more credits than it earns per millisecond.

Application and OS Symptoms

Because the instance is deprived of compute cycles at the hypervisor level, applications running inside the operating system will experience degraded performance:

  • Increased CPU Steal Time: Inside a Linux environment, tools like top or vmstat will show an increase in the %st (steal time) metric, indicating that the virtual machine is ready to run tasks, but the hypervisor is withholding physical CPU resources.
  • Higher Latency: Web servers and APIs will take longer to process requests, resulting in elevated response times and potential gateway timeouts.
  • Growing Process Queues: The system load average will climb as threads wait in the run queue for available CPU cycles.
  • Failed Health Checks: If the baseline CPU is insufficient to respond to load balancer pings within the configured timeout window, the instance may be marked unhealthy and terminated or replaced by an Auto Scaling group.

Cost Predictability

One of the primary benefits of Standard mode is cost protection. When the credit balance hits \(0\), AWS will never automatically bill you for extra CPU usage. Your monthly bill remains fixed at the standard hourly instance rate, trading away compute performance to guarantee predictable pricing.

Standard Mode vs. Unlimited Mode

To understand Standard mode fully, it helps to contrast it with Unlimited mode, which is the default configuration for T3, T3a, and T4g instances:

  • Standard Mode: Caps performance at the baseline when credits reach \(0\). Never incurs surplus charges. Best suited for development environments, testing servers, or strict-budget workloads where occasional slowdowns are acceptable.
  • Unlimited Mode: Allows the instance to burst above the baseline for as long as needed, even after the accrued credit balance hits \(0\). If the average CPU utilization over a 24-hour period exceeds the baseline, the account is billed a flat additional rate per vCPU-hour for the surplus credits used.

How to Monitor CPU Credit Balances

To avoid unexpected throttling in Standard mode, you should monitor two critical Amazon CloudWatch metrics provided automatically for all burstable instances:

  1. CPUCreditUsage: Tracks the number of CPU credits spent by the instance during the specified measurement period.
  2. CPUCreditBalance: Tracks the number of earned CPU credits that the instance has accrued since it was launched or started.

Setting a CloudWatch alarm that triggers when CPUCreditBalance drops below a safe threshold (for example, \(20\%\) of the maximum credit cap) gives operations teams time to intervene before throttling occurs.

Resolving Credit Exhaustion

If an instance running in Standard mode frequently exhausts its CPU credits, you have four primary remediation options:

  1. Switch to Unlimited Mode: You can modify the credit specification of a running instance from Standard to Unlimited via the AWS Management Console or AWS CLI without stopping the instance. This immediately restores full bursting capability at the cost of potential surplus charges.
  2. Upgrade to a Larger Burstable Size: Moving from a t3.micro to a t3.small or t3.medium increases the baseline CPU percentage, the credit earning rate per hour, and the maximum credit storage cap.
  3. Migrate to Fixed-Performance Instances: If your workload requires sustained high CPU utilization above the baseline, burstable instances are often neither performance-optimal nor cost-effective. Migrating to a general-purpose M-series or compute-optimized C-series instance provides dedicated, unthrottled vCPU capacity.
  4. Optimize the Workload: Profile your application to identify inefficient code, runaway background processes, or unindexed database queries that are consuming unnecessary CPU cycles.