Four Settings That Control Your AVD Spend: Autoscale, Power-On-Connect, Disk Warm-Up and Session Timeouts

By David, 2026-11-03

An Azure Virtual Desktop bill has two lines that grow quietly: compute for every hour a session host is running, and disk for every hour a session host exists, running or not. You can't control the rate Azure charges, but you can control how many of those hours you pay for.

Four Atlas AVD settings each cut a different set of those hours:

1. The Autoscale Engine runs only as many hosts as demand needs, and its Idle Timeout Shutdown deallocates hosts that have been empty for five minutes.
2. Power-On-Connect lets a pool drop to zero running hosts when nobody is connected, and starts one when the first user connects.
3. Smart Disk Tiering with a business-hours warm-up moves switched-off hosts to Standard HDD, then back to their performance disk before people sign in.
4. Session timeouts sign out abandoned sessions, so a disconnected user can't keep a host running all night.

Each one saves money on its own. Together, they cover the gaps the others leave, and that's where most of the savings come from.

The short version: session timeouts empty the hosts, autoscale and Idle Timeout Shutdown switch empty hosts off, Power-On-Connect lets the pool sit at zero overnight, and Smart Disk Tiering moves the switched-off hosts to cheaper disks, with a daily warm-up window so the first logon of the day still lands on SSD.

Where AVD money goes when nobody is using it

A typical office estate is busy for about 50 hours a week: ten hours a day, five days a week. A week has 168 hours. So if hosts run around the clock, about 70% of the compute you pay for serves nobody.

Turning hosts off at night is the obvious fix, and most teams start there. But three smaller leaks keep the bill higher than it should be:

• The warm floor. Pools keep one or two hosts running overnight "just in case", and every one of them bills for 118 off-hours a week.
• The disconnected session. A user closes their laptop at 5 p.m. without signing out. Their session stays on the host as disconnected, so the host isn't empty, and no safe autoscaler will switch it off.
• The switched-off disk. A deallocated VM stops billing for compute, but its Premium SSD OS disk keeps billing at the premium rate for every hour it sits there.

Each setting below closes one of these leaks.

1. The Autoscale Engine: run the hosts demand needs

The Autoscale Engine watches session load in every pooled host pool and starts or stops hosts to match it. You set the floor it keeps, and it does the rest.

What you configure, per pool or once for the whole tenant in the Settings Matrix:

• Capacity targets: how many hosts run 24/7, how many free session slots to keep ready, and how many empty hosts to keep warm. Keep the empty-host count at 0 unless you really want empty hosts billing.
• Load balancing: Depth-First fills one host before using the next, which keeps fewer hosts running. Breadth-First spreads users out.
• Time-of-day schedules: raise the floor for the morning login rush, Monday to Friday 08:00 to 09:30 for example, then let it fall back. Autoscale still adds hosts above a schedule's minimum when demand needs them.
• Concurrency limits: how many hosts start or stop at once, so a large scale-out stays inside Azure's rate limits.

Idle Timeout Shutdown runs inside the engine. When a running host has had no sessions, active or disconnected, for five minutes, it becomes a stop candidate. Atlas drains it, checks its live session count with Azure one more time, and deallocates it only if it's still empty and the pool still meets its floors. It never ends a user's session.

Hosts you've prepaid. If a host is covered by an Azure Reserved Instance, stopping it saves nothing. Mark it always on in the pool's Always-on hosts card, so autoscale keeps it running and leaves the savings to the hosts you pay for by the hour. Reserved Instances vs Savings Plans on AVD covers how to size that baseline.

The Scaling Configuration guide walks through every field.

2. Power-On-Connect: let the pool drop to zero

Even a well-tuned autoscale floor keeps at least one host running overnight. For a small pool that one host can be a large share of the bill. Power-On-Connect removes it.

Optimize for Power-On-Connect is a preset in the pool's autoscale settings. It sets hosts running 24/7, minimum free sessions and empty warm hosts to 0, sets concurrent starts to 1 and switches the pool to Depth-First. An AUTO CONFIG ACTIVE badge shows while it's on, and turning it off restores the values you had before.

With nothing running, Azure's Start VM on Connect does the waking: when a user connects to a pool with no running host, Azure starts one for them. Turn that on with the pool's Power on Connect switch under Settings → Compute & Deployment → Deployment Defaults. Always turn both on together; a pool scaled to zero without Start VM on Connect turns new connections away.

The trade-off is the first logon. The first user to connect waits while a host boots. For a pool that's busy all day, schedule a small floor for working hours and let Power-On-Connect handle evenings and weekends. For a pool that's used a few times a week, such as a finance desktop at month end or a contractor pool, running at zero all the time is usually the right call.

3. Smart Disk Tiering and the daily warm-up window

Once hosts spend most of the week switched off, the disk line becomes the next target. A deallocated host's Premium SSD keeps billing at the premium rate, so a pool that scales in every evening pays premium storage prices for VMs nobody is using.

Smart Disk Tiering moves the OS disk of a deallocated, empty host down to Standard HDD and moves it back to the pool's performance tier, Premium SSD or Standard SSD, before autoscale starts the host again. It works in pools with Start VM on Connect turned on, it never touches a running host, and it keeps one or two powered-off standby hosts on the fast disk, depending on how busy the pool is, so a sudden rise in demand still lands on SSD.

Why the warm-up window matters. With Start VM on Connect, Azure picks which host to boot when a user connects, and a running host's disk tier can't change. If that host is still on Standard HDD, the session runs from the slower disk until the host is next switched off. Business hours close that gap:

• Set Business Hours in the Settings Matrix, under Compute & VM Lifecycle: the days, the start and end times and your users' time zone. The same value shows as the Daily Warm-up Window on the Smart Disk Tiering page.
• During those hours, every powered-off host in a Start VM on Connect pool is kept on its performance disk, so the first logon of the day boots from SSD.
• Set a Pre-warm Lead Time of up to 240 minutes, so Atlas starts moving disks up before opening time. A large pool needs a longer lead time, because disks move a few at a time through a rate-limited queue.
• After hours, disks go back down to Standard HDD and the savings resume for every night and weekend. Only the small standby buffer stays on the fast disk.

Business hours follow Global → Tenant → Host Pool, so a pool in another time zone or on a night shift keeps its own hours. You choose when downgrades may run: Automatic, Scheduled Only inside a window you set, or Manual Only when you run a scan. The Smart Disk Tiering guide covers each mode.

4. Session timeouts: don't let one disconnected user hold a host on

This is the setting most teams skip, and the one that quietly undoes the other three.

Idle Timeout Shutdown, DrainGuard and Smart Disk Tiering all wait for a host to be empty. A disconnected session counts as a session. So a single user who closed their laptop without signing out keeps their host running, and keeps its disk on Premium SSD, until they come back the next morning. In a pool of ten hosts, three or four users doing that on different hosts keeps three or four hosts running all night.

Session timeouts end that. Atlas sets two standard Remote Desktop session limits on your session hosts:

Set them in the Settings Matrix under Sessions & AVD, or on a pool's Settings → General → Session Timeouts. Values run from 0, meaning no limit, to 1,440 minutes, and they follow Global → Tenant → Host Pool. A change reaches the pool's existing session hosts as well as new ones, so you don't need to rebuild a pool to apply it.

Choosing values. A disconnect timeout that's too short signs people out during a lunch break, and anything they hadn't saved is lost. One that's too long keeps hosts running for nothing. A common starting point is an idle timeout of one to two hours and a disconnect timeout of 30 minutes to two hours, then adjust after a couple of weeks. Tell users before you turn it on, so "save your work before you leave" is expected, not a surprise. Cost Intelligence in Atlas can also recommend idle session timeouts for a pool, with an estimated monthly saving.

How the four settings work together

Here is one weekday evening in a pooled pool with all four turned on:

1. 5:30 p.m. People leave. Some sign out, some just close the lid. Disconnected sessions stay on their hosts.
2. After the disconnect timeout, Atlas's Remote Desktop policy signs those sessions out. FSLogix saves each profile as normal.
3. Five minutes after a host empties, Idle Timeout Shutdown drains it, checks it's still empty and deallocates it. Compute billing for that host stops.
4. Power-On-Connect means no floor has to stay up, so the pool can reach zero running hosts.
5. Smart Disk Tiering queues each deallocated host's OS disk for Standard HDD, apart from the small standby buffer.
6. Before opening time, the pre-warm lead time moves the disks back to Premium SSD.
7. 8:00 a.m. The first user connects, Azure starts a host on SSD, and autoscale adds hosts as the morning rush arrives.

Take any one setting away and a gap opens. Without session timeouts, steps 3 to 5 never start for hosts with a disconnected user. Without Power-On-Connect, a floor stays running all night. Without the warm-up window, the first users of the day can land on a host still on HDD.

A worked example

These figures are arithmetic on an example pool, not customer data. Use them to see the shape of the savings, then model your own estate in the AVD cost calculator.

The example pool: 10 pooled session hosts, Premium SSD OS disks, people working Monday to Friday, 08:00 to 18:00 (50 hours a week). Autoscale runs an average of 7 hosts across working hours. A week has 168 hours, so with 10 hosts there are 1,680 host-hours of compute and 1,680 disk-hours to pay for.

What the table shows:

• Autoscale alone removes most of the idle compute, from 1,680 to 468 host-hours.
• Three disconnected sessions nearly double what's left. That's why session timeouts belong in the same change as autoscale, not in a later one.
• Power-On-Connect and session timeouts together take compute to 360 host-hours, about 79% fewer than always on.
• Smart Disk Tiering moves about 56% of disk-hours to Standard HDD, even with every host on SSD through the working day.

Your own numbers depend on your hours, how evenly people sign in, your VM size and your disk size. The proportions hold for most office-hours pools: the hours nobody uses are where the money goes.

See what you're saving

Atlas records every saving as it happens, so you don't have to wait for the Azure invoice to see whether a change worked. The Cost Savings breakdown shows each optimization by type, including VM Deallocate for hosts autoscale switched off and Disk Tier for disks moved down, with the hourly rate it's saving now and what's been banked so far.

A rollout checklist

1. Set session timeouts at the tenant level first. Start with values your users can live with and tell them before it's on.
2. Turn on autoscale per pool, with Depth-First, a working-hours schedule for the morning rush, and empty warm hosts at 0.
3. Mark reserved-instance hosts always on, so autoscale leaves the hosts you've prepaid running.
4. Turn on Start VM on Connect, then Optimize for Power-On-Connect, starting with pools whose users can accept a short wait on the first logon.
5. Turn on Smart Disk Tiering and set business hours for the same pools, with a pre-warm lead time that suits the pool's size.
6. Watch the first week. Check first-logon times and the Cost Savings breakdown, then widen to the next pools.

Autoscale applies to pooled host pools. For personal desktops, use Auto On/Off Scheduling or a Microsoft scaling plan for personal pools alongside Start VM on Connect. For the cost levers beyond these four, such as right-sizing, Hybrid Benefit and reservations, read Cut Idle AVD Compute: Our Cost Model Shows Up to 60%.

Every setting in this post is included on the Atlas AVD plan, for every pool and every user. See pricing, or start free and turn them on in your own tenant.