Dedicated vCPU vs Shared vCPU: The Three Ways You Get Throttled
Almost every explanation of shared versus dedicated vCPU stops at “you share cores with other customers, so performance varies.” That’s true and it’s not useful, because it doesn’t tell you what shape the slowdown takes or how to prove which one you’re hitting.
There are three distinct mechanisms that make a shared vCPU slower than a dedicated one. They produce different symptoms, they’re diagnosed with different commands, and only one of them is the noisy-neighbour effect everyone talks about.
If you already know you need dedicated cores and just want to know who sells them, our dedicated CPU VPS comparison covers the market and the price premium. This article is about what’s actually happening underneath.
Mechanism 1: CFS hard quota
This is the Linux kernel’s own bandwidth control, and it’s the most common mechanism in containers and many VPS platforms.
The scheduler works in periods — typically 100 milliseconds. Your instance is granted a quota of CPU time per period, expressed in microseconds. Half a core means a quota of 50,000µs against a 100,000µs period: you may use 50ms of CPU time in every 100ms window.
When you exhaust that budget, the kernel parks your processes until the next period begins. The kernel’s own documentation is unambiguous about it:
“Within each given ‘period’ (microseconds), a task group is allocated up to ‘quota’ microseconds of CPU time. […] Once all quota has been assigned any additional requests for quota will result in those threads being throttled. Throttled threads will not be able to run again until the next period when the quota is replenished.”
That’s abrupt rather than gradual — your threads don’t slow down, they stop until the clock rolls over.
Here is the part that surprises people, and it explains a lot of mysterious latency:
A CPU limit enforces a peak budget, not an average. A workload that bursts above the limit in any single 100ms window gets throttled in that window — even if its average utilisation over the minute is nowhere near the limit.
So an application that’s “using 20% CPU” on a graph can still be getting throttled several times a second, because the graph is an average and the quota is enforced per period. Request latency spikes; average CPU looks fine; nothing in your monitoring explains it.
How to prove it. Throttling is counted by the kernel, so you can read it directly:
cat /sys/fs/cgroup/cpu.stat
Look for nr_throttled (how many periods were throttled) and throttled_usec (total time parked). On cgroup v1 the file is cpu.cfs_throttled_time. If nr_throttled is climbing while your service feels slow, you have found your answer — and note that steal time will be zero, because nobody stole anything. You hit a ceiling you were sold.
Mechanism 2: Burstable CPU credits
The credit model is what AWS’s T-series popularised, and it produces the specific behaviour that makes long jobs mysterious: full speed for a while, then a step down.
Your instance has a baseline performance level and earns credits continuously at a fixed rate. Running below baseline banks credits; running above baseline spends them. While you have a balance, you get full performance. When the balance hits zero, behaviour depends on the mode:
- Standard mode — you’re throttled down to the baseline, which can be a small fraction of a full core.
- Unlimited mode — you keep bursting on surplus credits and pay them back later when utilisation drops below baseline. T3 and T3a instances default to Unlimited.
AWS’s documentation is worth reading closely on how the surplus is settled, because the accounting period is longer than people assume: the platform averages your CPU utilisation over a rolling 24-hour period, and “if the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a flat additional rate per vCPU-hour.” Their worked example is a t3.large with a 30% baseline — run it at 40% average across the day and you’re billed for the extra 10%. (That flat rate is widely reported at around $0.05/vCPU-hour, though the figure isn’t on this page.)
The 24-hour averaging is the merciful part — a short spike is absorbed by a quiet afternoon. Sustained load is not.
This is why a video encode or a long-running agent loop can take three times longer than a benchmark predicted. The first ten to forty minutes run at full speed on banked credits. Then the balance empties and you fall to baseline for the remainder. Nothing failed; the machine did exactly what it was sold to do.
How to prove it. Credits aren’t visible from inside the instance — check the provider’s metrics (on AWS, CPUCreditBalance and CPUSurplusCreditBalance). A balance trending to zero at the moment your job slowed is conclusive.
The billing trap in Unlimited mode: you don’t get slow, you get charged. A sustained workload on a burstable instance in Unlimited mode can quietly cost more than the dedicated instance you were avoiding.
Mechanism 3: Oversubscription — the actual noisy neighbour
This is the one everyone means by “shared,” and it’s the only one that produces steal time.
The host has more vCPUs allocated across its guests than it has physical cores, on the reasonable assumption that not everyone runs hot simultaneously. When that assumption breaks, the hypervisor has to choose, and your VM waits for a physical core while it’s ready to run.
That waiting is steal time, and unlike the first two mechanisms it isn’t a documented limit — there’s no published quota, no credit balance, and usually no acknowledgement it happened.
How to prove it:
vmstat 1 10 # the st column
mpstat -P ALL 1 5 # %steal per core
| Steal time | Reading |
|---|---|
| 0–2% | Normal. Not your problem. |
| 2–5% | Mild contention, generally tolerable. |
| 5–10% | Real contention worth investigating. |
| Above 10% | You’re materially losing CPU you paid for. |
And the arithmetic that makes it concrete: 8 vCores at 50% steal time deliver 4 effective cores. A high core count on a contended host is a number on an invoice.
The diagnostic table
This is the practical payoff — three failures that feel identical and are distinguished in about a minute:
| Symptom | Steal time | nr_throttled |
Provider credit metric | Mechanism |
|---|---|---|---|---|
| Latency spikes, average CPU looks low | 0 | Rising | — | CFS quota |
| Fast at first, then persistently slower | 0 | flat | Balance → 0 | CPU credits |
| Variable speed, worse at peak hours | >5% | flat | — | Oversubscription |
| Slow but all three clean | 0 | flat | fine | Not CPU — check disk and memory |
That last row matters more than the other three combined. Plenty of “CPU problems” are actually disk I/O or swapping, and buying dedicated cores fixes neither. Check iostat -x 1 5 for disk utilisation and free -h for memory pressure before you conclude anything.
What dedicated vCPU actually guarantees
A dedicated vCPU is pinned to a physical core that isn’t shared with another tenant. In practice that removes mechanisms 1 and 3 — no quota ceiling, no steal time — and mechanism 2 doesn’t apply because there’s no credit system.
What it does not do is make a core faster. A dedicated core at 2.5GHz is the same silicon as a shared core at 2.5GHz; you’re buying consistency, not speed. If your workload is fast enough when it runs and merely inconsistent, dedicated fixes it. If it’s too slow at full speed, dedicated changes nothing and you need more cores or better ones.
Which is why the honest question isn’t “shared or dedicated” but “is my duty cycle high enough that a ceiling matters?” Bursty work — a web app with traffic peaks, a CI runner, a development box — is exactly what shared plans are designed for and they handle it well. Continuous load is where the mechanisms above start firing.
Who uses which model
Broadly, and worth verifying against current documentation before you buy:
- Traditional VPS hosts — Hetzner, DigitalOcean, Vultr, Linode and similar — allocate resources per plan rather than running credit systems. Their shared tiers are subject to oversubscription and, on some platforms, quota; their dedicated tiers remove both.
- Hyperscaler burstable families — AWS T-series most prominently — use the credit model with Standard and Unlimited modes.
- Container platforms and managed PaaS — anything running your workload in a cgroup — use CFS quota, which is why Kubernetes CPU limits are such a common source of unexplained latency.
Naming remains the trap covered in our dedicated CPU guide: Hetzner’s CPX line is shared despite costing several times its CX line, only CCX is dedicated, and Vultr’s High Frequency is a faster clock rather than an isolated one. The word to look for is “dedicated,” and nothing else counts.
What to do about it
If you’re hitting CFS quota: raise the limit if you control it, or move to a plan without one. In Kubernetes specifically, consider removing the CPU limit while keeping the request — the limit is what throttles.
If you’re exhausting credits: either size the instance so your steady-state load sits below baseline, or move to a non-burstable plan. If you’re in Unlimited mode, check the surplus charges before assuming you’re saving money.
If you’re losing time to steal: the only real fixes are moving to dedicated cores or moving to a quieter host. Nothing you configure inside the VM reclaims stolen time. If you’d rather not diagnose this again, Liquid Web sells single-tenant hardware with a support organisation attached — expensive per gigabyte, but the contention question stops being yours. Our dedicated CPU comparison covers the cheaper routes.
If all three are clean: it isn’t CPU. Our NVMe VPS guide covers the disk side, including why providers cap IOPS well below what the drive can do, and the 8GB tier guide covers memory pressure.
How we picked the explanations
The mechanics here come from Linux kernel CFS bandwidth-control documentation, AWS’s burstable-instance documentation, and provider plan documentation, read in August 2026.
We have not run sustained load tests across providers to chart throttling curves. That’s the measurement people most want, and it’s also the least transferable: results depend on which physical host you land on, what your neighbours are doing that hour, and which plan generation you were assigned. A number we measured last month wouldn’t predict yours. The diagnostics above run on your own instance in under a minute and tell you something true about the machine you’re actually paying for.
FAQ
What’s the difference between dedicated and shared vCPU?
A dedicated vCPU is bound to a physical core no other tenant uses, so you get consistent performance with no quota ceiling and no steal time. A shared vCPU may be subject to a hard quota, a credit balance, or contention with neighbours. Dedicated buys consistency rather than raw speed — the core itself is no faster.
Why is my shared VPS fast at first and then slow?
That’s the signature of the credit model. You start with banked credits and run at full speed; when the balance empties you drop to baseline. Check your provider’s credit metric — on AWS that’s CPUCreditBalance — and see whether it hit zero when the slowdown began.
My CPU usage is low but my app is slow. Why?
Most likely CFS quota throttling. Limits are enforced per 100ms period, not on average, so a workload averaging 20% can still exceed the limit in individual windows and get parked. Check nr_throttled in /sys/fs/cgroup/cpu.stat — if it’s climbing, that’s your cause, and steal time will read zero.
Does high steal time mean I need a dedicated CPU?
If it’s consistently above 5–10% during the hours that matter, yes — nothing inside the VM reclaims stolen cycles. Below 2%, contention isn’t your problem and dedicated cores would be a 2–5× price increase for no measurable gain.
Are shared vCPUs bad?
No — they’re correctly matched to bursty workloads, which is most workloads. A web app, a bot, a staging environment or a development box all spend most of their time near idle, and paying for dedicated cores to sit unused is waste. The model breaks down when load becomes continuous.
How do I know which throttling model my provider uses?
Check the plan documentation for the words “burstable,” “credits” or “baseline performance” — that’s the credit model. Traditional VPS plans that state fixed vCPU counts without a baseline are usually quota or oversubscription based. If the documentation says nothing, run the three diagnostics above under load and let the machine tell you.
