vCPU vs Core: What's the Difference?

Quick answer
A physical core is a complete execution unit on the processor; a vCPU is a virtual CPU presented to a VM by the hypervisor.
On many cloud instance families one vCPU maps to one hardware thread, which is half a physical core with hyperthreading; on others it maps to a full core.
That ambiguity is why vCPU counts are not comparable across providers or even across instance families from the same provider.
For a workload limited by single-thread performance, the clock speed and the underlying CPU generation matter more than the vCPU count.
Use vCPU as a billing and scheduling unit, and benchmark your own workload when the difference actually matters.

What is the difference between a vCPU and a core?

A core is a physical execution unit. Modern server CPUs also expose two hardware threads per core through simultaneous multithreading, so an operating system may see twice as many logical processors as there are cores. A vCPU is what the hypervisor presents to a virtual machine, and it is scheduled onto those physical threads.

The number of vCPUs tells you how much scheduling capacity the provider allocates, not how many physical cores you own. A four-vCPU machine might occupy two physical cores with both threads, four full cores, or a share of a larger host depending on the instance family and the provider’s oversubscription policy.

| Question                  | Core                              | vCPU                                  |
|---------------------------|-----------------------------------|---------------------------------------|
| What it is                | Physical execution unit           | Virtual scheduling unit               |
| Who defines it            | CPU vendor                        | Hypervisor / cloud provider           |
| Typical mapping           | 1 core = 2 threads with SMT       | 1 vCPU = 1 thread or 1 core           |
| Visible to the guest      | Via topology, if exposed          | As a logical processor                |
| Comparable across clouds  | Yes, by CPU model                 | No, by design                         |

Why is the mapping not universal?

Providers choose how to expose CPU capacity. Some sell a vCPU as a hardware thread to maximise density; others sell a full core for workloads that need predictable single-thread performance. Instance families differ within one provider: a burstable family, a compute-optimised family, and a memory-optimised family can each define a vCPU differently.

Oversubscription adds another variable. If the host sells more vCPUs than it has threads, your vCPU competes with other tenants. Providers usually document CPU credits or baseline performance for burstable families, and the practical effect shows up as steal time or latency under load.

When does the distinction actually matter?

It matters for single-threaded workloads: a database primary, a Node.js process, a game server, or a compiler. Those are limited by clock speed and cache, so two vCPUs on a fast modern core can beat four on an older, slower one. Comparing raw vCPU counts across providers will mislead you here.

It matters less for horizontally scalable, parallel workloads such as request handling, batch processing, or a container fleet. There, total scheduling capacity and memory bandwidth dominate, and the vCPU count is a reasonable proxy for both. Even then, benchmark the specific instance family you intend to buy.

How should you compare two offerings?

Compare the underlying CPU model, the baseline clock, the vCPU-to-thread mapping if documented, the memory per vCPU, the network baseline, and the price per hour. Then run the same workload on both, because published specs rarely capture cache contention, noisy neighbours, or storage throughput.

For a small app, the practical approach is to pick a modest instance, measure p95 latency and CPU steal, and resize from evidence. Choosing between two-vCPU and four-vCPU plans by spec sheet alone is guessing; a one-week measurement answers it for your workload.

Where this bites vibecoders
An AI assistant asked to size a server will often say four vCPUs because it sounds balanced, without knowing whether the workload is single-threaded. A generated Node app with one process uses one core regardless of how many vCPUs you buy. Measure the process model before buying the machine.

Where AI coding assistants get this wrong

Treating one vCPU as one physical core in capacity planning.
Comparing vCPU counts across providers as if they were equivalent.
Buying four vCPUs for a single-process app that can use one.
Ignoring CPU steal and noisy-neighbour effects on shared hosts.
Assuming more vCPUs fixes a database limited by disk or lock contention.
Skipping the benchmark and trusting the spec sheet.

Checklist

Identify whether the workload is single-threaded or parallel.
Check the provider’s vCPU-to-thread mapping for the instance family.
Compare CPU generation and clock speed, not just count.
Measure p95 latency and CPU steal on a real instance.
Check memory per vCPU before sizing.
Resize from measurements, not from a rule of thumb.

FAQ

Is one vCPU always one hyperthread?

No. Some providers map a vCPU to a hardware thread, some to a full core, and some to a share of a core on burstable families. The mapping is documented per instance family, and it can differ between families from the same provider. Treat the vCPU as a scheduling unit rather than a fixed hardware quantity.

Does more vCPUs always mean more performance?

Only if the workload can use them concurrently. A single-threaded process will use one vCPU regardless of how many are available. For parallel workloads, performance also depends on memory bandwidth, storage, and contention, so adding vCPUs can produce diminishing or negative returns.

How do I see the physical topology in a VM?

On Linux, inspect the CPU information and topology files exposed by the kernel. A guest may see logical processors without being told how they map to cores or sockets, and some hypervisors hide the topology entirely. That is another reason the vCPU count is not a reliable proxy for physical cores.

Should I use dedicated or shared vCPUs?

Use dedicated capacity when latency must be predictable, such as a database primary or a real-time service. Shared capacity is fine for variable web traffic and batch jobs, where occasional contention is absorbed by headroom. The price difference usually reflects that predictability.