Autoscale Profiles and Schedule Rules

Autoscale in Azure allows you to automatically increase or decrease the number of instances (VMs, web app instances, etc.) based on demand. An autoscale profile is a container that defines the instance limits (minimum, maximum, default) and the set of rules that govern scaling. A schedule rule (or scheduled profile) is a profile that is active only during a specific time window, either recurring (e.g., every weekday from 9 AM to 5 PM) or fixed-date (e.g., a specific date range for a promotion). Multiple profiles can be defined, and the autoscale engine selects the appropriate profile based on the current date and time.

Without profiles, you would have a single set of instance limits and rules for all times. However, many workloads have predictable patterns: higher traffic during business hours, lower traffic at night, or spikes during specific events. Profiles allow you to pre-configure scaling behavior for these patterns, ensuring that the scale set starts with an appropriate number of instances and reacts to metrics within the context of that profile.

The autoscale engine runs every 30 seconds (the evaluation interval) and checks the current time against the defined profiles. It evaluates profiles in the following order of precedence:

When a profile is active, its instance limits (minimum, maximum, default) and scale rules are used. If multiple recurring profiles match the same time (e.g., two recurring profiles both active on Monday at 10 AM), the one with the more specific schedule takes precedence, or if they conflict, the behavior is undefined – you should avoid overlapping schedules.

To create autoscale settings with profiles, use az monitor autoscale create and az monitor autoscale profile create. Example:

# Create autoscale setting for a VMSS
az monitor autoscale create \
  --resource-group myRG \
  --resource myVMSS \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name myAutoscale \
  --min-count 1 \
  --max-count 10 \
  --default-count 2

# Add a recurring profile for weekdays 9 AM - 5 PM
az monitor autoscale profile create \
  --name weekdayProfile \
  --resource-group myRG \
  --autoscale-name myAutoscale \
  --min-count 2 \
  --max-count 20 \
  --default-count 5 \
  --recurrence week mon,tue,wed,thu,fri \
  --recurrence-start "09:00" \
  --recurrence-end "17:00" \
  --timezone "Eastern Standard Time"

Use az monitor autoscale show to view profiles. In the Azure portal, navigate to the autoscale settings blade for your resource. The effective profile is displayed based on current time.

Enterprise Scenario 1: E-commerce Platform with Weekly Sales Cycle

An online retailer experiences high traffic every Monday morning (post-weekend sales) and low traffic on weekends. They configure a recurring profile for Monday–Friday 8 AM–6 PM with min=10, max=50, default=20. A separate recurring profile for weekends has min=2, max=10, default=5. Additionally, during Black Friday week, they deploy a fixed-date profile from Nov 25–30 with min=20, max=100, default=50. Without these profiles, the autoscale would react to metrics but might scale too slowly for the Monday morning surge, causing performance degradation. The profile ensures that capacity is pre-allocated. Common issue: if the fixed-date profile overlaps with the recurring weekday profile, the fixed-date takes precedence, which is intended. However, if the fixed-date end time is not correctly set, the platform may remain scaled up unnecessarily, increasing costs.

Enterprise Scenario 2: Financial Services Batch Processing

A bank runs batch processing jobs every night from midnight to 6 AM. They create a recurring profile for that window with min=20, max=50, default=30 to handle the workload. During the day, a default profile with min=2, max=10, default=5 is used. They also have a fixed-date profile for end-of-quarter processing (March 31, June 30, etc.) with higher limits. Misconfiguration: if the recurring profile's end time is set to 6:00 AM but the batch job often runs until 6:30, the default profile kicks in at 6:00 AM and scales down prematurely, causing job failures. The solution is to add a buffer (e.g., end time 7:00 AM) or use a second recurring profile.

Scenario 3: Media Streaming Platform with Event-Driven Spikes

A streaming service has a recurring profile for prime time (7 PM–11 PM) with min=10, max=30. For a major live event (e.g., Super Bowl), they use a fixed-date profile with min=50, max=200. They also define scale rules: scale out when CPU > 60% for 5 minutes, scale in when CPU < 20% for 10 minutes. Performance consideration: the cooldown period (default 5 minutes) can cause scale-in delays after the event ends. To avoid over-provisioning, they reduce the cooldown to 2 minutes in the fixed-date profile. However, too short a cooldown can cause thrashing. Best practice: keep cooldown at least 5 minutes unless you have specific reasons.