Size VMs for a user target: vCPUs, memory, storage, instance count and real N+1 redundancy, with AWS, Azure and GCP picks that actually fit.
Multi-session figures as published by Microsoft, plus 30 GB of profile-container storage per user. The same guidance keeps a host between 4 and 24 vCPUs.
| Workload class | Max users / vCPU | Min vCPUs | Min RAM |
|---|---|---|---|
| LightPublished | 6 | 8 | 16 GB |
| MediumPublished | 4 | 8 | 16 GB |
| HeavyPublished | 2 | 8 | 16 GB |
| PowerPublished | 1 | 6 | 56 GB |
A sizing estimate, not a guarantee. Instance specifications are published by each provider and change over time; prices are deliberately not shown, because an undated price is worse than none. Validate with a load test before committing hardware.
You might also find these calculators useful
Work out the vCPUs, memory, storage and bandwidth a target number of users needs, then how many instances to run and which catalogue sizes actually fit. Web-application sizing runs on throughput you measure; session-host sizing runs on the users-per-vCPU figures Microsoft publishes. This page and the server capacity calculator share one model, so a machine provisioned here is rated for at least the users you asked for there.
Sizing is the inverse of capacity: instead of asking what a machine holds, you fix the number of users and solve for the machine. Three things decide whether the answer is usable. Cores do not scale linearly, so four times the load needs more than four times the cores. A machine has a sensible upper size, past which the published guidance is to add hosts rather than grow one. And redundancy means the survivors carry the whole load, so N+1 adds an instance rather than dividing the requirement among the ones you already had.
Sizing formula
Turn a user target into a concrete instance size and count you can put into a ticket or a Terraform file.
See exactly how much capacity survives one instance failing, and whether that clears the requirement.
Apply the published maximum users per vCPU for light, medium, heavy and power workloads, and get a host count inside the published vCPU band.
See which AWS, Azure or Google Cloud sizes meet the same requirement, on published specifications rather than an undated price.
A size is only offered if it meets the per-instance requirement. When nothing in a catalogue is large enough, the page says so rather than quietly handing back its biggest row.
N+1 deploys a spare on top of what the load needs, and the page states the capacity that survives one failure against the requirement, so you can check it rather than trust a label.
Concurrent users drive CPU, memory and network; registered accounts drive stored data. They are different numbers, usually by orders of magnitude, so they are different fields.
Both pages solve the same expressions, one forwards and one backwards. Agreement is asserted in the test suite rather than checked by hand.
It converts your steady-state concurrent users into the peak the machine must absorb. A multiplier of 2 sizes for twice the usual concurrency. It applies to CPU, memory and network, which scale with who is online, and deliberately not to storage, which scales with how many accounts exist.
It is the share of capacity you want the peak load to occupy in steady state. At 70 per cent, the machine is sized so peak sits at 70 per cent of what it can do, leaving the rest for bursts. This is why the server capacity calculator rates the resulting machine at roughly 1.4 times the users you asked for here: that is the headroom, not a disagreement.
Whenever losing one instance must not degrade service. N+1 deploys one more instance than the load needs, so the survivors still carry everything. Note what it is not: splitting the same requirement across two half-sized instances is not redundancy, because a failure then costs you half your capacity.
Cloud prices vary by region, commitment, storage and egress, and change without notice. A hardcoded range with no date, region or source is a number that looks authoritative and is not, so it was removed rather than refreshed. The instance specifications are published by each provider and are what this page compares.
Because neither fits this model honestly. Training is usually GPU-bound, and CI/CD sizing is about concurrent builds rather than concurrent users, so a users-per-core figure describes neither. Shipping an invented profile for them is what produced the old answer of 28,583 vCPUs paired with an 8-vCPU recommendation.
General-purpose families from each provider: t3 and m5 on AWS, B and Dsv5 on Azure, e2 and n2-standard on Google Cloud, plus generic vCPU and memory pairings. Only rows that meet the per-instance requirement are shown, and the next size up is listed alongside so you can see what the headroom costs.