Context
An EC2 application slows down every afternoon even though the instance has the same number of vCPUs it had in the morning. Another application stays responsive but develops an unexpected CPU surplus charge. Both incidents can involve burstable instances, but the corrective decisions differ. Investigate the instance's credit mode, accumulated demand, and business latency together before resizing it.
Understand what the vCPU count promises
Burstable instances earn CPU credits at a rate associated with their size. A credit represents one vCPU running at full utilization for one minute. The advertised vCPU count describes available execution capacity; it does not mean the instance can sustain that capacity indefinitely within its baseline price.
In Standard mode, an exhausted balance constrains sustained work toward the baseline. Unlimited mode can use surplus credits to continue above the baseline, with additional charges possible under AWS's accounting rules. Confirm the actual configuration rather than inferring it from an instance family name or an old launch template.
Collect one synchronized incident interval
Record the instance ID, type, credit specification, launch time, and any recent resize. Graph application latency, throughput, queue depth, CPUUtilization, CPUCreditUsage, and CPUCreditBalance over the same interval. For Unlimited mode, include CPUSurplusCreditBalance and CPUSurplusCreditsCharged.
Use the metric's documented period and statistic. A five-minute credit metric and a one-minute request graph will not align perfectly if displayed without explanation. Inspect several working days because an overnight credit recovery can hide a recurring afternoon shortage. Record batch jobs and security scans alongside customer traffic.
An illustrative afternoon slowdown
A small reporting service is idle overnight, handles interactive requests during the day, and rebuilds summaries after lunch. Its morning balance makes a short benchmark look healthy. Once the rebuild consumes the reserve, interactive latency rises and the worker queue grows.
The useful experiment separates interactive demand from the rebuild. Run the same job on a representative test instance, measure sustained behavior beyond the initial burst, and compare completed reports per minute. A larger pool of application threads may increase competition without creating additional CPU entitlement.
Compare three corrective choices
First, remove unnecessary work. Cache reusable results, reduce repeated parsing, and investigate a query that consumes CPU without improving output. Confirm optimization using a fixed input set and correct results.
Second, move deferrable processing into a worker with its own capacity and deadline. This isolates interactive requests, but the worker still needs a sustainable CPU budget. A delayed queue is an explicit product tradeoff, so measure completion against the business cutoff.
Third, compare a larger burstable size with a fixed-performance instance. Include observed surplus charges, memory needs, architecture compatibility, and peak latency. Use current regional pricing for the actual purchase decision. A low hourly headline price does not establish the cheapest cost per successfully completed task.
Quick diagnostic map
| Evidence | Likely boundary | Next check |
|---|---|---|
| Balance reaches zero as latency rises | Standard-mode baseline | Confirm mode and sustained workload |
| Service remains fast; surplus charges appear | Unlimited accounting | Compare longer-term CPU demand |
| One thread is busy; instance average looks modest | Application parallelism | Profile the busy request path |
| Credit reserve recovers only overnight | Daily capacity mismatch | Measure the entire workday |
A focused operator exercise
Use an isolated workload with a repeatable reporting dataset. Record the current credit configuration, starting balance, input size, and application version. Run a steady request stream alongside the reporting job long enough to observe sustained behavior rather than just startup performance.
Compare one optimization or instance change at a time. Keep output checks identical, capture queue recovery time, and inspect the account's relevant usage categories after metering becomes available. Document whether the improvement came from lower work per request, more baseline capacity, or paid bursting. Stop the test at the agreed spend and latency boundaries.
Turn the finding into an operating policy
Alert on a combination that supports action: low credit headroom with persistent above-baseline demand, or surplus usage that exceeds an agreed cost expectation. Assign an owner who can relate the signal to workload schedules. An alert on every ordinary balance decrease will mostly report that the instance is working.
Keep credit mode in the reviewed provisioning configuration. Otherwise a replacement instance can behave differently from the server used during diagnosis. Recheck the decision after traffic, software, or scheduled work changes.
Frequently asked questions
Does Unlimited mean the CPU is free to use indefinitely?
No. It changes how above-baseline demand is served and accounted for. Check surplus metrics and current pricing, then compare the measured workload with alternatives.
Should every production server avoid burstable instances?
No. Intermittent workloads can fit well. The important test is whether sustained demand, latency requirements, and the cost model fit the service.
Continue the investigation
- CloudWatch agent metrics: prove memory and disk collection end to end
- Investigate performance from the first response.
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Cloud Cost Optimization to discuss implementation, validation and operational handover.