Cloud right-sizing is the practice of changing a running VM so its CPU, memory, storage, and compute class match the workload it actually uses. In cloud computing, right-sizing is not simply “make the server smaller.” It means removing persistent excess capacity without creating a new performance or reliability bottleneck.
For an already deployed workload, the safest sequence is: measure representative usage, identify the constrained or consistently idle resource, change one variable where practical, and compare the workload outcome after the resize. Raff Technologies supports 3,000+ customers and 15,000+ VMs, and the recurring mistake in cost reviews is making a resize from one utilization percentage without checking latency, swap, queueing, storage growth, or application behavior.
This guide is for post-deployment VM optimization. If you are choosing a server for the first time, use the VM Sizing Guide. If the VM is slow and you do not yet know why, start with Cloud Server Bottlenecks.
What is right-sizing in cloud computing?
Right-sizing in cloud computing means matching provisioned resources to measured workload demand over representative periods.
A VM can be mis-sized in two directions:
- overprovisioned: it carries CPU, RAM, or storage that stays unused without serving a clear resilience or growth purpose;
- underprovisioned: it lacks enough capacity for normal demand, peaks, deployments, backups, or maintenance, causing pressure or instability.
The goal is not maximum utilization. A production VM needs headroom. The goal is to distinguish useful headroom from persistent excess.
Useful headroom absorbs expected peaks, deployments, scheduled jobs, backup activity, and short-term growth. Persistent excess remains unused across normal and peak periods and does not protect a specific reliability requirement.
That distinction is why there is no universal “right-size at 70% CPU” or “downsize below 30% memory” rule. The same utilization number can mean very different things for a batch worker, API, database, staging VM, or CI runner.
Cloud right-sizing is a cloud cost optimization method
Cloud right-sizing is one of the most practical forms of cloud cost optimization because it focuses on a specific decision: whether a running VM should be downsized, upsized, moved to another resource ratio, or split into separate services.
A cost-saving resize is successful only when the workload still meets its reliability and performance requirements afterward.
For example, current Raff General Purpose pricing includes:
| VM shape | Monthly price |
|---|
| 1 vCPU / 1 GB / 25 GB | $4.99 |
| 1 vCPU / 2 GB / 50 GB | $8.99 |
| 2 vCPU / 2 GB / 40 GB | $12.99 |
| 2 vCPU / 4 GB / 80 GB | $17.99 |
| 4 vCPU / 4 GB / 80 GB | $24.99 |
| 2 vCPU / 8 GB / 160 GB | $27.99 |
| 4 vCPU / 8 GB / 160 GB | $33.99 |
Moving a workload from 4 vCPU / 8 GB at $33.99/month to 2 vCPU / 4 GB at $17.99/month would reduce that VM's monthly compute price by $16, but it is a valid optimization only if the application still has enough CPU, memory, and storage headroom after the change.
Use workload outcomes, not one utilization threshold
A right-sizing decision should connect resource evidence to an application or operational outcome.
| Evidence | Likely interpretation | First action |
|---|
| CPU has long periods of headroom and peaks remain safe | Possible excess CPU | Test a smaller CPU shape |
| Sustained CPU pressure aligns with rising p95/p99 latency | Underprovisioned compute | Add vCPU or evaluate CPU-Optimized |
| Low available memory plus swap or OOM events | Underprovisioned RAM | Add memory or reduce memory demand |
| Large RAM allocation stays unused through representative peaks | Possible excess memory | Test a lower-memory shape |
| Disk capacity grows steadily toward the limit | Storage capacity issue | Increase or separate storage |
| High storage latency while capacity is comfortable | I/O issue, not capacity | Diagnose storage/application I/O |
| Worker queue grows while CPU is saturated | Compute throughput issue | Add compute or workers |
| CPU is low but database latency is high | Likely DB/query/storage issue | Diagnose before resizing VM CPU |
| App and DB compete for the same resources | Architecture contention | Consider separating roles |
The useful pattern is resource pressure plus workload impact. CPU can run hot on a batch job and still be correctly sized if the job meets its deadline. A customer-facing API can need more headroom even when its average CPU looks moderate if brief pressure repeatedly damages tail latency.
For memory-specific signals, use How Much RAM Do I Need for a VPS?.
A practical cloud right-sizing workflow
Use a repeatable process rather than resizing from a dashboard snapshot.
1. Define the outcome that matters
Choose the workload metric you are protecting or improving. Examples include:
- p95 or p99 application latency;
- request throughput;
- queue age;
- worker completion rate;
- CI build duration;
- database query latency;
- deployment stability;
- error and timeout rate;
- monthly infrastructure cost.
Without an outcome, a lower utilization percentage is not proof of success.
2. Measure representative periods
Review normal traffic, known peaks, deployments, backups, scheduled jobs, and maintenance. For seasonal or low-frequency workloads, a few quiet hours are not representative.
Useful Linux signals include CPU pressure, MemAvailable, swap activity, OOM events, load, storage growth, I/O latency, and application-level latency or queue metrics.
3. Identify the resource that is excessive or constrained
Do not assume the whole VM is too large or too small. A machine can have excess CPU and insufficient RAM at the same time.
Raff General Purpose provides multiple CPU-to-memory ratios. For example, current plans include 2 vCPU / 4 GB at $17.99, 4 vCPU / 4 GB at $24.99, and 2 vCPU / 8 GB at $27.99. Those shapes allow teams to change the resource ratio instead of always scaling CPU and RAM together.
4. Change one variable where practical
If CPU is excessive but memory is correct, choose a shape that reduces CPU without unnecessarily reducing RAM. If RAM is the constraint while CPU has headroom, move toward a memory-forward shape.
If sustained CPU predictability—not simply vCPU count—is the issue, evaluate Shared CPU vs Dedicated CPU.
5. Compare before and after
Repeat an equivalent workload and compare both resource behavior and workload outcomes.
A successful downsize preserves the required latency, throughput, stability, and maintenance headroom while reducing cost. A successful upsize improves the constrained workload outcome rather than merely lowering a utilization chart.
6. Check whether the bottleneck moved
Adding CPU can expose database or storage limits. Adding memory can reveal a CPU-bound worker. Splitting a service can shift the bottleneck to network or database connections.
Right-sizing is iterative because infrastructure bottlenecks are often sequential.
How to identify an oversized VM
An oversized VM has persistent excess capacity that is not justified by a known peak, resilience requirement, or near-term growth event.
Useful signs include:
- CPU has substantial headroom across representative normal and peak periods;
- available memory remains consistently high even during application peaks;
- the VM was sized for a launch, migration, or temporary spike that has ended;
- staging, testing, preview, or internal workloads use production-sized resources without similar demand;
- one large VM hosts several mostly idle services that could be consolidated differently;
- storage capacity was provisioned far ahead of realistic growth.
Do not downsize simply because average CPU is low. A service with low average demand but sharp latency-sensitive peaks may still need burst headroom. Review peak behavior and the business cost of saturation first.
Non-production environments are often the easiest right-sizing candidates because their availability requirements are lower. For that broader cost-control problem, see Idle Infrastructure Cost.
How to identify an undersized VM
An undersized VM repeatedly loses performance or operating safety because one or more resources cannot meet normal demand.
Strong signals include:
- sustained CPU pressure that aligns with latency or queue growth;
- swap activity or memory-pressure stalls during representative load;
- OOM events or container restarts;
- deployments failing because the server lacks temporary headroom;
- background jobs falling behind arrival rate;
- disk capacity approaching a dangerous limit;
- database or storage operations stalling under normal work;
- maintenance, backups, or scheduled tasks destabilizing the application.
The hidden cost of undersizing is engineering time. Saving a few dollars on compute is not useful when the team repeatedly investigates failures caused by insufficient capacity.
If the constrained resource is unclear, use the Cloud Server Bottlenecks diagnostic flow before changing the plan.
CPU right-sizing: more vCPU is not always the answer
CPU right-sizing asks whether the workload has enough parallel compute and whether the CPU allocation model matches its sensitivity.
More vCPU helps when there is useful runnable work that can execute concurrently. It helps less when the application is waiting on a serial code path, storage, database locks, external APIs, or memory.
For current Raff General Purpose, a useful CPU-only comparison is:
- 2 vCPU / 4 GB / 80 GB — $17.99/month
- 4 vCPU / 4 GB / 80 GB — $24.99/month
Memory and storage stay constant, so this pair is useful when you want to test whether additional CPU—not RAM—is the required change.
Use 2 vCPU vs 4 vCPU for that specific decision.
For sustained CPU-sensitive work, Raff CPU-Optimized uses dedicated compute. A current 2 vCPU / 4 GB / 80 GB CPU-Optimized VM is $36.99/month, compared with $17.99/month for the shared-vCPU General Purpose shape. Dedicated compute should therefore solve a measured predictability or sustained-compute requirement, not be treated as a default upgrade.
Memory right-sizing should follow working-set pressure
Memory right-sizing is not about pushing RAM usage toward a target percentage.
Linux uses otherwise idle memory for cache, so high RAM usage can be healthy. Better signals are MemAvailable, swap behavior, memory PSI, OOM events, service restarts, and workload latency.
Raff's General Purpose ladder allows memory changes without always adding CPU. Current examples include:
- 2 vCPU / 2 GB / 40 GB — $12.99/month;
- 2 vCPU / 4 GB / 80 GB — $17.99/month;
- 2 vCPU / 8 GB / 160 GB — $27.99/month.
That makes a memory-first resize easier to isolate. If CPU is comfortable but memory pressure is real, increasing RAM can be more efficient than doubling both resources.
For higher memory ratios, see High Memory VMs.
Storage right-sizing includes capacity, growth, and architecture
Storage right-sizing is partly a capacity problem and partly an architecture decision.
Track database growth, uploads, logs, container images, build artifacts, temporary files, and backup staging. A disk that is comfortable today can become the next outage if growth is unbounded.
Do not solve every storage problem by buying a larger VM. If durable application or database data needs a separate lifecycle, Raff Volumes are currently $0.08/GB-month. Separating data from the VM can also make compute resizing cleaner when storage needs grow independently.
Use Raff Volumes and the live pricing page for current storage costs.
Right-size non-production environments separately
Production, staging, development, test, preview, and demo environments rarely need identical capacity.
A common source of cloud spend drift is cloning production-sized infrastructure into environments with much lower demand and then leaving it running indefinitely.
For each environment, record:
- owner;
- purpose;
- required availability window;
- expected workload;
- expiration or review date;
- minimum safe resource size.
Downsizing a staging VM can be sensible when it still reproduces the behavior needed for testing. It is not sensible when the environment must accurately load-test production capacity. Right-sizing should preserve the purpose of the environment.
Billing terms are part of cloud cost optimization
Right-sizing reduces the amount of infrastructure you buy. Billing-term selection determines how you pay for infrastructure that is already correctly sized.
Raff supports pay-as-you-go VM billing. Check the live pricing page for current billing terms. Use shorter commitments when the workload or resource requirement is still uncertain. Longer terms make more sense when the workload and VM shape have become stable enough to justify commitment.
Do not use a long billing term as a substitute for right-sizing. A discounted oversized VM can still waste more money than a correctly sized smaller VM.
Raff VM traffic currently uses a 3 Gbps public connection with unmetered VM traffic and no VM egress fee. Public IPs and other add-ons are priced separately, so evaluate the complete live resource cost rather than assuming every component is bundled with the VM.
Review right-sizing on a schedule, not continuously
Teams do not need to resize VMs every time a graph changes.
A practical review cadence is:
- review new production workloads after enough representative traffic exists;
- review after major releases or traffic changes;
- review environments created for temporary work when their purpose ends;
- review persistent low-utilization resources during regular cost checks;
- re-check after each material resize to verify the workload outcome.
The goal is controlled adjustment, not constant infrastructure churn.
Cloud right-sizing balances cost and reliability
Right-sizing in cloud computing is successful when it removes waste and keeps the workload inside its required performance and reliability envelope.
Start with measured behavior. Separate CPU, memory, storage, and architecture decisions. Downsize when capacity is persistently unused without a clear reason. Upsize when repeatable resource pressure damages latency, throughput, queueing, stability, or maintenance safety. Change machine class when allocation behavior matters more than raw capacity.
For pre-deployment sizing, continue with the VM Sizing Guide. For current Raff VM shapes and prices, compare Raff General Purpose VM Plans or Raff Cloud Servers.
Sources
