Getting Started

Understanding vCPU, RAM and the Specs on a Pricing Page

What a vCPU actually is, why two instances with the same number perform differently, and which specification usually limits you first.

3 min read

Cloud pricing pages describe instances in a small vocabulary: vCPU, RAM,
storage, transfer. The words look self-explanatory and are not, and the gap
between what they appear to promise and what they deliver explains a lot of
disappointed benchmarking.

What a vCPU is

A vCPU is a virtual CPU, which in practice usually means one hardware thread
rather than one physical core. Modern server processors run two threads per
core, so a two vCPU instance is frequently one physical core presented as two.

Two threads on one core do not deliver two cores of throughput. For
compute-heavy work the second thread adds a modest improvement rather than
doubling anything. This is not a trick; it is how simultaneous multithreading
works. But it means “4 vCPU” describes an allocation, not a performance
guarantee.

Why identical specs perform differently

Two providers both offering four vCPUs and eight gigabytes of RAM can differ
substantially in real throughput, for reasons the pricing page does not
mention:

  • Processor generation. A current-generation core is
    meaningfully faster than one several generations old, and both may be sold as a
    vCPU.
  • Clock speed and boost behaviour, which vary by instance
    family.
  • How many neighbours share the physical host, which
    determines how much contention you experience.
  • Storage performance, which is often the real constraint and
    is specified far less prominently than CPU.

Hetzner’s reputation for price-to-performance rests substantially on this
gap: the specification per unit of cost is higher than most competitors in the
entry tiers, which is covered in its
provider guide.

Shared versus dedicated

This distinction matters more than the vCPU count for predictability.

Shared instances draw from a pool of CPU shared with other
tenants. Most of the time you get what you expect. Occasionally a busy neighbour
takes some of it. This is fine for workloads with headroom and occasionally
frustrating for latency-sensitive ones.

Dedicated instances reserve physical cores for you. They
cost more and deliver consistent performance. If your workload has strict
latency requirements, or if you have ever been confused by a server that is
sometimes fast and sometimes not, this is the setting that explains it.

Some providers also sell burstable instances, which maintain
a baseline allocation and accumulate credits while idle that permit short bursts
above it. These are excellent for workloads that are quiet most of the time and
occasionally busy, and actively bad for sustained load, because the credits run
out and performance drops to the baseline. Understanding which type you bought
prevents a confusing afternoon.

RAM is usually what runs out first

For most web applications, databases and container workloads, memory is the
binding constraint rather than CPU. A process that exceeds available memory does
not slow down gracefully; it is terminated, or the machine starts swapping and
becomes unusable.

Leave more headroom on memory than on CPU for this reason. A server at
seventy percent CPU is working well. A server at ninety five percent memory is
one traffic spike from an incident.

Storage: size is the least interesting number

Capacity is easy to reason about and rarely the problem. What matters more
is throughput and operations per second, which are often tied to the volume’s
provisioned size on block storage. A small volume may be capped at a level that
limits a database considerably, and the fix is to provision a larger volume than
you need for capacity in order to get the performance.

Check whether storage is local to the host or network-attached. Local is
faster and disappears when the instance does. Network-attached survives the
instance and is the sensible default for anything you care about.

Transfer allowances belong in the comparison

Many providers bundle an outbound transfer allowance with each plan, and the
size of that allowance varies enormously. Comparing two instances on CPU and RAM
alone while ignoring that one includes a generous allowance and the other meters
from the first gigabyte produces a conclusion that the invoice will contradict.
The mechanics are in
data egress fees explained.

How to choose without agonising

Start one size smaller than feels comfortable and measure. Resizing upward
takes minutes on every major platform, and the measurement is worth more than
the estimate. For a first deployment, two vCPUs and four gigabytes of RAM
handles a surprising amount, and you will learn more from a week of real metrics
than from a day of comparing specification tables.

Scroll to Top