Review AVD scaling plan costs
Evaluate a pooled scaling plan against observed demand and allocated host hours. Minimum running hosts and session capacity thresholds can prevent a schedule from reaching its theoretical cost. Keep the machine size fixed for the comparison, include persistent storage, and test access behavior. Azure autoscale performs customer-authorized changes; Costframe remains a read-only reviewer.
In this guide
Identify the scaling method and scope
Microsoft distinguishes power management autoscaling from dynamic autoscaling. Power management changes the power state of existing hosts. Dynamic scaling has separate prerequisites and can create or delete hosts. This review concerns pooled power management, where the main economic assumption is a change in allocated instance hours.
Record the assigned host pools, plan time zone and schedule days. Confirm that the plan is enabled on the intended pool and check exclusion tags. Microsoft warns against running autoscale and a separate Azure Automation or Logic Apps scaling solution on the same pool. Competing controls can make both the observed behavior and its costs difficult to explain.
Compare the schedule with observed demand
Plot connections and session counts around ramp-up and ramp-down, including disconnected sessions. Include shift changes and exceptional days such as month-end work. Record when hosts become available for connections, since the scheduled start time alone does not establish readiness for the first arriving user.
Check the configured maximum session limit and capacity threshold with the pool owner. Microsoft uses them to decide when to add capacity and whether fewer hosts can accommodate existing sessions. The minimum host count derived from a percentage is rounded up to a whole host. Excluded hosts still affect the minimum-host calculation, so a maintenance exception can change the economics of a small pool.
An illustrative host-hour comparison
Assume eight identical hosts in a 30-day month, an invented instance rate of USD 0.40 per allocated host-hour and USD 320 in unchanged managed disk charges. The baseline keeps eight hosts allocated for 720 hours each: 5,760 host-hours. The candidate keeps eight allocated for 12 hours daily and two for the other 12 hours: 3,600 host-hours.
The candidate compute estimate is USD 1,440, compared with USD 2,304 for the baseline. Including disks gives USD 1,760 and USD 2,624 respectively. The modeled difference is USD 864. It assumes demand allows the proposed schedule every day and excludes extra allocated time during transitions. It is not a savings forecast or an Azure price quote.
Scroll the table sideways on smaller screens. Keyboard: focus the table and use the arrow keys.
| Illustrative monthly component | Baseline | Candidate schedule |
|---|---|---|
| Allocated host-hours | 5,760 | 3,600 |
| Assumed instance rate | USD 0.40 per hour | USD 0.40 per hour |
| Compute estimate | USD 2,304 | USD 1,440 |
| Unchanged managed disks | USD 320 | USD 320 |
| Scoped monthly estimate | USD 2,624 | USD 1,760 |
| Modeled cost difference | Not applicable | USD 864 |
Stress-test the economic assumptions
A minimum of two hosts is an assumption in the example, not a suitable default for every pool. Workloads may require more capacity for reconnections or host failures. If demand keeps extra hosts allocated overnight, replace the candidate hours with observed hours before estimating a cost difference.
Keep licenses and profile storage outside the variable compute reduction unless their own billing mechanism changes. Existing reservations or savings plans need a separate commitment-utilization review: fewer running hosts do not by themselves establish a lower payment obligation. Do not apply a commitment discount and a host-hour reduction to an actual-cost baseline without proving both effects.
Review ramp-down and restart behavior
Microsoft allows different ramp-down choices for active and disconnected sessions. Forced sign-out can send a notification and sign users out after a configured wait. Review that setting with the service owner because unsaved work and background tasks can be affected. A cost target cannot establish that users may be interrupted.
Check unselected schedule days: Microsoft carries the last off-peak parameters forward until the next scheduled ramp-up. Confirm that weekends and holidays match the service's access obligations. Document excluded maintenance hosts and who restores them to normal control. Approve the restart or rollback path before the customer changes an assigned plan, since Microsoft says assigned-plan updates apply immediately.
Run a bounded customer trial and reconcile
The customer administrator should choose a representative pool and trial period, retain the original settings and name the person authorized to revert them. Observe allocated host hours alongside failed connections and session behavior. Stop the trial when agreed access requirements are not met, even if the compute estimate looks favorable.
Afterward, compare actual same-currency charges with the modeled hours and explain differences in demand or rates. Persistent disks still belong in the scoped comparison. Costframe's Azure audit client is read-only; it does not assign or execute scaling plans. Keep customer changes and provider observations separate from any financial conclusion, and retain evidence gaps when attribution remains unresolved.
Sources
Use this in your next review
Inspect a review example before bringing your own schedule and cost evidence.
Open a demo auditCheck plans and current scope