VM Resource Calculator

VM resource calculator: a defensible starting size for vCPU, RAM and storage

Pick the workload, say how many concurrent users it has to carry, add a growth buffer, and the calculator returns a vCPU count, a RAM figure, a storage figure, an estimated IOPS requirement, a network bandwidth class, a matching instance size and a rough monthly cost across AWS, Azure and GCP. It is a first-pass sizing tool for one virtual machine, and it is honest about being that. It exists to replace the guess you would otherwise write into a ticket, not to replace the monitoring data you will have in a month.

Everything is computed in the browser from a fixed set of workload profiles. There is no API call, no account, no data leaving the page, and the Copy button puts the whole configuration on your clipboard as text you can paste into a change request.

The formula it actually uses

Each of the eight workload profiles carries a baseline — the resources the service needs with nobody using it — plus a per-user coefficient. The calculation is deliberately simple and worth knowing, because it tells you exactly where the tool's judgement ends and yours begins:

• vCPU = ceil((base CPU + per-user CPU × users) × (1 + buffer/100))
• RAM = ceil((base RAM + per-user RAM × users) × (1 + buffer/100))
• Storage = ceil((base storage + per-user storage × users) × (1 + buffer/100))
• IOPS = ceil(100 × workload multiplier × (1 + users/100))

The raw results are then snapped upward to shapes you can actually buy: vCPU to 2, 4, 8, 16, 32 and then multiples of 8; RAM to 4, 8, 16, 32, 64, 128 and then multiples of 32; storage to 50, 100, 200, 500, 1000 GB and then multiples of 500. That rounding is why nudging the user count by ten often changes nothing — you are inside the same bucket.

The eight workload profiles

The spread across that per-user column is the useful part. A web server costs 0.01 vCPU per concurrent user; a terminal server costs 0.5 — fifty times as much — because every session is a desktop with a browser in it. The development profile has zero per-user coefficients on purpose: it is one workstation, and the user count does not change its size (it does still affect the IOPS estimate).

Two worked examples

Web server, 100 concurrent users, 25% buffer. vCPU: (2 + 0.01 × 100) × 1.25 = 3.75, rounded up to 4, snapped to the 4 bucket. RAM: (4 + 0.05 × 100) × 1.25 = 11.25, rounded up to 12, snapped to 16 GB. Storage: (50 + 0.1 × 100) × 1.25 = 75, snapped to 100 GB. IOPS: 100 × 1 × (1 + 100/100) = 200. The tool labels this Medium (t3.large / B4ms) and quotes roughly $169–196 a month on AWS.

Terminal server, 50 concurrent users, 25% buffer. vCPU: (4 + 0.5 × 50) × 1.25 = 36.25, rounded up to 37, and since that is past 32 it snaps to the next multiple of 8 — 40 vCPU. RAM: (8 + 2 × 50) × 1.25 = 135, past 128 so snapped to the next multiple of 32 — 160 GB. Storage: (100 + 5 × 50) × 1.25 = 437.5, rounded to 438, snapped to 500 GB.

That second result is the more instructive one, and not because the number is right. A 40 vCPU, 160 GB machine is not a VM you casually provision — it is most of a host. The correct reading is that 50 concurrent RDS sessions is a capacity-planning problem, and the answer is probably two or three smaller session hosts behind a broker rather than one enormous VM. The calculator will happily print the single-VM answer; deciding it is the wrong shape is your job.

What the growth buffer is for

The buffer is a straight percentage multiplier applied before rounding, adjustable from 0 to 100%, defaulting to 25%. It is not headroom for peak load — it is headroom for the next year of the service getting bigger. Two notes on using it well:

• Because rounding happens after the buffer, a buffer change often produces no change at all. If 20% and 40% both land in the same bucket, take the bucket.
• In a cloud environment where resizing is a reboot, a large buffer is money spent on capacity you do not yet need. On-premises, where the next chassis is a purchase order and a lead time, the same buffer is cheap insurance. The right number depends on how hard it is for you to change your mind later.

What the High Availability toggle does — and does not do

This is the most commonly misread control on the page, so it is worth stating plainly. Turning HA on does not change the vCPU, RAM or storage figures. That is deliberate: the recommendation is per node, and both nodes are identical. What HA changes is the cost estimate, which doubles, and the note that appears telling you to deploy two VMs with these specs across availability zones.

Two identical nodes is an active/active or active/passive pair, not a general N+1 capacity model. If you are sizing a cluster where the surviving hosts must absorb a failed host's workload, the tool does not compute that for you — N+1 means every host must run at a utilisation low enough that (N − 1) hosts can carry the whole load, so a four-host cluster should sit around 75% of its total capacity at most. Work out the per-VM size here, then do the host-count arithmetic separately.

Overcommit, ballooning and the hypervisor's own reserve

The figures this tool returns are what to allocate to one guest. Packing guests onto a host is a different problem that it does not model, and the difference matters most for two resources:

• vCPU overcommit is usually fine. CPU is time-sliced, and most VMs are idle most of the time. Ratios in the low single digits of vCPU to physical core are routine for general workloads. It stops being fine when the guests are busy simultaneously — the symptom is CPU ready time, not high guest CPU usage, and it is invisible from inside the VM.
• Memory overcommit is where clusters die. RAM is not time-sliced; if guests genuinely touch what they were promised, something has to give. Ballooning asks a cooperative guest driver to hand pages back, transparent page sharing dedupes identical pages, compression buys a little more, and swapping to disk is the last resort and a performance cliff. Ballooning works when guests are over-provisioned relative to their real working set, which is common — but it is a reclamation mechanism, not free memory, and a database that has claimed a large buffer pool will not give it back gracefully.
• The hypervisor needs its own reserve. The host operating system, the management agents and the per-VM overhead all consume RAM and cycles that are not available to guests. Never plan guest allocations up to 100% of physical memory.

Reading the cost estimate correctly

The monthly figures come from a flat internal model: roughly $30 per vCPU, $3 per GB of RAM and $0.10 per GB of storage per month, doubled when HA is on, then presented as three provider ranges around that total. It is a scale check — is this a $200 machine or a $2,000 machine — and nothing more. It does not know about your region, your reserved-instance or savings-plan commitments, your negotiated discount, egress, IOPS charges on provisioned volumes, licensing, or the specific instance family you would actually pick. Price the real SKU with the provider's own calculator before anyone signs anything.

The instance-type label is a similar approximation: it maps the vCPU and RAM pair onto a rough size band with example AWS and Azure names attached. Treat it as a search term, not a purchase order.

How to use the output well

• Start with the profile whose shape matches your workload, not the one whose name matches. A Redis cache is closer to the database profile than the application profile.
• If your real bottleneck is disk, take the IOPS figure as a hint and then check it against the storage tier you are buying — a burstable volume that meets a sustained IOPS number on paper may not meet it at your queue depth.
• The network class is derived only from the profile's intensity and the user count: high-intensity workloads above 500 users get 10 Gbps, high intensity or over 200 users gets 2–5 Gbps, everything else gets 1 Gbps. It is a class, not a measurement.
• Size once, then right-size on evidence. Two to four weeks of production metrics will beat any formula on this page, including the ones you liked.

Used as a starting point that someone else can check — because the coefficients are written down and the arithmetic is reproducible — it does the job. Used as a final answer, it will oversize your small services and undersize your interesting ones.