Shared vs dedicated vCPU describes how a cloud VM receives CPU time: shared vCPU uses host compute scheduled across multiple VMs, while dedicated vCPU reserves CPU capacity for one VM so sustained compute behavior is more predictable.
The choice matters when CPU consistency affects real work, not simply because one class sounds more powerful. Raff Technologies supports 3,000+ customers and 15,000+ VMs, and a recurring pattern in infrastructure work is that teams often consider dedicated CPU after seeing one busy graph. The stronger signal is repeatable: CPU pressure rises at the same time as latency, queue age, build duration, or job completion time under comparable load.
This guide focuses on the CPU allocation model. For the broader choice between balanced, CPU-focused, and memory-focused machines, start with Cloud VM Machine Classes Explained. If the question is simply whether you need 2 vCPU or 4 vCPU, use 2 vCPU vs 4 vCPU Cloud VMs.
Shared and dedicated vCPU trade cost efficiency for CPU predictability
Shared and dedicated vCPU can both run real production workloads. The difference is what you are paying to control.
With shared vCPU, the host schedules CPU capacity across multiple virtual machines. This is efficient for workloads that are idle much of the time, burst for short periods, or can tolerate some variation in execution time.
With dedicated vCPU, CPU capacity is reserved for the VM. That makes the class more useful when sustained compute or timing consistency matters enough to justify the additional cost.
| Factor | Shared vCPU | Dedicated vCPU |
|---|---|---|
| CPU allocation | Scheduled from shared host capacity | Reserved CPU capacity for the VM |
| Main advantage | Lower cost for variable workloads | More predictable sustained CPU behavior |
| Main trade-off | More potential performance variation | Higher cost for reserved compute |
| Strong starting fit | Websites, dev, staging, small apps, variable APIs | CI runners, busy workers, compute-heavy services, latency-sensitive apps |
| Production use | Valid when CPU consistency is not the constraint | Useful when consistency has measurable value |
| Upgrade reason | More resources may be enough | CPU predictability itself must solve a problem |
A useful mental model is: shared vCPU buys cost efficiency; dedicated vCPU buys CPU predictability.
Neither class fixes insufficient RAM, slow storage, inefficient queries, external API latency, or application code that cannot use additional CPU.
The decision framework starts with sustained CPU behavior
The decision should connect CPU behavior to a workload outcome.
| Evidence | Better first decision | Why |
|---|---|---|
| CPU is usually low with short bursts | Shared vCPU | Reserved CPU would sit unused much of the time |
| Brief deployment or traffic spikes | Stay shared and observe | Short spikes alone do not prove a consistency problem |
| Sustained CPU around 70–80% with rising latency or queue time | Investigate CPU class and size | Compute may be controlling the workload |
| CPU pressure repeats during equivalent builds or jobs | Dedicated vCPU becomes a candidate | Predictable compute can matter to completion time |
| p95/p99 latency varies with sustained CPU pressure | Dedicated vCPU becomes a candidate | Tail latency may be sensitive to CPU scheduling |
| CPU is moderate but RAM is exhausted or swap is active | Add memory or change memory class | CPU allocation is not the primary constraint |
| CPU is low but database queries are slow | Diagnose queries, locks, storage, or connections | Dedicated CPU would not address the main wait |
| Development or staging workload is intermittent | Shared vCPU | Cost efficiency usually matters more than strict consistency |
| Worker or CI workload runs CPU-bound for long periods | Dedicated vCPU | Sustained compute makes reservation more useful |
The 70–80% range is an investigation trigger, not a universal threshold. A workload can operate correctly at high utilization, and another can miss latency goals at a lower average. The important relationship is pressure plus impact.
In Raff infrastructure work, the useful evidence is repeatability. If CPU pressure and user-visible latency or job duration rise together under comparable load, changing CPU class is defensible. If memory, storage, queries, or a dependency controls the outcome, dedicated CPU usually does not fix the problem.
Shared vCPU fits bursty and cost-sensitive workloads
Shared vCPU is usually the sensible default when compute demand is variable and occasional CPU variation does not create a meaningful business or operational problem.
Good fits include:
- websites and content applications with uneven request patterns;
- development and staging environments;
- internal tools with intermittent usage;
- early SaaS applications with modest traffic;
- small APIs that spend substantial time waiting on databases or external services;
- test servers and temporary environments;
- workloads where memory or storage matters more than sustained compute.
Shared CPU is also valid for production when the application is healthy on it. “Production” describes responsibility, not CPU behavior. A low-traffic customer application with comfortable latency and resource headroom does not become CPU-bound merely because users pay for it.
Stay on shared vCPU when the workload meets its latency and throughput targets and CPU pressure is not repeatably controlling the outcome. If more headroom is needed, a larger shared VM may be a simpler and more economical change than moving immediately to dedicated compute.
The main reason to leave shared CPU is not status or architecture maturity. It is evidence that more predictable CPU access solves a real constraint.
Dedicated vCPU fits sustained or latency-sensitive compute
Dedicated vCPU becomes more useful as compute demand becomes sustained, repeatable, and expensive to vary.
Common candidates include:
- CI/CD runners with CPU-bound builds or test suites;
- queue workers processing jobs continuously;
- encoding, compression, compilation, or transformation workloads;
- CPU-heavy application services;
- customer-facing APIs where tail latency correlates with CPU pressure;
- databases whose measured workload is genuinely CPU-bound;
- scheduled processing that must finish inside a predictable window.
The strongest case is a workload where execution time has operational value. If a build blocks every deployment, a worker queue has a deadline, or request latency directly affects users, greater CPU predictability may be worth paying for.
Dedicated CPU is not automatically the right database class. A database can be limited by memory, query plans, indexes, locks, connections, or storage latency. Confirm CPU is controlling the workload before changing allocation model.
Likewise, a CPU-Optimized VM is not a substitute for application tuning. Reserved compute can make CPU-bound execution more predictable, but it cannot remove work the application should not be doing.
CPU count, memory, and application design can matter more than allocation model
A CPU class decision sits beside several other sizing decisions.
More vCPU may solve capacity before dedicated CPU is needed
If a shared VM is simply too small, moving from 2 vCPU to 4 vCPU may provide enough headroom without changing allocation model. Use 2 vCPU vs 4 vCPU Cloud VMs when core count is the main question.
More memory is the correct fix for memory pressure
Swap activity, out-of-memory events, container restarts, and a database cache starved for RAM point toward memory. HiMem VMs Explained covers that decision.
Application and database work should be optimized first when possible
A slow query, unbounded worker concurrency, excessive serialization, or synchronous external call can create symptoms that resemble infrastructure limits. Before changing VM class, identify where the workload waits.
Cloud Server Performance Bottlenecks provides the diagnostic path across CPU, memory, disk I/O, network, databases, and dependencies.
The practical sequence is therefore:
- confirm the user-visible or operational problem;
- identify the constrained resource;
- optimize avoidable work;
- resize if capacity is insufficient;
- choose dedicated CPU when predictability itself remains the constraint.
Measure the workload before changing VM class
A dedicated CPU decision should be supported by a before-and-after test rather than a plan label.
Track metrics that connect compute pressure to outcomes:
- CPU utilization over time;
- load or run-queue pressure;
- CPU steal time when the guest exposes it;
- request p50, p95, and p99 latency;
- queue depth and oldest-job age;
- worker throughput and job duration;
- build and test duration;
- database query time;
- memory and swap activity;
- disk I/O wait;
- error and timeout rates.
Compare equivalent workload windows. A production traffic peak should not be compared with an idle overnight period, and a clean build should not be compared with a cached build.
A simple validation looks like this:
| Test | Shared class | Dedicated class | Decision |
|---|---|---|---|
| Same request mix | Record p95/p99 and CPU pressure | Repeat with equivalent load | Keep dedicated only if the workload outcome improves meaningfully |
| Same CI build | Record duration and variance across runs | Repeat the same pipeline | Look for lower or more predictable duration |
| Same worker batch | Record completion time and queue age | Repeat with same job set | Confirm throughput improves without moving the bottleneck |
Do not evaluate only average CPU percentage. A class change is successful when latency, completion time, throughput, or operational predictability improves enough to justify the cost.
Raff maps General Purpose to shared compute and CPU-Optimized to dedicated compute
Raff exposes the CPU allocation decision through two VM families:
- General Purpose uses shared CPU resources for balanced and variable workloads.
- CPU-Optimized provides dedicated CPU cores for workloads that need more consistent compute behavior.
As of August 10, 2026, Raff's live pricing page lists the General Purpose entry plan at $8.49/month for 2 vCPU, 2 GB RAM, and 40 GB NVMe, while the CPU-Optimized family starts at $9.99/month. Exact configurations and prices should still be checked on the live pricing page before deployment because plan tables can change.
Both families are part of the broader Raff VM model, which currently includes 3 Gbps port speed, unmetered VM bandwidth, resize support, private networking, monitoring, and root access.
The product mapping does not change the decision framework. General Purpose is the better default when CPU demand is variable and shared scheduling is acceptable. CPU-Optimized is the stronger fit when measured sustained compute or latency variance makes dedicated CPU valuable.
For the full machine-class map, return to Cloud VM Machine Classes Explained. For current shared-class sizes, use Raff General Purpose VM Plans Explained.
Choose dedicated CPU only when predictability solves a real constraint
Shared vs dedicated vCPU is not a basic-versus-serious distinction. It is a decision about whether reserved CPU capacity improves an outcome that matters.
Start with shared vCPU when the workload is bursty, cost-sensitive, or still has comfortable CPU headroom. Keep production workloads on shared compute when they meet their latency and throughput targets. Move toward dedicated vCPU when sustained CPU pressure repeatedly aligns with tail latency, build time, worker throughput, or another measurable constraint.
Before changing class, rule out memory pressure, storage latency, inefficient queries, application code, and external dependencies. If the problem is simply insufficient core count, resizing a shared VM may still be the smaller change.
Continue with Cloud VM Machine Classes Explained for the parent decision or review Cloud Server Performance Bottlenecks before changing capacity.