What Is a vCPU (and Why Isn't It a Real Core)?

Quick answer
A vCPU is a virtual processor the hypervisor schedules on a physical core, usually one hardware thread of a shared machine.
Cloud providers oversubscribe: more vCPUs are sold across customer instances than there are physical threads, on the assumption that most instances are idle most of the time.
Steal time is the percentage of time your instance wanted to run but the physical CPU was busy with someone else — the number that explains mysterious slowness.
Burstable instances give you a small baseline with credits for bursts above it, and they throttle hard once the credits run out.
Four vCPUs on a shared host are not equivalent to four cores of a laptop, let alone four dedicated cores on a server.

What a vCPU actually is

When you rent a cloud instance, you are renting a virtual machine. The hypervisor schedules its virtual processors onto the physical processor’s threads, giving each instance slices of time. A vCPU is therefore a scheduling slot, not a piece of silicon: on most providers, one vCPU corresponds to one hardware thread of a physical core, and that thread is shared with other customers’ virtual machines.

This is a deliberate and reasonable design. Most instances on a provider’s fleet are idle a large fraction of the time, so packing many vCPUs onto each core makes the platform affordable. It means, though, that the performance you get depends on what your neighbours are doing, and that two instances with identical specifications can differ substantially. Instance families exist precisely to describe how much contention you are buying: ‘general purpose’ means shared, ‘compute optimised’ means more CPU per unit of memory, and ‘dedicated’ or ‘bare metal’ means the physical core is yours.

Oversubscription and steal time

Oversubscription is the practice of selling more vCPU capacity than physically exists on the host. A machine with 32 threads might host instances whose vCPUs add up to a hundred. As long as demand stays below the physical capacity at any instant, everything runs at full speed; when demand exceeds it, the hypervisor schedules fairly and every instance gets less. Your instance still reports its full vCPU count, so nothing in the specification tells you that it is waiting.

Steal time is how the operating system reports the wait. It appears in the output of top and vmstat as st, and it is the percentage of time your virtual processors were runnable but the physical CPU was busy serving someone else. Zero is normal on a quiet host, a few percent is unremarkable, and a sustained double-digit figure means you are sharing with busy neighbours and cannot fix it by optimising your own code. On a machine where the workload is latency-sensitive, a sustained steal time above a few percent is a reason to change instance type or provider rather than to tune anything.

# Steal time as a percentage, sampled every second
vmstat 1 | awk 'NR>2 {print $1, "st="$17"%"}'

# The same figure from top: the 'st' column in the CPU line
# High st with low own-usage means the host is oversubscribed, not your code

Burstable instances and CPU credits

Some instance types are explicitly designed around the idle assumption. A burstable instance has a small baseline — say 10% or 20% of a core on average — and accumulates CPU credits when it uses less than its baseline. When it needs to work harder it spends those credits to run at full speed, and when the credits run out it is throttled back to the baseline, hard and without warning.

This is a good fit for a small website, a development machine, or a service that is mostly idle with occasional spikes. It is a poor fit for anything steady, because the baseline is exactly what the name says: a sustained workload on a burstable instance performs as though the machine had a fraction of a core. If your instance seems fast during tests and slow under real traffic, check whether it is burstable and whether it has exhausted its credits. The distinction between burstable and fixed-capacity instance types is one of the highest-value things to understand when comparing prices.

Sizing without being fooled

Start from the shape of the work. If your application is single-threaded — which most web frameworks are for any individual request — adding vCPUs beyond two or three buys very little, and a faster core would help more if the provider sold one. If the work is genuinely parallel, more vCPUs translate into more throughput until something else saturates. And if the workload is I/O-bound, which most application code is, the CPU count is nearly irrelevant and the memory and storage matter far more.

Then measure, because specifications do not describe contention. Track steal time, CPU utilisation, and memory, and compare them against what the machine delivers at a busy hour rather than at 3 a.m. Two practical habits follow. First, prefer more small instances to one large one when the workload allows it, because it isolates noisy neighbours and gives you a failover story. Second, if you do need predictable single-core speed, that is what dedicated-CPU or bare-metal instance types exist for, and the premium over shared instances is usually smaller than the cost of chasing phantom performance problems.

Where this bites vibecoders
AI assistants reason about compute as if a vCPU were a fixed quantity of performance. A generated recommendation to ‘use a multi-process worker configuration for better throughput’ is good advice on a dedicated 8-core machine and actively harmful on a burstable 2-vCPU instance where each extra worker competes for the same shared thread and fights over memory. The assistant cannot see your host’s contention, and it will never mention that the machine is out of CPU credits. Checking steal time and the instance’s billing model before accepting a concurrency recommendation is a two-minute habit that prevents a class of performance mystery.

Where AI coding assistants get this wrong

Treating a vCPU as a dedicated physical core with predictable speed.
Setting worker or thread counts far above the vCPU count and causing contention.
Choosing a burstable instance for a steady workload and being throttled later.
Diagnosing performance from application code when the host is oversubscribed.
Comparing instance prices without comparing the CPU model, baseline, or contention.
Assuming benchmarks run on your quiet instance reflect performance at peak hours.

Checklist

Check whether the instance is burstable or fixed-capacity before deploying.
Monitor steal time and alarm on sustained high values.
Set worker counts relative to actual vCPUs, not to an assumed core count.
Measure at your busiest hour, not during a low-traffic test.
Confirm the instance family matches whether you need cores, memory, or storage performance.
Consider several small instances over one large one for isolation and failover.

FAQ

Is one vCPU equal to one core?

Rarely. On most providers a vCPU is one hardware thread of a physical core, and that thread is shared with other customers’ virtual machines through the hypervisor. Two vCPUs are usually one physical core’s two threads, and their performance depends on how busy the host is.

What is CPU steal time?

The percentage of time your virtual processors were ready to run but the physical CPU was busy with another customer’s work. It appears as st in top and vmstat. A few percent is normal; a sustained double-digit figure means the host is oversubscribed and your own optimisation will not help.

Why did my instance get slow after a few hours?

If it is a burstable instance, it probably used up its CPU credits and has been throttled to its baseline. Credits accumulate while the instance is quiet and are spent while it is busy, so a workload that runs flat out will always end up at the baseline. Move to a fixed-capacity instance type for steady work.