Why Azure Scaling Plans Can Be Limiting

Azure Virtual Desktop includes native scaling plans — Microsoft’s built-in solution for automatically managing session host capacity. They’re free, they’re integrated, and they work.

So why would anyone look beyond them?

Because while Azure scaling plans are a solid foundation, they come with limitations that can cost you money and flexibility. Let’s explore what those limitations are and when you might need something more sophisticated.

What Azure Scaling Plans Offer

First, credit where it’s due. Azure scaling plans provide:

Time-based scaling — Define different capacities for different times of day
Load-based scaling — Scale based on session host utilisation
Ramp-up and ramp-down periods — Gradual transitions between capacity levels
Weekend schedules — Different behaviour for weekdays vs weekends

For many simple deployments, this is enough. If your usage patterns are predictable and consistent, native scaling plans might serve you well.

But here’s where things get complicated.

Limitation 1: Rigid Scheduling

Azure scaling plans work on fixed schedules. You define your time windows, and the system follows them religiously.

The problem: Real-world usage isn’t that predictable.

Consider these scenarios:

Your finance team works late during month-end close
Sales has a major event that changes their working patterns for a week
A project deadline means extended hours for one department
Summer hours mean earlier finishes across the organisation

With native scaling plans, you’d need to manually adjust schedules for each of these situations. Miss one, and you’re either paying for unused capacity or leaving users without resources.

Limitation 2: No Holiday Awareness

This is a big one. Azure scaling plans have no concept of public holidays.

What this means in practice:

It’s Christmas Day. Your office is closed. Your scaling plan doesn’t know that. It dutifully scales up to full capacity at 8am, maintaining resources that nobody will use.

Now multiply that by every bank holiday, regional holiday, and company closure throughout the year. You’re paying for capacity that sits idle.

The workaround? Manually adjust schedules before each holiday. Hope you don’t forget. Hope your team doesn’t miss any. Hope the person who handles this doesn’t go on leave themselves right before a holiday.

It’s not a sustainable approach.

Limitation 3: Single-Region Thinking

Azure scaling plans are designed with a single timezone in mind. But modern organisations are rarely that simple.

Real-world complexity:

Your UK team works 9-5 GMT
Your US team works 9-5 EST (5 hours behind)
Your Australia team works 9-5 AEST (11 hours ahead)
Your support team spans all regions

Managing this with native scaling plans means creating multiple plans, coordinating between them, and hoping they don’t conflict. It’s possible, but it’s complex and error-prone.

Limitation 4: Limited Scaling Logic

Azure scaling plans support two scaling modes: scheduled and load-based. Both are relatively basic.

Scheduled scaling follows your defined timetable. Simple, predictable, but inflexible.

Load-based scaling reacts to current utilisation. Better, but it’s reactive — by the time utilisation triggers a scale-up, users might already be waiting.

What’s missing:

Predictive scaling — Anticipating demand before it hits
Historical pattern learning — Understanding that Mondays are busier than Tuesdays
Event awareness — Knowing that the all-hands meeting ends at 3pm and everyone will log in simultaneously
Gradual user migration — Intelligently moving users to consolidate hosts before shutdown

Limitation 5: Basic Ramp Behaviour

The ramp-up and ramp-down logic in Azure scaling plans is straightforward: linear progression between two capacity points.

What this misses:

Real usage patterns aren’t linear. Typically, you see:

A sharp spike at the start of the working day
A plateau during core hours
A gradual tail-off in the afternoon
Minimal usage overnight

A linear ramp doesn’t match this pattern. You’re either scaling too slowly (users wait) or too quickly (resources sit idle).

Limitation 6: No Cross-Host Pool Coordination

If you have multiple host pools, each gets its own scaling plan. There’s no coordination between them.

Why this matters:

You can’t implement organisation-wide policies consistently
Each pool is an island — no shared intelligence
Changes need to be made in multiple places
No unified view of scaling behaviour

When Native Scaling Plans Are Enough

Let’s be fair: for some scenarios, Azure scaling plans are perfectly adequate:

Small, simple deployments — One region, predictable hours
Consistent usage patterns — Same schedule every day, few exceptions
Manual holiday management — You have processes to adjust for holidays
Basic cost optimisation needs — Some saving is better than none

If this describes your situation, native plans might be all you need.

When You Need More

Consider looking beyond Azure scaling plans when:

You operate across multiple regions and need coordinated scaling
Holidays significantly impact your usage and manual management is unsustainable
Your usage patterns are variable and fixed schedules don’t fit
You want predictive scaling that anticipates demand
You need visibility into scaling decisions and their impact
Cost optimisation is a priority and you’re leaving money on the table

What The Smart Scaler Adds

This is where we come in. The Smart Scaler builds on the foundation of Azure’s capabilities while addressing these limitations:

Holiday-aware scheduling — Automatic adjustment for public holidays worldwide
Multi-region intelligence — Coordinated scaling across timezones
Predictive capabilities — Learning from historical patterns (coming soon)
Custom business logic — Rules that match your organisation’s reality
Unified management — Single view across all your host pools
Detailed analytics — Understand exactly what’s being scaled and why

The Bottom Line

Azure scaling plans are a good starting point. They’re free, they’re native, and they deliver basic cost optimisation.

But if your organisation is complex, spans multiple regions, or needs more intelligent scaling decisions, you’ll likely hit their limitations.

The Smart Scaler doesn’t replace Azure’s infrastructure — it enhances it. We use Azure’s APIs to execute scaling decisions, but we bring intelligence that goes beyond what native tools provide.

Ready to see what intelligent scaling looks like? Try The Smart Scaler free and discover how much more you could be saving.