Two VPS plans both advertise four vCPUs. One performs a long compile consistently while the other slows down during busy periods. The difference may reflect the CPU model, the allocation policy or the way the provider lets tenants share physical hardware. The number shown inside the guest is only the beginning of the comparison.

A vCPU is not always a physical core

DigitalOcean's Droplet plan documentation defines a vCPU as a hardware thread. Its dedicated CPU plans provide guaranteed access to the allocated thread; shared CPU plans share processor time among workloads. That is a product-specific definition, not a universal guarantee for every provider using the term dedicated.

Google Cloud's CPU platform documentation illustrates why physical core counts cannot be inferred from vCPU counts. Some machine series expose two threads per core, while others expose one. Its Arm platforms use one thread per core. Particular x86 families also differ from the common two-thread configuration.

Simultaneous multithreading lets two hardware threads share parts of a physical core's execution resources. Four vCPUs backed by four separate cores may perform differently from four backed by two cores with two threads each. The workload and processor architecture determine the difference.

Shared CPU is a scheduling arrangement

A shared CPU instance can be economical when its demand is usually low and short bursts can tolerate variation. When other tenants also need CPU time, scheduling delays may increase. Dedicated CPU is intended to buy more predictable access to the specified allocation, not necessarily an entire physical server or complete isolation from all shared hardware resources.

A small web application waiting mainly for its database might see little benefit from paying for dedicated CPU. A game server with a tight simulation deadline or a continuous encoder has a different concern: consistent execution time during sustained demand.

Short benchmarks can miss that distinction. Compare a longer representative workload and examine the variation in response times, not just the best result. Guest metrics such as CPU steal time may help reveal host scheduling effects on some virtualization platforms, but a low value does not prove the absence of contention or throttling. The available accounting depends on the hypervisor.

Burstable instances use a different model

Shared and burstable are not synonyms. Amazon EC2's CPU-credit documentation describes instances that earn credits below a defined CPU baseline and spend them when utilization exceeds it. The operating mode determines what happens when accrued credits are insufficient, including possible additional charges in Unlimited mode.

As a simplified example, imagine a two-vCPU instance with a 20% baseline per vCPU. Its aggregate baseline is 0.4 vCPU-equivalents. Running both vCPUs fully for 30 minutes uses 60 vCPU-minutes while the baseline corresponds to 12 vCPU-minutes in that interval. Ignoring credit-accounting details, the excess represents 48 vCPU-minutes.

A short test might run entirely on accumulated credits. A long test can expose a different performance or billing outcome. Check the actual instance family's baseline and credit rules before comparing it with a continuously allocated CPU plan.

A dedicated host is a placement choice

Google Compute Engine's VM tenancy documentation distinguishes ordinary multi-tenant placement from sole-tenant nodes. A physical host reserved for the permitted customer projects may still run several of that customer's own VMs.

This can satisfy particular placement or licensing requirements without giving every guest exclusive access to the entire server. The workloads may also share external networking, storage and regional services. Dedicated vCPU access and physical-host tenancy should be evaluated independently.

Other bottlenecks can dominate

A larger CPU allocation may not improve a workload limited by a single serial processing path, memory bandwidth, storage latency or a remote database. Compare CPU architectures and software support as well as the allocation terms.

For a latency-sensitive service, test the actual operation repeatedly under realistic concurrency. Record sustained throughput, high-percentile response times and any credit or throttling behavior. If the application spends most of its time waiting for disk or network I/O, investigate that before buying additional CPU.

The right purchase is the allocation that meets the workload's sustained requirements at an acceptable cost. Serverless, containers and VM cost models explains how the billing arrangement changes that calculation.