How to Size vCPU and Memory Without Guessing

Most cloud instances are sized the way the first one was sized: somebody picked a plausible option at the start and nobody revisited it. Half are too large, the other half are quietly throttled.

Measuring is not difficult. It just requires knowing what to measure.

What a vCPU actually is

A vCPU is usually a hardware thread, not a core. On a typical x86 host with simultaneous multithreading, one physical core presents two threads, so two vCPUs are frequently one core's worth of silicon sharing execution units.

The exceptions matter:

• Oracle Cloud bills in OCPUs, where one OCPU on an x86 shape is a full core with two threads — roughly two vCPUs elsewhere. Comparing OCI prices without normalising makes it look twice as expensive as it is.
• Arm-based instances (Ampere, Graviton) typically map one vCPU to one physical core with no sharing, which is part of why their per-vCPU performance is often better than the price suggests.

This is why a like-for-like comparison across providers has to start with what the unit means, not with the number.

Shared, burstable and dedicated

Burstable instances — AWS T-series, Azure B-series, and the shared tiers on most VPS providers — accrue credits while idle and spend them while busy. When credits run out, performance drops to the baseline, which can be as little as 10–20% of a full vCPU.

The failure mode is distinctive: the application is fine for hours, then becomes uniformly slow and stays that way. If that pattern sounds familiar, check the CPU credit balance metric before changing anything else.

The rule is simple. Bursty load, burstable instance. Sustained load, dedicated instance. Getting this wrong in either direction costs money — one in wasted spend, the other in unexplained slowness.

Measuring CPU properly

Average utilisation is close to useless on its own. What you need:

• p95 and p99 utilisation, not the mean. A 20% average with regular 100% spikes is a saturated system.
• Run queue length — load average relative to core count. A load average consistently above the vCPU count means processes are waiting.
• I/O wait — if %wa is high while %us is low, the disk is the constraint and more CPU will change nothing.
• Steal time — %st above a few percent on a shared instance means the hypervisor is giving your cycles elsewhere.

That last one is the giveaway for an over-subscribed shared instance. Persistent steal time is a reason to move to a dedicated plan, not to add cores.

Measuring memory properly

Linux memory reporting misleads almost everyone. free -m shows most memory "used" because the kernel caches aggressively — and that cache is a benefit, not a problem.

Look instead at:

• Available memory (the available column), which accounts for reclaimable cache.
• Swap activity — si/so in vmstat. Any sustained swapping means you are genuinely short.
• OOM killer events in the system log. Even one is a sizing failure.
• Application-level metrics — JVM heap, PHP-FPM worker count, connection pool sizes. These frequently cap throughput long before the machine runs out of RAM.

A machine at 90% memory with zero swap activity is working correctly. A machine at 60% memory that swaps under load has an allocation problem, not a capacity problem.

A practical sizing method

1. Start from a measured baseline. If migrating, measure the existing system for a full business cycle — a week usually captures the pattern.
2. Size for p95, not peak. Sizing for the annual maximum means paying for it all year.
3. Add headroom deliberately — 20–30% is reasonable for most services.
4. Match the ratio to the workload. Web and application tiers suit balanced ratios; databases and caches want memory-heavy; build and encoding want CPU-heavy.
5. Run for two weeks, then revisit. The first size is a hypothesis.
6. Scale out before scaling up where the workload is stateless — several smaller instances behind a load balancer fail more gracefully than one large one.

Providers such as Kamatera and UpCloud allow independent CPU and memory selection, which is genuinely useful when your ratio is lopsided and you do not want to buy a bundle shaped for someone else.

Common mistakes

• Sizing by price tier rather than by requirement.
• Ignoring the disk. A throttled volume looks exactly like a CPU problem from the application's perspective.
• Forgetting the database connection limit, which frequently caps concurrency well before CPU does.
• Sizing production like development, or the reverse.
• Never revisiting. Load changes; the instance does not size itself.

Frequently asked questions

Is more vCPU always faster? Only if the workload is parallel. Single-threaded work benefits from higher clock speed, not more cores — which is why high-frequency instance types exist.

How do I compare providers fairly? Normalise the unit first (OCPU versus vCPU, core versus thread), then benchmark your actual workload rather than a synthetic test.

Should I use autoscaling instead of sizing? Autoscaling handles variation. It does not replace sizing the individual instance correctly, and scaling badly sized instances just multiplies the error.

How much headroom is right? 20–30% for most services. More for workloads with sharp unpredictable spikes; less for batch work that can queue.

The database guide covers sizing for the stateful tier specifically.