Burstable vCPU: How It Works, What It Costs You, and When to Walk Away

What Is a Burstable vCPU?

A burstable vCPU (virtual CPU) is a type of compute allocation used by many VPS and cloud hosting providers in which your server is guaranteed a baseline level of CPU processing power, but can temporarily “burst” above that baseline when additional CPU cores are idle on the physical host machine.

The term appears under various names across different platforms: AWS calls them T-series instances with CPU credits; Google Cloud uses shared-core machine types; budget VPS providers simply describe them as shared vCPU plans. The underlying mechanic is the same regardless of the label — your VPS does not own its CPU cores. It borrows them.

To understand why this matters, you need to understand how a hypervisor allocates compute resources. A hypervisor — the software layer such as KVM, Xen, or VMware ESXi — sits between the physical hardware and the virtual machines running on top of it. When a provider sells burstable burstable vCPU plans, the hypervisor deliberately oversubscribes the physical CPU cores, betting that not all tenants will demand full CPU simultaneously.

How Burstable vCPU Works Under the Hood

Burstable CPU allocation operates differently depending on the virtualization technology your provider uses. The two main approaches are the credit model and the time-sharing model.

The Credit Model (AWS T-Series, Azure B-Series)

AWS and Azure implement burstable CPU through an explicit credit system. Your instance earns CPU credits at a fixed rate while running below its baseline CPU utilization threshold, and spends credits when bursting above it. When your credit balance reaches zero, CPU performance is throttled to the baseline — regardless of what the physical host can spare.

For example, an AWS T3.small instance earns 24 credits per hour at its 20% baseline. A one-hour CPU spike above 20% burns through credits at a rate proportional to the overage. Once depleted, performance is hard-capped at 20% of a vCPU. AWS offers “unlimited” mode to bypass throttling — but at an additional per-vCPU-hour charge that can make burst instances significantly more expensive than initially advertised.

The Time-Sharing Model (Budget VPS Providers)

Most budget VPS providers using KVM or legacy OpenVZ operate a simpler time-sharing model. The hypervisor scheduler divides physical CPU time among all virtual machines on the host. When the host is lightly loaded, your VPS can consume more CPU time than its nominal allocation — that’s the “burst.” When the host is fully loaded, the scheduler enforces fairness and your VPS is confined to its proportional share.

Unlike the credit model, there is no formal accounting mechanism here — no credits, no explicit threshold. Performance varies with physical host load, time of day, and the behaviour of co-located tenants. This unpredictability is the fundamental weakness of burstable shared vCPU plans.

The OpenVZ containerization platform, which shares the host’s OS kernel across all containers rather than running separate kernels per container, was historically associated with the most aggressive CPU oversubscription. Because OpenVZ uses the host OS kernel directly, the overhead is lower, and providers can pack more tenants per physical host — meaning individual tenants experience more contention during peak periods.

Burstable vCPU vs Dedicated vCPU: Full Comparison

The choice between a burstable vCPU plan and a dedicated vCPU plan is essentially the choice between variable-cost efficiency and consistent-performance reliability. Neither is categorically superior — the right choice depends entirely on your workload profile.

An important nuance: RAM is almost always dedicated even on burstable vCPU plans. When a provider sells you 4 GB RAM, that memory is reserved — it does not fluctuate based on host load the way burstable CPU does. The unpredictability of burstable plans is confined entirely to the CPU dimension. Storage on burstable plans may also use shared SATA SSD arrays rather than the dedicated NVMe drives found on premium plans, which can further contribute to performance variance at the I/O layer.

When Burstable vCPU Works — and When It Doesn’t

Who Should Actually Use a Burstable vCPU Plan?

The honest answer is that burstable vCPU plans are designed for workloads with low average CPU demand and occasional short spikes. If your application spends most of its time idle or lightly loaded — and only needs significant CPU briefly and infrequently — you will extract excellent value from a burstable plan and never notice the throttling.

The Noisy Neighbour Problem

The noisy neighbour problem is the single most significant risk of burstable vCPU plans. Because multiple VPS instances share the same pool of physical CPU cores, a single tenant running a CPU-intensive workload — whether a legitimate video encoding job or, more commonly, cryptocurrency mining malware — consumes physical threads that would otherwise be available to you for bursting.

The hypervisor enforces minimum guarantees: your VPS will always receive its contracted baseline CPU share. But burst headroom is first-come, first-served among idle physical capacity. If your neighbour claims it before you, you are throttled to your baseline.

On dedicated vCPU plans, the hypervisor — whether KVM, Xen, or VMware ESXi — uses CPU pinning to bind specific physical threads to your virtual machine. Those threads cannot be allocated to other tenants regardless of how lightly you use them. Noisy neighbours are architecturally eliminated.

How Providers Market Burstable vCPU

Providers rarely use the word “burstable” prominently in their marketing — because it implies limitations. Instead, look for these phrases that signal a burstable or shared vCPU architecture:

• “Shared CPU” or “Shared vCPU” — the explicit term used by DigitalOcean and Linode for their lower-tier plans, as distinct from “Dedicated CPU” plans.
• “Up to X GHz” or “up to X% of a core” — the “up to” qualifier is the tell. Dedicated resources are always stated as absolutes.
• Suspiciously low prices for high vCPU counts — a plan advertising “8 vCPUs” for $5/month is almost certainly burstable. True physical CPU thread reservation at that price is economically impossible.
• OpenVZ virtualization — any OpenVZ-based plan is by definition running on a shared OS kernel, and CPU oversubscription is endemic to the platform.
• T-series, B-series, f1-micro, e2-micro nomenclature — AWS T-series, Azure B-series, and Google Cloud’s small instance types are explicitly burstable by architecture.

Real-World Performance: What to Expect

Benchmarks of burstable vCPU instances show a consistent pattern: short-burst performance is often impressive; sustained performance under load is not. A burstable instance can outperform a dedicated instance on a 10-second sysbench CPU test run at 3 AM on an unloaded host. The same instance will underperform significantly on a 10-minute benchmark run during business hours.

For web applications, this translates to a predictable pattern. Cache-hit requests involve minimal CPU — burstable serves them fine regardless of throttling. A cached WordPress page served by Nginx uses almost no CPU. Cache-miss requests are a different story: PHP execution plus database queries plus template rendering is CPU-intensive, and burstable plans show 2–5× slower response times under throttling compared to dedicated equivalents.

The one performance dimension where burstable plans match or exceed dedicated is memory bandwidth, since RAM is dedicated regardless of CPU plan type. For memory-bound workloads — such as Redis caching, in-memory databases, and large dataset processing — the CPU plan type matters less than RAM capacity and speed.

When to Upgrade from Burstable to Dedicated

The signal to upgrade is straightforward: when your application’s average CPU utilization — not its peak — approaches or exceeds the burstable plan’s baseline allocation for sustained periods. If your VPS regularly runs at 80% CPU for hours at a time, you are in burst territory continuously, which means you are either being throttled or consuming credits faster than you accumulate them.

The practical monitoring tool is steal time. On Linux, run top or htop and observe %st in the CPU statistics. Steal time is the percentage of CPU time your VPS wants but the hypervisor refuses to give it because other tenants are consuming the physical CPU cores. Any steal time above 5% on a sustained basis indicates CPU contention. Steal time above 20% is a serious performance problem and a clear signal to upgrade to a dedicated vCPU plan or move providers entirely.

Frequently Asked Questions