--- title: "CPU Burst Credits: What Settles When an Instance Stops" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/ai-control-plane-cpu-surplus-credit-settlement" last-updated: "2026-10-21" --- # CPU Burst Credits: What Settles When an Instance Stops Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. Stopping an AWS burstable instance in Unlimited mode can turn outstanding CPU surplus from past usage into an additional charge, even as future instance usage ends. For a short-lived AI control or metadata worker, compare that settlement with the base running time needed to repay it. Avoiding a surplus charge alone does not establish the lower total cost. ## Identify the CPU allowance behind the worker offer An AI platform may have CPU-side workers that manage metadata or control requests separately from accelerator work. When comparing a short-lived worker with a persistent one, retain the promised useful workload and its required availability. CPU consumption alone does not establish how much application work either offer completes. AWS's unversioned EC2 documentation, checked October 21, 2026, defines one CPU credit as one vCPU-minute at full utilization. Its t3.small row lists two vCPUs, 24 credits earned per running hour, a 20% baseline per vCPU and a maximum accrued balance of 576 credits. That maximum equals 24 hours of earning. These are CPU accounting quantities, separate from the monetary cloud-credit and EBS gp2 I/O-credit ledgers explained in the related guides. The comparison below stipulates an eligible t3.small in Unlimited mode, outside a Dedicated Host. Unlimited can use surplus after accrued credits are depleted. Its CPU-cost coverage uses a rolling 24-hour period or instance lifetime, whichever is shorter; Standard has different behavior. The named instance supplies a CPU-credit example, with no GPU configuration or application suitability inferred. References: [CPUKEY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html) ## CPU-C4: account for the same first four hours CPU-C4 is a wholly fictional comparison starting with zero accrued credits and zero surplus. Both paths stipulate 100% CPU utilization across both vCPUs for four running hours. The arithmetic represents demand assumptions, with no completed AI jobs, actual utilization trace or measured performance claimed. Gross consumption is 2 vCPUs × 60 minutes/hour × 4 hours = 480 credits. The instance earns 24 × 4 = 96 credits during those same hours. The remaining deficit is therefore 480 − 96 = 384 surplus credits. Dividing by 60 converts that quantity to 6.4 vCPU-hours. The 96 earned credits already account for the baseline contribution. Subtracting another 20% from the 384 would count that allowance twice. Likewise, 6.4 vCPU-hours is the surplus quantity across the instance; it is neither 6.4 elapsed instance-hours nor a quantity to multiply by two again. The deficit grows throughout this constant-demand interval and peaks at 384. Since 384 is below the 576 credits earnable in 24 hours, this history does not cross the cap-exceedance charging trigger before the four-hour endpoint. A still-unsettled balance at that point leaves the lifecycle decision open. References: [CPUKEY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html), [CPUUNL](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html) ## Path A: stopping settles the outstanding surplus Path A ends its running interval at hour 4 with the stipulated ordinary stop. Its 384 outstanding surplus credits become chargeable under AWS's stop settlement rule. Ending future instance usage does not erase the CPU time already consumed. AWS also identifies termination and a change from Unlimited to Standard as settlement events. Separately, surplus above the maximum earnable in 24 hours is charged at the end of the hour. Consequently, the 24-hour reference is not a guaranteed free period before any charge can arise. Keep that settlement distinct from resources retained afterward. The related Stopping a GPU Instance Leaves Other Billing Clocks Running article explains continuing storage and optional-resource charges. Here, the additional CPU line concerns past use settled at the boundary; it does not imply that a stopped CPU continues executing. References: [CPUUNL](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html), [LCYCLE](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html) ## Path B: later running time repays the deficit Path B shares the same first four hours but remains running at exactly 0% CPU utilization for 20 additional hours, with no mode change or intervening stop. At 24 credits per hour and zero consumption, the first 16 later hours repay 16 × 24 = 384 surplus credits. The balance reaches zero at hour 20 of the full timeline. Only then do earned credits accumulate as an accrued balance. The final four running hours add 4 × 24 = 96 accrued credits. At hour 24, this path has no surplus remaining and incurs no surplus charge under the stated history. The full-period average CPU utilization is 4/24 = 16.666…%, below the selected 20% baseline. The running interval still totals 24 billable instance-hours. AWS bills a running instance even when it is idle. Path B therefore changes both the credit outcome and the purchased duration: it adds 20 running hours without adding useful work in this example. Zero utilization is a deliberate simplifying premise. For a real persistent worker, background work consumes credits too, so the offer needs a supported later-use assumption. Calling a period quiet does not establish the same paydown as CPU-C4's stipulated zero. References: [CPUKEY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html), [CPUUNL](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html), [CPUMET](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html), [LCYCLE](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html) ## Compare the two charge histories, not only the surplus line Let B be the applicable base rate in currency per instance-hour and R the applicable surplus rate in the same currency per vCPU-hour. Assume constant applicable rates over each path. In a deliberately partial model containing only these two charge lines, Path A costs 4B + 6.4R. Path B costs 24B. The comparison is therefore a settled 6.4 vCPU-hour deficit alongside four base hours, versus 24 base hours with no surplus charge. Reporting only Path B's zero surplus line would omit the additional 20B of running cost. Neither path can be declared cheaper without the applicable rates. For an actual offer, expand the scope to the resources, commitments, discounts and taxes that apply over the comparison period. The retained-resource guide addresses continuing storage and other allocations; the monetary-credit guide addresses which charges an applicable promotional balance can cover. Resolve those items separately before treating either expression as a bill estimate. CPU-C4 establishes two different charging histories for the same stipulated initial CPU demand. It does not establish a universal breakeven, recommend keeping a worker idle or direct a lifecycle change. The buyer's useful comparison keeps both the promised work and the complete purchased duration visible. References: [CPUUNL](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html), [LCYCLE](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html) ## Ask for the usage history behind the ending balance AWS distinguishes CPUCreditUsage, CPUCreditBalance, CPUSurplusCreditBalance and CPUSurplusCreditsCharged. These describe consumption, accrued credits, outstanding surplus and charged surplus respectively. The credit metrics use vCPU-minute units and are available at five-minute frequency; a dated metric observation is not an instantaneous monetary invoice. A zero surplus balance at the end cannot by itself tell the buyer whether earlier surplus was repaid or charged. CPU-C4 makes that ambiguity concrete: Path A settles its deficit at stop, while Path B repays it during later running time. The ending surplus quantity alone loses the distinction that matters to the comparison. Ask the appointed platform and billing owners for the starting accrued and surplus balances, CPU usage over the proposed intervals, running duration, lifecycle and credit-mode boundaries, and surplus already charged within the comparison period. Earlier usage or earlier settlements cannot be reconstructed from one balance snapshot. Match each observation to its time and interval before using it in the offer. A short-lived worker proposal should explain the surplus expected at its endpoint and how that endpoint settles it. A persistent worker proposal should explain the later workload that supports its paydown assumption and the base time it purchases. Either answer remains incomplete if it converts CPU time into a count of useful metadata operations without application evidence. References: [CPUMET](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html) ## Keep a separate physical equipment project on its own scope The cloud billing comparison belongs with the selected provider and the customer's appointed platform and billing owners. If the wider AI project separately needs customer-selected equipment mounted in a rack, Leviathan's Rack-and-Stack Installation service covers agreed physical equipment installation, IT cabling, labels and installation records. Use the related physical project inquiry with a nonconfidential equipment and rack outline, site authorization, appointed supplier responsibilities, required work window and handoff needs. That scope discussion concerns the equipment installation; it does not provide cloud administration or a cloud cost-management service. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [CPUKEY — AWS EC2: Key concepts for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html). Checked 2026-10-21. CPU-credit units, earning and consumption, the selected t3.small row and the Dedicated Host restriction establish the example's applicability. Other instance rows and default credit settings are outside this comparison. - [CPUUNL — AWS EC2: Unlimited mode concepts for burstable instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html). Checked 2026-10-21. Surplus paydown and charging at cap exceedance, stop, termination or a change to Standard support the lifecycle comparison. Provider illustrative prices and fixed-instance breakeven examples are not rate quotations for CPU-C4. - [CPUMET — AWS EC2: Monitor CPU credits for burstable instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html). Checked 2026-10-21. Metric definitions, vCPU-minute units, five-minute availability and surplus-first paydown distinguish current balances from previously charged surplus. - [LCYCLE — AWS EC2: Amazon EC2 instance state changes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html). Checked 2026-10-21. Running and ordinary-stop billing states support the example's four-hour and 24-hour instance-usage intervals. Retained EBS and other resource charges have separate scopes. - [L1 — Leviathan Systems: Rack-and-Stack Installation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-21. Agreed equipment mounting, IT cabling, labeling and physical installation records support a separately needed customer-equipment project inquiry. ## Related Leviathan resources - [Storage burst credits: evaluate EBS gp2 duration](/articles/ebs-gp2-burst-credit-duration) - [Monetary cloud credits: reconcile eligible charges and usable balance](/articles/cloud-credit-eligible-charges-usable-balance) - [Stopped compute: account for retained-resource billing](/articles/gpu-cloud-stopped-compute-retained-resource-billing) - [Rack-and-Stack Installation for a separate equipment project](/services/rack-and-stack) - [Discuss a separately needed physical installation](/contact?service=rack-and-stack&from=%2Farticles%2Fai-control-plane-cpu-surplus-credit-settlement) ## Does a separate equipment project need rack installation? Share a nonconfidential equipment and rack outline, site requirements, appointed supplier responsibilities and physical handoff needs to discuss installation scope and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/ai-control-plane-cpu-surplus-credit-settlement)