Skip to content
  • Independent cloud account marketplace
  • Options and USD prices shown before checkout
  • Support available before and after ordering
Cloud Fundamentals

What Is a vCPU? Understanding Cloud Compute Sizing

A vCPU is a share of a physical processor, not a whole core. Learn how shared, dedicated, and burstable vCPUs differ, how vCPU quotas work, and how to size a cloud server.

Every cloud server is sized in vCPUs, and every serious cloud account has a vCPU quota. Yet the term hides a lot: a vCPU is not a whole processor, two vCPUs on different providers can perform very differently, and the number you can launch is capped by limits that have nothing to do with your credit card. This guide explains what a vCPU is, how shared, dedicated, and burstable vCPUs differ, how AWS, Google Cloud, Azure, OVHcloud, Hetzner, and DigitalOcean count them, and how to size a workload.

What a vCPU actually is

A vCPU (virtual CPU) is a slice of processor time that the hypervisor presents to a virtual machine as if it were a CPU. On most x86 instance types at AWS, Google Cloud, and Azure, one vCPU corresponds to one hardware thread of a physical core that has simultaneous multithreading enabled. Two vCPUs therefore usually map to one physical core, not two. On Arm-based instances such as AWS Graviton, each vCPU is a full physical core because those processors do not use multithreading.

Some providers use their own word. OVHcloud describes VPS and Public Cloud instance sizes in vCores. Azure uses vCPU for virtual machines and vCore for managed database tiers. DigitalOcean, Hetzner, Linode, Vultr, and UpCloud all say vCPU. The underlying idea is the same: a scheduled share of a physical processor.

Because a vCPU is a share rather than a fixed piece of silicon, its real performance depends on the processor generation underneath, the clock speed, and how much the host is oversubscribed. That is why provider instance families matter more than the raw vCPU count.

Shared, dedicated, and burstable vCPUs

Providers sell three broad kinds of vCPU, and the difference explains most of the price gap between plans with the same headline numbers.

Type How it behaves Provider examples Good for
Shared The physical core is shared with other tenants; you get a fair share, not a reserved one DigitalOcean Basic Droplets, Hetzner CX and CPX, Linode Shared CPU, Vultr Cloud Compute, OVHcloud VPS Web servers, dev boxes, small databases, anything with uneven load
Dedicated The vCPU is reserved for your VM; no other tenant competes for it DigitalOcean Dedicated CPU Droplets, Hetzner CCX, Linode Dedicated CPU, Vultr Optimized Cloud Compute, most AWS, Google Cloud, and Azure standard families Production databases, build servers, video encoding, sustained compute
Burstable Baseline performance with credits that allow short bursts above it AWS T-series, Azure B-series, Google Cloud E2 shared-core sizes Low average load with occasional spikes; cheapest option when sized honestly

On a shared plan, the Linux steal time counter shows how often your VM wanted the CPU but another tenant had it. A steady high steal value is a sign to move to a dedicated plan. On a burstable instance, the provider tracks CPU credits; run out and the instance is throttled to its baseline until credits accrue again.

vCPU quotas: the number you can actually launch

The hyperscalers cap how many vCPUs an account may run at the same time, and the cap is set per region and often per instance family. On AWS the relevant limits are the EC2 On-Demand instance quotas, expressed in vCPUs for groups such as “Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances”, with separate quotas for GPU, high-memory, and Spot instances. New accounts start with a low default and can request increases through the Service Quotas console. Google Cloud tracks a CPUs quota per region per project, with separate quotas for specific CPU platforms and GPUs. Azure sets a total regional vCPU quota on each subscription plus a quota per VM family, visible under Usage + quotas.

Developer clouds usually limit servers rather than vCPUs. DigitalOcean caps the number of Droplets per account, Hetzner caps the number of servers per project, and Linode and Vultr apply account-level limits that support can raise. The effect is the same: your total compute is bounded by an account attribute, not just by price.

Quotas exist to protect the provider from runaway or abusive usage and to protect you from surprise bills. Increases are granted on request, based on account age, payment history, and a stated use case. That is why marketplace listings describe accounts by their vCPU tier: a label such as “32vCPUs Account” or “512vCPUs Account” restates the quota level the seller reports for that listing, nothing more. Confirm the number in the console for the region you plan to use, because a limit granted in one region does not apply in another.

How to size a workload in vCPUs

  1. Pick the family before the size. General purpose families balance vCPU and memory (AWS M-series, Google Cloud N2 and E2, Azure D-series). Compute optimised families give more vCPU per GB of memory (AWS C-series, Google Cloud C2, Azure F-series). Memory optimised families do the reverse (AWS R-series, Google Cloud M-series, Azure E-series). Match the family to the bottleneck you actually have.
  2. Size for the peak of a typical day, not for an imaginary worst case. Horizontal scaling and load balancers handle the rare spikes better than a permanently oversized box.
  3. Check the memory ratio. Most databases and JVM applications run out of memory long before they run out of vCPU. A 2 vCPU, 8 GB server often outperforms a 4 vCPU, 4 GB server for those workloads.
  4. Prefer fewer, newer vCPUs. A current-generation processor at a higher clock speed frequently beats an older one with more threads, and providers usually price the newer generation the same or lower.
  5. Verify the quota before you commit. Add up the vCPUs across every instance you plan to run in the region, including staging and CI runners, and compare it with the limit in the console.

Reading a provider plan name

AWS instance names encode family, generation, and size: m7g.xlarge is family M, generation 7, Graviton processor, extra-large size. Google Cloud names are similar: n2-standard-4 is the N2 family, standard memory ratio, 4 vCPUs. Azure uses Standard_D4s_v5, meaning the D family, 4 vCPUs, premium storage support, version 5. Hetzner uses CX, CPX, and CAX for shared plans on different processor lines and CCX for dedicated. Learning to read these names saves time when comparing offers.

Where to go next

If you need an account with a specific EC2 vCPU quota tier, the listed tiers are on the Buy AWS Accounts page. For a European provider that sizes instances in vCores, the listed variants are on the Buy OVHcloud Accounts page. Both listings restate only what their labels say.

Related reading in the Cloud Library:

Browse every guide in the Cloud Library, or compare two European providers on the Hetzner vs OVHcloud page.

More from the Cloud Library

Telegram