Azure Virtual Desktop Autoscale Scaling Plans

Introduction

Session hosts that stay powered on after the last user leaves continue to incur compute charges. Shut them down too aggressively and the first person in at 8 a.m. waits for a cold start.

In one sample environment we reviewed, stopped desktops took a typical 3 minutes to start and 5.2 minutes at worst.

Azure Virtual Desktop autoscale scaling plans address both problems. They use schedules and host-pool capacity settings to match session-host availability to expected demand.

This guide covers prerequisites, pooled and personal behavior, the four schedule phases, configuration steps, cost boundaries, validation, and troubleshooting.

Key Takeaways

  • Scaling plans change session-host power state, not VM size, and they are not VM Scale Sets.
  • Good plans balance savings against login speed with capacity buffers, drain mode, and careful ramp-down.
  • Check region, time zone, assignment, permissions, session limits, and competing automation before go-live.
  • Autoscale cuts compute only. Disks, profiles, networking, and licensing keep billing.

What Are Azure Virtual Desktop Autoscale Scaling Plans?

Per Microsoft's autoscale overview, a scaling plan scales session-host VMs in a host pool up and down on a schedule to optimize deployment costs. In practice, it starts and deallocates existing session hosts based on schedules, session demand, minimum-host settings, and capacity thresholds.

Teams adopt it to:

  • Stop paying for idle compute
  • Have capacity ready for predictable work periods
  • Remove manual host-pool power management

Horizontal vs. vertical scaling

Horizontal scaling adds or removes available capacity, meaning more or fewer running hosts. Vertical scaling changes the size of an individual VM. Native power-management plans are horizontal. They do not resize VMs.

What scaling plans are not

  • VM Scale Sets change instance counts for application VMs behind a load balancer.
  • Azure Monitor autoscale adds or removes resource instances using metric or schedule rules. It does not scale vertically.
  • Azure Automation scripts are a legacy, custom alternative to native plans.

The cost boundary

Per Azure billing guidance, a VM in Stopped (Allocated) still incurs compute charges, while Deallocated does not. Disks and networking may keep billing either way.

Profile storage, backup, monitoring, and applicable licensing sit outside the savings too. Eligible Microsoft 365 and Windows licenses include AVD desktop access at no extra charge.

Feature status shifts. Pooled power management and personal autoscale are generally available. Dynamic autoscaling (host creation and deletion) is labeled preview in the overview, while newer release notes say "now available." Verify current Microsoft documentation before committing to it.

Prerequisites and Planning Before You Enable Autoscale

Planning prevents most failed rollouts. Work through this list first.

Know your host pools and demand

  • Identify pooled vs. personal pools. Each plan type only matches its own pool type.
  • Pull connection history from AVD Insights. Look at login peaks, late sessions, weekends, holidays, and time zones.
  • Flag users who need 24-hour access or protected maintenance windows.

One sample environment peaked at just 3 users, or 30% of 10 sessions across two desktops. Assumed business hours would have missed that. Real connection data won't.

Confirm technical requirements

  • Region: the plan and host-pool configuration must share a region. Session-host VMs can live elsewhere.
  • Time zone: the plan runs in its configured time zone.
  • Session limit: pooled pools need a custom MaxSessionLimit, not the default. Microsoft calculates required hosts as ceiling[(active + disconnected sessions) / (MaxSessionLimit × capacity threshold)].
  • Permissions: assign the Desktop Virtualization Power On Off Contributor role to the AVD service principal, scoped only as far as needed. Use Microsoft's current role guidance rather than an old custom role. Role assignment needs Microsoft.Authorization/roleAssignments/write (Owner or User Access Administrator).

Clear out conflicting automation

Microsoft says not to combine scaling plans with other scaling tools on the same pool. Inventory scripts, Azure Automation runbooks, Azure Monitor rules, Nerdio policies, and old shutdown schedules. Overlap produces unpredictable behavior.

Decide up front which hosts need an exclusion tag. Tagged hosts are not started, stopped, or drained, but they still count toward the minimum-host calculation.

How the Four AVD Scaling Plan Phases and Settings Work

Every pooled schedule has four phases: ramp-up, peak, ramp-down, and off-peak. Each has a start time and load-balancing algorithm.

Phase Key settings Notes
Ramp-up Minimum hosts %, capacity threshold Microsoft recommends breadth-first. No hosts turn off.
Peak Load balancing Inherits the ramp-up threshold. Hosts start and stop as needed.
Ramp-down Threshold, minimum hosts %, force logoff, wait time, message Capacity and minimum limits still apply.
Off-peak Load balancing Inherits the ramp-down threshold. Depth-first is recommended.

Ramp-up and peak

Set the minimum active-host percentage so capacity exists before the first login. Microsoft's example: six hosts, a 30% minimum, and five sessions per host gives two powered-on hosts, rounded up.

AVD ramp-up capacity calculation showing minimum active hosts

Breadth-first spreads new sessions across available hosts. It suits ramp-up and performance-sensitive work because users land on lightly loaded machines while capacity starts.

Ramp-down

Ramp-down is where users get hurt. Without force logoff, you choose a stopping condition: no active or disconnected sessions, or no active sessions. Disconnected sessions count toward capacity, so they can block scale-in.

With force logoff, autoscale picks the host with the fewest sessions and enables drain mode so it takes no new users. It then notifies users, waits, signs them out, and deallocates the host.

Unsaved work can be lost, so set a generous wait time and a clear message. Logoff messages sometimes state less time than you actually configured, so test your wording.

Off-peak and depth-first

Depth-first sends new sessions to the busiest host that hasn't hit its limit. That consolidates users and frees hosts for shutdown. It fits off-peak.

Check how much of an after-hours startup delay your users can tolerate. A floor of zero hosts saves the most and risks cold starts.

Multiple schedules

You can create weekday and weekend schedules, and separate plans for departments with different hours. Unselected days keep the previous day's off-peak parameters until the next ramp-up. Specific-date ramp-down isn't supported natively.

How to Create, Assign, and Validate an AVD Autoscale Scaling Plan

Baseline first

Document host count, VM SKUs, powered-on hours, session patterns, and storage. Pull current billing data. Don't promise a savings percentage. No reliable savings estimate exists for native plans.

Create and assign

  1. In the Azure portal, go to Azure Virtual Desktop > Scaling Plans > Create.
  2. Set resource group, name, region, time zone, host-pool type, and exclusion tag.
  3. Add at least one schedule and configure all four phases from observed demand.
  4. Under Host pool assignments, select matching pools and enable autoscale.
  5. Select Review + Create.

A plan that isn't assigned does nothing. One plan can serve multiple pools, but each pool gets only one plan. Changes to an assigned plan apply immediately.

You can also use PowerShell (New-AzWvdScalingPlan, Az.DesktopVirtualization 4.2.0 or later) or ARM, Bicep, and Terraform via the Microsoft.DesktopVirtualization/scalingPlans resource. Microsoft's Terraform example uses AzAPI.

There is no dedicated Azure CLI configuration per Microsoft's FAQ. Property names change between versions, so check the current reference.

Validate before production

  • Test on a nonproduction or representative pool.
  • Confirm host states, session distribution, drain behavior, notifications, and startup timing.
  • Check how disconnected sessions are treated.
  • Plan a rollback: clear Enable autoscale on the pool, then check hosts manually.
  • Microsoft doesn't state that drain mode resets automatically, so use Turn drain mode off on any host left drained.

Monitor the first cycles

For pooled pools, send diagnostics to the Log Analytics workspace used by Insights:

  • WVDAutoscaleEvaluationPooled records actions and reasons
  • Join WVDErrors on CorrelationId when troubleshooting failures
  • Use the Activity Log to confirm power-state changes

Personal pools aren't covered by Autoscale Insights, so send their logs to Storage or Event Hubs instead.

Adjust schedules, thresholds, and minimum floors before reaching for force logoff.

AVD autoscale validation and monitoring workflow from testing to adjustment

Optimize and Troubleshoot AVD Autoscale in Production

Pooled vs. personal behavior

  • Pooled: decisions rest on shared session capacity, session limits, load balancing, and host consolidation.
  • Personal: decisions follow session state. Disconnect and logoff can deallocate, hibernate, or do nothing after 0 to 360 minutes.
  • If ramp-up starts no VMs, Microsoft strongly recommends Start VM on Connect.

Hibernation keeps storage and network charges, and FSLogix and App Attach don't support it.

When native plans are enough

Native plans cover most schedule-driven needs. A management platform such as Nerdio Manager may help when you need:

  • CPU, RAM, or session-based triggers
  • Base and burst capacity, or pre-staging
  • Specific-date schedules or broader reporting

Those are Nerdio features, not native-plan capabilities.

TechSogna is a Microsoft Partner and Authorized Nerdio Partner. We assess existing AVD environments, validate scaling behavior, document the configuration, and provide business-hours co-management for teams without dedicated AVD expertise. Our fixed-fee Health Check starts at $3,500.

Troubleshooting checklist

Nothing scales

  • Check host-pool assignment and that autoscale is enabled
  • Verify permissions, region, and time zone
  • Look for conflicting automation

Hosts won't deallocate

  • Look for active or disconnected sessions
  • Check drain mode, force-logoff settings, and exclusion tags
  • Review the minimum-host percentage and capacity threshold (autoscale acts above or below the threshold, not at it)

Users see delays

  • Review ramp-up timing, startup time, and capacity buffers
  • Check load balancing, VM sizing, and profile storage
  • Check sign-in telemetry. Our sample review showed a 5.7-minute cold start.

The bill barely moved

  • Separate compute savings from disk, profile, backup, and networking costs
  • Check licensing and unattached disks

AVD autoscale troubleshooting matrix for scaling delays and billing issues

Frequently Asked Questions

What are the two types of scaling on Azure?

Horizontal scaling changes the number of instances or session hosts. Vertical scaling changes the size of one VM. AVD scaling plans are primarily horizontal.

Does resizing Azure VM lose data?

Resizing restarts a running VM, and some sizes require deallocation. OS and data disks are unaffected, but temporary disk data can be lost. Verify SKU compatibility and take backups first.

What are Azure VM scale sets?

VM Scale Sets manage instance counts for application VMs using schedules or metrics behind a load balancer. AVD scaling plans instead coordinate session-host power and user-session capacity within host pools.

How do I create an autoscale scaling plan in Azure Virtual Desktop?

Confirm permissions and a custom session limit, then create the plan with its schedules. Assign it to a host pool, enable autoscale, and validate through logs and power states.

What is the difference between breadth-first and depth-first load balancing in AVD?

Breadth-first spreads sessions across hosts, favoring performance. Depth-first fills the busiest host first, consolidating users so idle hosts can shut down during scale-in.