Shared vs Dedicated vCPU: What You Are Actually Buying

The three models

Shared plans are not oversold in a dishonest sense. They rely on the accurate observation that most servers idle most of the time, so capacity can be pooled. The plan works until several tenants are busy simultaneously.

Burstable plans and the credit trap

Credit-based instances — AWS T-family, and similar plans elsewhere — give a baseline such as 20 per cent of a core, and accumulate credits while below it. Bursting above the baseline spends credits.

The trap is what happens when credits run out. The instance is throttled to the baseline, which can be a fraction of the performance you were seeing. Everything slows down at once, and the CPU graph looks fine because it is pinned exactly at the baseline.

Burstable plans suit workloads that are genuinely idle most of the time. They are a poor fit for anything with sustained load, and a very poor fit for a database.

Steal time: the number to watch

Steal time is the percentage of time your virtual CPU was ready to run but the hypervisor gave the physical core to someone else. Read it with top, vmstat or sar — the st column.

• 0 to 1 per cent — normal, nothing to do.
• 2 to 5 per cent — noticeable on latency-sensitive work.
• Above 10 per cent — you are losing significant capacity to neighbours.

Persistent high steal time is the concrete evidence that a dedicated plan would help. Without it, you are speculating about a noisy neighbour who may not exist.

What needs dedicated cores

• Databases under sustained load — latency variance shows up directly in query times.
• CI and build runners — sustained 100 per cent CPU is exactly what shared plans throttle.
• Video encoding and batch processing — long CPU-bound jobs.
• Realtime services — game servers, trading, anything where p99 latency matters more than the average.
• Benchmarking — shared cores make results meaningless.

And what does not: static sites, low-traffic web applications, development environments, staging, cron jobs, and most CMS installations. These spend most of their time waiting, and shared cores are exactly the right purchase.

How the providers name it

Names differ; the underlying distinction is the same everywhere. Read the plan description for the words “shared”, “burstable” or “baseline” — those signal the first two models.

A decision that takes five minutes

1. Start on a shared plan. It is cheaper and usually sufficient.
2. Watch steal time and response-time percentiles for two weeks.
3. If steal time stays low and p99 latency is stable, stay where you are.
4. If either degrades at predictable times of day, move that workload to dedicated.
5. Keep databases and CI on dedicated from the start; the evidence is already in.

Common questions

Where to go next

See how to size a cloud server and Hetzner versus DigitalOcean, where this distinction drives most of the price gap.