Why Enable Unlimited Mode on AWS EC2 T3 and T4g Instances?

This article explains why developers enable Unlimited mode on Amazon EC2 T3 and T4g burstable instances, detailing how the CPU credit mechanism works, the performance benefits of sustaining high CPU utilization during traffic spikes, and the cost considerations involved when exceeding baseline thresholds.

Understanding Burstable Performance Instances

Amazon EC2 T3 and T4g instances are burstable performance instances designed to provide a baseline level of CPU performance with the ability to burst above that baseline when workloads demand extra processing power. Under the hood, this capability is governed by CPU credits.

When an instance operates below its designated baseline CPU utilization (for example, \(20\%\) on a t3.small or t4g.small), it continuously earns CPU credits. When the workload requires more processing power than the baseline—such as during application startup, code compilation, or sudden web traffic spikes—the instance consumes these accumulated credits to burst up to \(100\%\) of its vCPU capacity. One CPU credit is equal to one vCPU running at \(100\%\) utilization for one minute, which can be expressed mathematically as:

\[\text{CPU Credits} = \text{Number of vCPUs} \times \text{Utilization} \times \text{Time in Minutes}\]

Standard Mode vs. Unlimited Mode

To understand why Unlimited mode is useful, it helps to contrast it with Standard mode:

  • Standard Mode: When a burstable instance runs out of accrued CPU credits during a sustained workload, its CPU performance is throttled back down to the baseline level. If the baseline is \(10\%\) or \(20\%\), the application can suddenly become sluggish, unresponsive, or fail health checks until demand drops and credits are replenished.
  • Unlimited Mode: When Unlimited mode is enabled (which is the default setting for T3 and T4g instances), the instance is never throttled down to its baseline when its accrued credit balance reaches zero. Instead, it is allowed to burst at high CPU utilization for as long as needed to handle the workload.

Key Reasons to Enable Unlimited Mode

Developers choose to keep or enable Unlimited mode on T3 and T4g instances for several practical reasons:

1. Preventing Performance Degradation During Traffic Spikes

Production web servers, APIs, and microservices often experience unpredictable traffic surges. In Standard mode, a prolonged traffic spike can exhaust the CPU credit balance, causing severe latency or timeouts once throttling kicks in. Unlimited mode guarantees that the instance maintains full vCPU performance throughout the entire spike, protecting the user experience and meeting service-level agreements (SLAs).

2. Handling Periodic Intensive Workloads

Many workloads sit mostly idle but occasionally run heavy batch jobs, automated backups, security scans, CI/CD builds, or cron tasks. If a batch job takes longer than anticipated and consumes all accrued credits, Unlimited mode ensures the job finishes at full speed rather than stalling out at baseline CPU performance for hours.

3. Borrowing Future Credits Without Immediate Charges

When an instance in Unlimited mode exhausts its accrued credits, it does not immediately incur extra charges. Instead, EC2 allows the instance to borrow "surplus credits" against future credit earnings. If the workload drops back below the baseline later in the 24-hour rolling window, the instance earns credits that pay down the surplus balance. As long as the average CPU utilization over a 24-hour period stays at or below the baseline, the developer pays $0 in additional burst charges.

4. Right-Sizing Instances for Cost Efficiency

Without Unlimited mode, developers worried about occasional CPU throttling often over-provision their infrastructure by choosing larger burstable instances or migrating to fixed-performance instance families (like M6i or M7g). Those fixed-performance instances cost significantly more per hour even when sitting idle. Unlimited mode lets teams run cost-effective T3 or T4g instances for variable workloads while retaining a safety net of on-demand compute power when required.

Cost Considerations and When to Avoid Unlimited Mode

While Unlimited mode prevents throttling, developers must monitor how often their instances consume surplus credits. If an instance's average CPU utilization remains above the baseline over a 24-hour period (or when the instance is terminated), AWS bills for the net surplus credits consumed at a flat rate per vCPU-hour.

If a T3 or T4g instance runs at or near \(100\%\) CPU utilization continuously in Unlimited mode, the accumulated surplus credit charges can make the instance more expensive than a comparably sized fixed-performance instance (such as an M-family or C-family instance). Developers should therefore avoid Unlimited mode—or migrate to a non-burstable instance family—in the following scenarios:

  • Consistently High CPU Workloads: Applications like video encoding, continuous data streaming, or high-throughput compute engines that constantly require high vCPU usage are more economical on M, C, or R instance families.
  • Strict Budget Caps in Development Environments: In non-production or sandbox environments where runaway loops, buggy code, or misconfigured processes could accidentally peg the CPU at \(100\%\) for days, switching to Standard mode acts as a hard cost control to prevent unexpected surplus credit charges.