Moving desktops from your own data centre to Azure changes what you pay for. On premises, a server that sits idle overnight costs the same as one that is busy. In Azure, a virtual machine that is allocated to a host is billed, and one that is deallocated is not, apart from its disks and networking. The bill for a Citrix DaaS estate on Azure is therefore mostly a question of how many machine-hours you leave switched on.
Autoscale is the Citrix DaaS feature that manages those hours. It is included in the service and works on every platform DaaS supports, but it only saves money when it is configured against your real usage pattern. This checklist sets out the settings we review on a DaaS-on-Azure deployment, in the order we check them.
1. Know what Azure charges for
Microsoft's documentation is clear on the two states that matter. A VM that is "Stopped" is still allocated to a host and still billed for compute. A VM that is "Stopped (deallocated)" or "Hibernated (deallocated)" has released its hardware and is not billed for compute, though managed disks and networking continue to incur charges.
Two consequences follow. Shutting a VM down from inside Windows is not enough; it has to be deallocated, which is what Citrix power management does. And storage is a standing cost that Autoscale alone does not touch, which is why the provisioning model in point 6 matters.
2. Build the schedule from measured demand
Autoscale schedules set how many machines are powered on in each 30-minute slot, with different schedules for different days. The temptation is to copy a working week: on at 07:00, off at 18:00. Measured logon data usually shows a steep morning ramp, a long shoulder of a few late users, and a different shape on Fridays and at month-end.
Pull session counts by half-hour from Citrix Monitor for at least a month before you set the schedule, and look at single-session and multi-session delivery groups separately, because their Autoscale settings differ. The schedule is the baseline; the settings below handle the variance around it.
3. Set the capacity buffer separately for peak and off-peak
The capacity buffer is spare capacity kept powered on above current demand, so that a user who logs on does not wait for a VM to boot. For single-session groups it is a percentage of the machines in the group; for multi-session groups it is a percentage of total capacity measured in load index. It is calculated from current usage, so it rolls with demand rather than sitting on top of the whole pool.
The buffer has a peak value and an off-peak value, and a common mistake is to leave the same figure in both. Peak needs headroom for the morning ramp; off-peak, with a handful of users connected, a large percentage buys almost nothing.
4. Use vertical load balancing for multi-session groups
Citrix DaaS load-balances horizontally by default: a new session goes to the least-loaded machine, which spreads users thinly across every VDA that is on. Vertical load balancing does the opposite. New sessions go to the machines with the highest load index until a watermark is reached, so fewer machines fill up and the rest drain and power off.
Citrix's documentation notes that vertical load balancing can reduce cost by lowering the number of VDAs that must stay powered on. It is set at site level under Load Balancing Sessions on Machines in Studio, or with Set-BrokerSite -UseVerticalScalingForRdsLaunches, and a delivery group can override it. Pair it with a sensible Maximum number of sessions policy so density does not come at the expense of experience.
5. Tune the power-off rules
Autoscale does not power off a busy machine. When capacity exceeds demand, it puts the surplus machines with the fewest sessions into drain state, and powers each off once it has no sessions and has passed the power-off delay. The delay is the minimum time a machine stays on after powering up: 30 minutes by default, configurable from 0 to 60. A shorter delay saves money on volatile workloads; a longer one stops a machine being booted and shut down repeatedly around the same threshold.
Drain only empties a machine if sessions end. Review the Disconnected session timer and Session idle timer policies, because a disconnected session left for hours holds its machine on. For pooled desktops, Set-BrokerDesktopGroup -ShutdownDesktopsAfterUse $true shuts the VM down at logoff.
6. Choose the provisioning model with storage in mind
Machine Creation Services on Azure provisions on demand: the VM is created when Citrix DaaS issues a power-on, not when the catalogue is built. For pooled, non-persistent machines the OS disk and write-back cache exist only while the VM exists, so shutting the machine down removes it from Azure and stops the disk charge too. Dedicated machines keep their OS disk until the machine identity is deleted. Citrix has deprecated the older Azure catalogue type that created every VM up front and recommends recreating such catalogues.
Hibernation is the other Azure-specific option. For single-session catalogues on a hibernation-capable VM size and machine profile, Autoscale can suspend machines instead of shutting them down, and resume them for the user or during peak. Resume is faster than a cold boot and a hibernated VM is not billed for compute. The limits: single-session only, no ephemeral OS disks or MCS I/O, and every VM in the group must be hibernation-capable before the load-based action can be set to Suspend.
7. Prove the saving
Each delivery group carries a machine instance cost per hour in US dollars, and Monitor reports the estimated saving under Cost Optimization. Enter a realistic figure for your VM size and review the Cost savings and capacity utilisation views monthly. Autoscale that is never measured is usually left at defaults.
Where this sits in a wider Azure design
Autoscale controls run-time; it does not choose the region, the VM family or the commitment model. Those decisions belong in the architecture, as our page on Citrix on Azure South Africa sets out, and in the platform choice covered by our comparisons of Azure Virtual Desktop and Citrix DaaS and Citrix DaaS Flex on Azure. We include an Autoscale review in every Citrix DaaS assessment, because it is the fastest way to make a sound deployment an affordable one.
Sources
- Citrix DaaS documentation: Autoscale, accessed 26 October 2026.
- Citrix DaaS documentation: Get started with Autoscale, accessed 26 October 2026.
- Citrix DaaS documentation: Load balance machines, accessed 26 October 2026.
- Citrix DaaS documentation: Power manage Azure VMs, accessed 26 October 2026.
- Microsoft Learn: States and billing status of Azure Virtual Machines, accessed 26 October 2026.
Have your Autoscale configuration reviewed as part of a Citrix DaaS assessment from OAS.