VM Size Calculator

• Requests per second (RPS): If Direct RPS is empty,
  RPS = (Users × RequestsPerMinutePerUser) ÷ 60
• CPU cores at 100%:
  Cores100 = RPS × (CpuMsPerRequest ÷ 1000)
• CPU with overhead and utilization target:
  CoresBase = (Cores100 × (1 + CpuOverhead%)) ÷ TargetCpuUtil%
• Base RAM:
  RamBase = BaseAppRamGB + (Users × RamPerUserMB ÷ 1024) + OsOverheadGB
• RAM with utilization target:
  RamUtil = RamBase ÷ TargetRamUtil%
• Headroom and growth multiplier:
  Multiplier = (1 + Headroom%) × (1 + Growth%)
• Per-instance recommendation:
  PerInstance = (Base × Multiplier) ÷ Instances

1. Enter peak load using Direct RPS, or provide Users and per-user request rate.
2. Set CPU ms per request from profiling or APM sampling.
3. Adjust OS overhead and CPU overhead for agents and background tasks.
4. Choose utilization targets; lower values improve stability and latency.
5. Add headroom for bursts and growth margin for upcoming releases.
6. Press Calculate to see sizing and download CSV/PDF reports.

Workload signals that drive CPU sizing

CPU demand is estimated from peak requests per second and average CPU milliseconds per request. For example, 150 RPS at 3 ms consumes 0.45 core at 100% utilization. After overhead and a 65% target, the baseline rises to roughly 0.73 vCPU before headroom and growth are applied.

Memory planning for stability and latency

RAM is calculated using application baseline memory plus per-user allocations, then adjusted for an operating-system buffer. Keeping a 70–80% memory target reduces swapping risk, lowers garbage-collection pressure, and helps caches remain warm. If your app uses in-memory sessions, increase per-user MB to reflect real heap usage.

Headroom and growth as separate levers

Headroom protects performance during bursts, deploy spikes, and noisy-neighbor variance. Growth margin accounts for business expansion, new features, and traffic seasonality. A practical starting point is 20–35% headroom and 15–30% growth for fast-moving products. Mature services can reduce growth but should keep headroom for reliability.

Multi-instance distribution and availability modes

When you scale horizontally, total demand is split across instances, producing a smaller per-instance recommendation. Availability modes influence total planned capacity: N+1 reserves enough capacity to survive a single node failure, while active-active can be modeled conservatively as doubling capacity to absorb failover without degradation.

Storage, IOPS, and network considerations

Storage size impacts retention and log growth, but performance is often limited by IOPS and latency. If targets exceed ~2,000 IOPS, premium tiers are typically appropriate; above ~5,000 IOPS, provisioned performance becomes more predictable. Network throughput requirements above 300 Mbps usually justify higher bandwidth options and careful egress budgeting.

Validate results with measurement and iteration

Treat the recommended VM size as a first-pass baseline, then validate with APM traces, load tests, and system metrics. Monitor CPU steal, memory paging, disk queue depth, and p95 latency during peak. Right-size after one to two release cycles, and keep a repeatable sizing record using the built-in CSV and PDF exports.

1) Should I use Users or Direct RPS?

Use Direct RPS when you have monitoring or load-test data. Use Users when demand is early-stage and you can estimate per-user request rates during peak windows.

2) What CPU ms per request value should I enter?

Start with APM averages from peak traffic. If you lack data, use 2–5 ms for lightweight APIs and 5–15 ms for heavier logic, then calibrate using load tests.

3) Why do you apply utilization targets?

Running at 100% is unstable for most services. Targets like 60–70% CPU and 70–80% RAM preserve latency, handle spikes, and reduce risk from background tasks and contention.

4) What does N+1 change in the output?

N+1 increases total planned capacity to survive one instance failure. It does not increase the recommended per-instance size; it ensures remaining instances can carry the load.

5) How do I size storage beyond GB?

Confirm disk latency and IOPS needs. Databases and log-heavy systems often require higher-performance tiers even with modest GB. Benchmark with real workloads to validate queue depth and p95 latency.

6) Is the recommendation cloud-provider specific?

No. It is provider-agnostic and focuses on capacity math. Map the result to your platform’s instance families, then validate with metrics because vCPU performance differs by generation, region, and throttling policies.