Compute, storage, network and capacity evidence
Capacity planning must reflect the actual workload and failure requirements. A nominal CPU count or an old published density figure cannot establish how many users a new image will support. Applications, background tasks, profile activity, graphics, storage latency, network conditions and user concurrency all matter. Build a representative test and record how the environment behaves at normal demand, peak demand and the agreed failure condition.
Define the workload
Distinguish single-session and multi-session designs, application mix, concurrency and the pattern of arrivals. A morning launch burst can stress boot, authentication, brokering, storage and profile services differently from steady-state sessions. Pre-started capacity may reduce waiting, but it carries resource and cost implications. Test the selected scheduling or autoscale approach rather than assuming a powered-off machine becomes ready instantly when demand appears.
Size for the failure case
Suppose a hypothetical pool must support nine hundred simultaneous sessions. Testing establishes a conservative usable capacity of one hundred and eighty sessions per host under the required experience target. Five hosts cover normal capacity exactly. If one host must be lost without exceeding that tested limit, six hosts are needed for this simplified compute calculation. The result still does not establish storage, licensing, Controller, network or application-service capacity. Document the limits and assumptions rather than labelling one arithmetic result a complete resilient design.
Follow I/O and data paths
MCS image and write activity, Provisioning streaming/cache activity and profile storage create different demands. Observe latency as well as throughput and IOPS, and consider boot storms, cache growth, maintenance and recovery. For network design, verify supported connectivity, bandwidth, path MTU and security controls. Jumbo frames or a dedicated VLAN are not universal substitutes for measuring the actual path and dependencies. Graphics and media workloads require compatible host, driver, VDA and endpoint capabilities, with appropriate licensing and support verification.
Compare performance and cost
Cloud VM and disk choices, power schedules and committed-capacity arrangements influence both service and cost. A cheaper instance is not economical if it fails the agreed workload; a larger instance is not automatically necessary for every user segment. Measure cost over the expected use pattern and retain sufficient recovery and startup capacity. Spread critical components across genuinely independent fault domains and verify shared storage, identity or network dependencies that might defeat apparent redundancy. Repeat the assessment after major image or application changes.