A logistics API runs a steady CPU load on a burstable instance, and the CPU credit balance is exhausted. Unlimited mode was proposed so this same size can stay the permanent home. The team does not want the steady load to depend on CPU credits. What should the load move to?
Select an answer to reveal the explanation.
Short Explanation
You’ve spotted the key issue: your steady load has exhausted its CPU credits, so unlimited mode would keep the same size running at extra cost rather than provide a sustained CPU profile. Move the API to a non-burstable size so its CPU no longer depends on credits.
Full Explanation
Burstable instances earn CPU credits below their baseline and spend them above it. Your steady load has exhausted its credit balance, so standard mode throttles the CPU. Keeping the same burstable size in unlimited mode avoids that throttle by billing for surplus credits, but it does not give your steady load a sustained CPU profile. A daily stop would earn credits only while the API is not serving traffic. A larger burstable size can raise the baseline, but it still earns and spends credits for this steady load, which the team does not want to depend on. A non-burstable size provides CPU that does not rise and fall with an accumulated credit balance, making it the fit for this permanent capacity plan. One caveat: unlimited mode can be a short bridge during a move, but it is a weak permanent design for a steady load. As a practical check, review the current instance’s CPU credit balance, move the API to a non-burstable size, and confirm the capacity plan no longer depends on credits. If unlimited mode remains on during the move, watch surplus CPU credits, then turn it off when the new size is serving.