The Rule of 5 and 10: A Quick Way to Size CVAD Infrastructure

When IT teams plan a virtual apps and desktops deployment, one question arises immediately: how many users or virtual machines can a single physical server support? This concept, called single-server scalability (SSS) or user density, can be modeled with expensive load-testing tools and long validation cycles. But there is a faster way to get a useful first estimate: the Rule of 5 and 10.

What is the Rule of 5 and 10?

The Rule of 5 and 10 is a back-of-the-napkin formula popularized by Citrix for estimating SSS. The math is simple: take the number of physical CPU cores in a server and multiply it by 5 or 10.

Use the multiplier of 5 to estimate how many virtual desktop VMs (full Windows desktops, one per user) a host can support. Use 10 to estimate how many session-based virtual apps users can run on the same hardware. The difference reflects the fact that shared session hosts pack more users onto the same cores than dedicated desktop VMs do.

A few examples show how clear this is in practice. A server with 36 physical cores running virtual desktops yields 5 × 36 = 180 VMs per host. An older 24-core box running session-based apps gives 10 × 24 = 240 users per host. A newer 32-core server running apps produces 10 × 32 = 320 users per host. Scaling up to a 48-core host (a dual-socket 2×24 configuration), the same arithmetic holds: virtual desktops give 5 × 48 = 240 VMs per host, while session-based apps give 10 × 48 = 480 users per host. The apps figure is double because shared session hosts pack more users onto the same cores.

Why It Works

The rule rests on a single, hard-won observation: these workloads are CPU-bound about 99.9% of the time. The bottleneck limiting density is the number of physical cores, not memory, disk, or network. Years of field deployments taught Citrix that while clock speed, hyper-threading, logon storms, and NUMA architecture matter, nothing predicts density as reliably as raw core count. By ignoring other variables on the first pass, sizing teams avoid analysis paralysis and get a defensible number in seconds.

That said, the rule is a starting point. There is only one way to know the true SSS for a specific workload: validate it with a load-testing tool like Login VSI before committing budget to hardware. Factors like workload weight (a data-entry “light” user versus a 3D-modeling “heavy” user), activity ratio (real users are often idle 40–60% of the time), and CPU over-subscription (a 2:1 ratio is often optimal) all affect the final figure. The Rule of 5 and 10 gets you in the ballpark; testing gets you the seat number.

Where the Model Breaks Down: The Hyperscaler Problem

The Rule of 5 and 10 was built for a world where you buy and own the physical server, where you can count the cores and reason about NUMA nodes, sockets, and over-subscription. That assumption collapses when you move the same workload to a hyperscaler like AWS, Azure, or Google Cloud.

The first problem is visibility. In the cloud, you rent vCPUs, not physical cores. A “core” you provision is usually a single hyper-thread on a shared physical core, abstracted behind the provider’s scheduler. The multiplier in the rule was calibrated against physical cores, so applying it to vCPUs double-counts the hyper-threading benefit the rule was designed to exclude. The estimate inflates, and density projections become unreliable.

The second problem is control. On-premises, you tune the CPU over-subscription ratio and pin VMs to avoid crossing NUMA boundaries. On a hyperscaler, the provider owns the hypervisor, scheduler, and over-subscription policy. You cannot guarantee your instances aren’t sharing physical silicon with noisy neighbors, which introduces performance variability the rule never accounts for.

Finally, the economics invert the exercise. The rule answers the question, “How much hardware should I buy?” In the cloud, you don’t buy hardware — you scale instances elastically and pay by the hour. The right question becomes cost per user and right-sizing instance families, not packing maximum density into a fixed box. Optimizing for density can raise your bill if a smaller, more numerous instance type serves users more cheaply.

The Rule of 5 and 10 remains an excellent mental model for owned infrastructure. But in a hyperscaler environment, where physical cores are invisible, scheduling is out of your hands, and elasticity replaces capital purchasing, the model’s core assumption — count the cores, multiply, done — simply no longer holds.