How to Size a Cloud Server Without Guessing

Work out which resource binds first

Every workload runs out of one thing before the others. Identify it and size around it.

A database whose working set no longer fits in memory does not degrade gradually. It falls off a cliff, because every query starts touching disk. That is the most common sizing surprise there is.

Memory: the number that matters most

Add up what actually runs:

• Operating system and base services — roughly 300 to 500 MB.
• Web server — 50 to 200 MB, plus per-worker memory.
• Application runtime — measure one process under load and multiply by worker count.
• Database — the buffer pool or shared buffers you have configured, plus per-connection overhead.
• Cache — whatever you gave Redis or Memcached, plus headroom.
• Headroom — at least 20 per cent, so a traffic spike does not trigger the out-of-memory killer.

Then add swap. Not as a substitute for RAM, but so a temporary spike degrades into slowness rather than a killed process. One to two gigabytes is enough on most servers.

CPU: count concurrency, not requests

A useful starting estimate: concurrent requests equals requests per second multiplied by average response time in seconds. Two hundred requests per second at 200 ms is forty concurrent requests.

For CPU-bound work, cores needed is roughly concurrency multiplied by the fraction of time spent on CPU. If most of that 200 ms is waiting on a database, one or two cores handle it comfortably. If it is all computation, you need considerably more.

Measure it rather than assuming: run one worker, load it, and read the CPU time per request.

Disk: size and speed are separate decisions

• Capacity — application, dependencies, logs, database, and room for growth. Logs are the usual cause of a full disk; set up rotation on day one.
• IOPS — how many operations per second the volume sustains. Databases care; static file serving mostly does not.
• Throughput — megabytes per second, which matters for backups, large uploads and analytics scans.

On several providers IOPS scales with volume size, so a small volume can be slow regardless of the instance type. On others, local NVMe is much faster but tied to the instance lifecycle. Check which model applies before assuming disk speed.

Bandwidth is a billing decision

VPS providers such as Hetzner, DigitalOcean, Linode and UpCloud include a generous transfer allowance in the plan price. Hyperscalers bill egress per gigabyte from the first gigabyte in most regions.

For a media-heavy site, the difference between the two models is often larger than the difference in compute price. Estimate monthly egress before choosing, and see hyperscaler versus VPS provider for how those models compare.

The habit: start small and resize

1. Deploy on a plan you believe is slightly too small.
2. Run under real traffic for a week with monitoring in place.
3. Read peak memory, peak CPU, disk usage and egress — not averages, peaks.
4. If peak memory exceeds 80 per cent or CPU sits above 70 per cent, move up one size.
5. If peaks stay below 30 per cent for a month, move down one size.
6. Repeat quarterly, or after any significant traffic change.

Resizing a cloud server takes a reboot on most providers. That is a far smaller cost than a year of paying for four times what you need.

Common questions

Where to go next

See shared versus dedicated vCPU and monitoring a cloud server, which supplies the numbers this method needs.