What is the difference between shared and dedicated vCPUs?
A dedicated vCPU is a processor thread or core that the hypervisor reserves for one virtual machine, so its performance does not depend on other customers. A shared vCPU comes from a pool of physical cores that several virtual machines use at once, so it is cheaper but can slow down when neighbors are busy. On Hetzner Cloud as of 14 November 2026, a 2 vCPU shared server (CPX22) costs €19.99 a month in Nuremberg and a 2 vCPU dedicated server with more memory (CCX13) costs €43.49.
What a vCPU is
A vCPU is the unit of processor capacity a cloud sells, and its meaning depends on the hardware:
- On most x86 instances, a vCPU is one hardware thread. AWS states that each vCPU “is a thread of either an Intel Xeon core or an AMD EPYC core” for most instance types, and Google Cloud says “a vCPU represents a single thread” on its x86 series. Two vCPUs therefore usually share one physical core.
- On Arm processors without simultaneous multithreading, such as AWS Graviton or Google’s Axion-based C4A, a vCPU is a full core.
Kubernetes counts the same way: 1 CPU unit is one physical core on bare metal or one virtual core on a virtual machine.
How shared vCPUs work
With shared vCPUs, the provider places more virtual CPUs on a host than it has physical threads, on the assumption that most machines are idle most of the time. Hetzner describes its shared plans this way: “hypervisors are used to distribute usage rights of CPU resources among several virtual servers” (servers overview). When several tenants need CPU at the same moment, each one waits for a turn.
That waiting shows up inside the guest as steal time: the share of time a vCPU was ready to run while the hypervisor served another virtual machine. You can read it in:
top, as thestvalue in the CPU summary linempstat -P ALL 5, as the%stealcolumn (sysstat)vmstat 5, as thestcolumn
Steal time that stays high under load means your workload is losing part of the CPU it pays for. Latency-sensitive services show it first, as slower and less predictable response times.
Burstable credits are a different model
Some providers sell shared capacity as burstable instances with a CPU credit budget instead of an open pool:
- AWS T instances earn credits while they run below a baseline and spend them above it. One credit equals one vCPU at 100% for one minute. A
t3.mediumhas a baseline of 20% per vCPU. In the default unlimited mode, AWS bills extra per vCPU-hour if average use over 24 hours stays above the baseline. - Azure B-series VMs use a similar credit model and throttle back to the base performance level when credits run out.
- Google Cloud offers E2 shared-core machine types (
e2-micro,e2-small,e2-medium) next to its standard machine types.
Burstable instances are predictable about their limit but punish sustained load. Shared pools without credits let you use full CPU at any time, with performance that depends on neighbors.
How the tiers map across providers
| Provider | Shared or burstable | Dedicated or fixed |
|---|---|---|
| Hetzner Cloud | Cost-Optimized CX (x86) and CAX (Arm) on older hardware; Regular Performance CPX on newer AMD | General Purpose CCX, dedicated AMD vCPUs |
| AWS | T family (T3, T3a, T4g, T8i) with CPU credits | M, C and R families with fixed CPU resources |
| Google Cloud | E2 shared-core types | Other E2 sizes and N, C series machine types |
| Azure | B-series with CPU credits | D, F and E series |
Hetzner prices as of 14 November 2026, per month, excluding VAT, including an IPv4 address:
| Hetzner type | vCPU and RAM | Nuremberg | Helsinki |
|---|---|---|---|
| CX23 (shared, Cost-Optimized) | 2, 4 GB | €5.99, not orderable | €5.99, not orderable |
| CPX22 (shared, Regular Performance) | 2, 4 GB | €19.99 | €16.99 |
| CCX13 (dedicated, General Purpose) | 2, 8 GB | €43.49 | €36.99 |
Sources: Hetzner’s Cost-Optimized, Regular Performance and General Purpose pages. The Cost-Optimized line has been unavailable since a capacity shortage that began on 26 June 2026, as explained in why you can’t create a Hetzner server.
Which workloads fit which tier
| Shared vCPUs work well for | Dedicated vCPUs are worth it for |
|---|---|
| Development and staging environments | Databases and message brokers |
| CI runners and batch jobs that tolerate variance | Services with latency SLOs, such as APIs at p99 |
| Stateless web front ends with low average CPU | Sustained CPU work: encoding, compilation, analytics |
| Small internal tools | Benchmarks and load tests that need repeatable results |
Network-heavy workloads can also behave differently. In our benchmark of Hetzner’s new network stack, an 8 vCPU shared CPX42 received 7.5 to 8.9 Gbit/s of 8-stream TCP traffic, while a 4 vCPU dedicated CCX23 received 15.6 to 18.1 Gbit/s on the same network stack.
What it means for Kubernetes
The scheduler places Pods by their CPU requests and assumes that a requested core is a core. On shared vCPUs that assumption holds only while neighbors are quiet, so a node can look half empty and still run slowly. CPU limits are enforced by throttling, so on a contended node a Pod can be held back by its own limit and by its neighbors at the same time. The trade-offs are covered in Kubernetes resource requests and limits.
A common pattern is to run separate node pools per tier: shared vCPU nodes for stateless and batch workloads, dedicated vCPU nodes for databases and latency-sensitive services, steered with node labels, taints and tolerations.
On Cloudfleet, node auto-provisioning selects Hetzner shared, dedicated or Arm server types from your Pod requests and constraints, and you can pin a workload to a CPU type with node selectors.