vCPU vs core: what a cloud provider is actually selling you

Two providers both advertise four vCPUs at similar prices. One consistently completes your job in half the time. Nothing is wrong with either of them, and the specification was never comparable in the first place.

What a vCPU usually is

On most cloud platforms, a vCPU maps to one hardware thread rather than one physical core. Modern processors run two threads per core, so a four vCPU instance is typically two physical cores with simultaneous multithreading enabled.

That is not deceptive, it is just a unit that needs stating. Two threads on one core deliver more total throughput than one thread, but nothing close to two full cores. For parallel workloads the gain is real; for a single threaded process it is nothing at all.

The units that differ

Oracle Cloud quotes OCPUs. An OCPU is a physical core with hyperthreading, so one OCPU is roughly two vCPUs elsewhere. Comparing an Oracle price per OCPU against an AWS price per vCPU without normalising produces an answer that is wrong by a factor of two, in Oracle’s favour.

Some providers allocate dedicated physical cores on their higher tiers and share threads on their entry tiers, without always changing the word they use.

Before comparing anything, establish what unit each side is quoting.

Shared against dedicated

The larger practical difference is not thread counting, it is whether the allocation is guaranteed.

Shared or burstable. You receive a baseline share of a core and can use more when the host is quiet. Some providers formalise this with a credit system: the instance accrues credits while idle and spends them under load, throttling when they run out. Excellent value for spiky, low average workloads. Unpredictable for anything with a sustained floor.

Dedicated. The threads or cores are yours. No noisy neighbour effects, consistent latency, higher price. This is what you move to when the variance rather than the average becomes the problem.

The symptom that tells you to move is not a slow average. It is a response time distribution with a long tail: most requests fast, some inexplicably slow, no pattern in the application logs.

Clock speed and generation still matter

A vCPU on a current generation processor does meaningfully more work per second than one on a five year old part. Providers frequently offer both at different prices, and the newer generation is often cheaper per unit of actual work despite the higher hourly rate.

Architecture matters too. Arm based instances from all the major providers generally offer better price for performance where the software runs natively, which today covers most Linux workloads, containers built for multiple architectures and standard runtimes.

How to compare honestly

1. Normalise the unit. Convert everything to threads or to physical cores before looking at price.
2. Check shared against dedicated. These are different products and should not be compared on price alone.
3. Note the processor generation and architecture. Both change the amount of work per unit.
4. Benchmark your own workload. Synthetic scores are a weak proxy. Run the actual job for an hour on each candidate; it costs almost nothing and settles the argument.
5. Measure the tail, not the mean. The ninety ninth percentile is what your users experience.

Where the quota comes in

Confusingly, the same word governs how much you are allowed to run. Cloud providers cap concurrent capacity in vCPU terms per account or project and per region, and those limits start low on new accounts. A machine you can afford is not necessarily a machine you can launch. The mechanics are in AWS vCPU quotas explained, and the same pattern applies on Azure and Google Cloud.

For the naming schemes that encode all of this, see EC2 instance families, Azure VM series decoded and Compute Engine machine types.