Cloud VM types and machine classes describe how a virtual machine combines CPU allocation, vCPU count, memory, and storage for different workload patterns.
For most small teams, the useful decision is not “Which VM type is best?” It is which resource becomes limiting first, and whether that resource needs predictable allocation. A balanced web application, a CPU-bound worker, and a memory-heavy database can all use similar vCPU counts while needing very different VM shapes.
Raff Technologies organizes its VM lineup around two primary compute families: General Purpose for shared-vCPU, balanced or variable workloads, and CPU-Optimized for dedicated compute where sustained CPU behavior matters. Memory-forward General Purpose shapes provide more RAM per vCPU when memory pressure is the main constraint.
Current September 2026 reference pricing starts at $4.99/month for General Purpose and $15.99/month for CPU-Optimized. A like-for-like 2 vCPU / 4 GB / 80 GB comparison is $17.99/month General Purpose vs $36.99/month CPU-Optimized.
Cloud VM types differ by resource shape and CPU allocation
A VM type or machine class is a resource model, not a quality grade.
Cloud providers group virtual machines because workloads create pressure in different places. Some applications need balanced CPU and memory. Others need predictable CPU time for long-running compute. Databases, caches, and multi-service applications may need more RAM per vCPU. Storage-sensitive workloads may run out of capacity before CPU becomes important.
The main dimensions are:
- CPU allocation: shared or dedicated compute;
- vCPU count: available parallel compute;
- memory ratio: RAM available relative to vCPU;
- storage capacity: local persistent storage available to the VM;
- storage behavior: read/write intensity and durable data growth;
- network behavior: throughput and transfer requirements;
- operational role: whether one VM hosts one service or several competing services.
Two 4 vCPU machines can therefore be very different choices. One may provide shared CPU with a balanced memory ratio, while another reserves compute for sustained CPU work. A third configuration may keep fewer vCPUs but provide more RAM.
The class name should summarize the resource trade-off. It should not replace workload measurement.
General Purpose vs CPU-Optimized at a glance
| Decision factor | General Purpose | CPU-Optimized |
|---|---|---|
| CPU model | Shared vCPU | Dedicated compute |
| Best starting fit | Balanced, bursty, variable workloads | Sustained or CPU-sensitive workloads |
| Main advantage | Lower cost and flexible resource ratios | More predictable sustained CPU behavior |
| Typical workloads | Websites, APIs, dev, staging, small SaaS apps | CI runners, workers, compilation, encoding, compute-heavy services |
| When to upgrade | Capacity or RAM becomes the constraint | CPU predictability itself becomes valuable |
| Current starting price | $4.99/month | $15.99/month |
| Current 2 vCPU / 4 GB / 80 GB reference | $17.99/month | $36.99/month |
This is the central machine-class decision on Raff. General Purpose is the stronger default when the workload is mixed or still uncertain. CPU-Optimized becomes more defensible when sustained CPU pressure repeatedly affects latency, throughput, build time, queue age, or another measurable result.
Choose a VM type by the first constrained resource
The most reliable selection method is to identify what the workload runs out of first during normal pressure.
| Workload signal | Likely constraint | Better starting direction |
|---|---|---|
| CPU rises briefly, then returns to normal | Variable compute | General Purpose |
| CPU stays high while latency or job time increases | Sustained compute | CPU-Optimized or more vCPU |
| CPU is moderate but memory is near exhaustion | RAM | Memory-forward shape |
| Swap activity or OOM events appear | RAM | More memory or service separation |
| App, database, queue, and workers compete on one VM | Mixed contention | More memory first, then consider separation |
| Builds or workers take too long with sustained CPU pressure | Compute throughput | CPU-Optimized |
| Database is slow while CPU remains comfortable | Query, memory, storage, or locks | Diagnose before changing VM class |
| Logs, uploads, or database files consume disk rapidly | Storage growth | More or separate storage |
| Different services need independent scaling or recovery | Architecture boundary | Split roles instead of buying one larger VM |
This prevents a common sizing mistake: upgrading the resource that is easiest to see rather than the resource actually controlling the workload.
A database-backed application can show moderate CPU and still be unstable because memory is exhausted and swap is active. More vCPU would add compute without solving the real problem. A CI runner can have plenty of free memory while every available CPU remains busy for long periods. More RAM would add the wrong resource.
Use this sequence:
- identify the user-visible or operational problem;
- correlate it with CPU, memory, storage, and application behavior;
- choose the VM type or size that changes the constrained resource;
- verify that latency, throughput, stability, or completion time improves.
General Purpose VMs fit balanced and variable workloads
General Purpose is the default when no single resource consistently dominates the workload.
Typical fits include:
- websites and content applications;
- APIs with modest or variable traffic;
- development and staging environments;
- internal tools;
- early SaaS applications;
- small backend services;
- lightweight self-hosted applications;
- mixed workloads where the bottleneck is not yet clear.
Shared vCPU can also be appropriate for production. Production responsibility means the service matters; it does not automatically mean the application needs dedicated CPU. If the workload meets its latency and throughput targets and CPU pressure is brief or variable, shared compute can remain the more economical choice.
Raff General Purpose currently starts at 1 vCPU / 1 GB RAM / 25 GB NVMe for $4.99/month. The lineup includes multiple CPU-to-memory ratios, so teams can increase RAM without always increasing vCPU.
For the current plan-by-plan ladder, use Raff General Purpose VM Plans.
CPU-Optimized VMs fit sustained compute
CPU-Optimized makes sense when compute is not merely busy but controls an outcome that matters.
Good candidates include:
- CI/CD runners with long CPU-bound builds;
- queue workers processing continuously;
- encoding, compression, compilation, or transformation jobs;
- compute-heavy application services;
- APIs where tail latency rises with CPU pressure;
- analytics jobs with sustained processing;
- database workloads measured and confirmed as CPU-bound.
Short CPU spikes alone are not enough. Deployments, package updates, cache warm-ups, and traffic bursts can temporarily use every vCPU on an otherwise healthy General Purpose VM.
CPU-Optimized becomes more compelling when CPU pressure is repeatable under equivalent load and connects to:
- slower p95 or p99 response time;
- longer build duration;
- growing queue age;
- reduced worker throughput;
- missed batch deadlines;
- inconsistent completion time.
Raff CPU-Optimized currently starts at 1 vCPU / 1 GB RAM / 25 GB NVMe for $15.99/month. For a direct CPU allocation comparison, see Shared CPU vs Dedicated CPU.
Memory-forward VM shapes fit RAM pressure
Not every workload that needs a larger VM needs more CPU.
Memory-forward configurations are useful when the working set grows faster than compute demand. Common examples include:
- PostgreSQL or MySQL databases;
- caches and in-memory services;
- analytics dashboards;
- multi-container applications;
- self-hosted platforms with several services;
- runtimes with large heaps;
- combined app + database + worker stacks.
Memory pressure signals include sustained swap activity, out-of-memory events, container restarts, database cache pressure, and deployment failures because existing services leave too little RAM headroom.
Raff's General Purpose ladder includes memory-forward ratios such as 2 vCPU / 8 GB, 4 vCPU / 16 GB, and 8 vCPU / 32 GB. These shapes can be more economical than buying extra vCPU only to obtain more RAM.
For the deeper memory decision, use HiMem VMs Explained.
More vCPU and a different VM class are not the same upgrade
Class answers what resource profile the workload needs. Size answers how much of that profile it needs.
If a shared-vCPU application is CPU-bound only because the VM is too small, moving from 2 vCPU to 4 vCPU may solve the problem without changing machine class. If the workload still suffers from sustained CPU variability after right-sizing, CPU-Optimized becomes the more relevant test.
Likewise, increasing vCPU will not fix a memory-bound database, and moving to dedicated CPU will not fix slow queries or storage waits.
Use 2 vCPU vs 4 vCPU Cloud VMs when core count is the main question, and Cloud Server Performance Bottlenecks when the constrained resource is unclear.
Storage and architecture can matter more than VM type
A machine-class change is not always the right infrastructure change.
| Symptom | Better question |
|---|---|
| Disk fills because of uploads | Should user files move to object storage? |
| Database files grow rapidly | Does the database need its own storage and recovery boundary? |
| Logs consume local disk | Can retention or centralized logging reduce growth? |
| Backups compete with production I/O | Should backup timing or recovery design change? |
| App and database compete for RAM and CPU | Is it time to separate the database? |
| Workers interfere with web latency | Should workers move to another VM? |
Different services can also use different VM types. A web tier may stay on General Purpose while sustained workers move to CPU-Optimized. A database may need a memory-forward ratio instead. There is no requirement that every service in one application use the same machine class.
Split services only when independent scaling, deployment, security, or recovery benefits justify the added operational complexity.
