Summary
In this module, you mapped cloud desktop requirements to design decisions that hold up in production.
Key takeaways
- You separate control plane responsibilities (Microsoft-managed brokering and gateway services) from data plane responsibilities (your session hosts, apps, profiles, and networking) so ownership stays clear.
- You use the Azure Virtual Desktop resource model—host pools, session hosts, application groups, and workspaces—to publish either full desktops or RemoteApps with consistent access control.
- You compare Azure Virtual Desktop and Windows 365 by workload pattern, operational ownership, and networking needs so the service choice matches the scenario.
- You select pooled or personal host pools based on whether users share capacity or require dedicated desktops.
- You tune cost and performance with load balancing choices (breadth-first vs. depth-first), realistic session limits, and scaling options such as autoscale scaling plans or Start VM on Connect.
Apply the concepts to your next design task
Use the following checklist when you translate a requirement into an initial architecture:
| Requirement signal | Design decision it drives | Typical outcome |
|---|---|---|
| Users share a standard app set and concurrency stays below total users | Pooled host pool and multi-session where possible | Higher density and lower cost per user |
| Each user needs a persistent, device-like environment | Windows 365 or an Azure Virtual Desktop personal host pool | Dedicated compute per user and predictable performance |
| Only specific applications need publishing | RemoteApp application group | Reduced desktop surface and faster onboarding |
| Demand changes across the day or week | Autoscale scaling plan and session distribution tuning | Capacity stays aligned with peak and quiet periods |
You now have the vocabulary and decision signals to evaluate virtual desktop scenarios and choose a path that matches both the workload and the operating model.