Right-Sizing a Burstable Instance for a Spiky Reporting Job
A team runs a nightly reporting job on a single burstable compute instance (2 vCPU, 4 GiB) in a public cloud. The job runs from 01:00 to 01:40 and pushes CPU to 100% of the baseline for the entire window; the rest of the day the instance sits near 5% CPU. After three weeks, users report that the 01:00 job now takes 95 minutes and occasionally times out at the 120-minute guardrail. Cloud monitoring shows sustained CPU credit depletion by 01:20 each night, with credits refilling during the idle daytime. The team's budget allows either a larger fixed instance or a switch to an on-demand non-burstable type, but not both. They also want to keep the daytime cost low.
1. Diagnose why the job slowed down and explain the credit mechanism at work. Then recommend the most cost-effective change given the constraint that they cannot both upsize and switch to non-burstable.
Read the worked answer
The slowdown is caused by CPU credit exhaustion, not by a code regression. A burstable instance earns credits at a baseline rate while idle and spends them when CPU exceeds baseline. During the 40-minute job, the instance burns credits faster than it earns them; by roughly 01:20 the balance hits zero and the instance is throttled back to baseline performance. Because the daytime is nearly idle, credits refill, which is why the job starts fast and then crawls.
The judgement call is between two levers:
- Upsize the burstable instance. A larger burstable size has a higher baseline and a larger credit bucket, so the same 40-minute burst may fit inside the earned credits. This keeps the cheap idle behavior and is usually the lowest-cost fix when the burst is short.
- Switch to a non-burstable (fixed-performance) type. This removes throttling entirely but raises the hourly cost for all 24 hours, including the 23 hours of near-idle time.
Given the budget constraint, the better choice is to upsize the burstable instance only if the new baseline times the job duration plus the bucket size covers the burst; otherwise the fixed type is the only reliable option. The team should verify with the credit math before committing, and consider scheduling the job off-peak isn't relevant here because the issue is the burst itself, not contention.
2. The team proposes splitting the 40-minute job into four 10-minute chunks spread across the night to 'stay under the credit limit.' Evaluate this proposal.
Read the worked answer
Splitting the work does not reduce total CPU-credit consumption. Credits are spent per unit of CPU time above baseline; four 10-minute bursts consume the same credits as one 40-minute burst. What changes is the timing of depletion: spreading the chunks gives the instance time to refill credits between chunks, so each chunk may run at full speed without hitting zero. This can work, but only if the refill rate between chunks outpaces the spend within each chunk.
The catch is that the job's total wall-clock time grows and the design becomes fragile: any chunk that runs long or overlaps with daytime traffic risks depletion again. A cleaner engineering answer is to reduce the CPU work itself (e.g., caching, parallelism limits, or moving to a batch service), or to accept the instance-type change. The chunking idea is a valid stopgap only if the team measures credit balance between chunks and confirms it stays positive; otherwise it just moves the timeout later.