A cloud server is sold as a bundle of vCPU, RAM and disk. The temptation is to pick a middle option and hope. The better approach is to work out which of the three your workload exhausts first, size that one properly, and treat the rest as consequences.
RAM is usually the one that bites
Running out of CPU makes things slow. Running out of RAM makes things stop. When a Linux server exhausts memory, the kernel starts killing processes — often the database, because it is the largest one. That is why memory is the resource to be least clever about.
Rough starting points: a small static or brochure site is comfortable on 2 GB. A CMS such as WordPress with a database on the same server wants 2–4 GB once caching and a PHP process pool are in play. An application server with a database, a cache and a background worker is more realistic at 8 GB.
The reliable method is to measure rather than estimate. On an existing server, free -m during a busy period tells you the truth, and the number you care about is available memory, not used — Linux deliberately uses spare RAM for disk cache and gives it back on demand.
vCPU: how many things happen at once
A vCPU is a unit of processing capacity assigned to your virtual machine. More vCPUs mean more work happening simultaneously, not each individual request being faster.
This matters because most web workloads are bursty and concurrent rather than sustained. Two vCPUs handle a surprising amount of traffic if requests are short. A single long-running task — video encoding, a large import, a build — will occupy a whole core for its duration and block others.
The other decision is shared CPU versus dedicated CPU. A shared CPU plan draws on physical processor capacity used by several virtual machines. It is well suited to websites, development environments and anything with variable load. A dedicated CPU reserves capacity for you, which is what you want for a database under continuous load, or any workload where consistent response time matters more than cost.
Disk: size for data, but watch the type
Disk capacity is easy to reason about — add up what you store and leave headroom. Two details are less obvious.
First, storage type matters more than capacity for databases. NVMe SSD storage delivers far lower latency than older disk types, and database performance is dominated by how quickly small random reads and writes complete.
Second, data that matters should usually not live only on the boot disk. Attaching a volume keeps application data separate from the operating system, so you can rebuild, resize or replace the server without moving the data with it.
Architecture: x86 or ARM
Server CPUs come in two mainstream architectures. x86-64 is the traditional one and runs essentially everything. ARM servers often provide more performance per unit of cost and use less power.
The catch is compatibility. Interpreted and JIT languages generally run fine, and most popular software publishes ARM builds. Anything with compiled binaries or niche dependencies needs checking first. If you are not sure, x86-64 is the choice that never surprises you.
Start smaller than you think
The advantage of cloud infrastructure over buying hardware is that sizing is a decision you can revisit. Vertical scaling — giving one server more resources — takes a reboot. Horizontal scaling — adding servers behind a load balancer — takes longer to design but stops one machine being the ceiling.
Because both paths stay open, the sensible move is to start one size below your guess, measure real usage for a week, and adjust. Guessing high costs money every month; guessing low costs you one resize.
Before you deploy
Two settings are worth thinking about at creation time, because changing them later is more disruptive. Backups are far easier to enable at the start than to retrofit after an incident. And the region you deploy into determines latency for your users and where your data physically sits — which may matter for reasons that are legal rather than technical.