Autoscaling Fundamentals: Picking the Right Policy Type

Autoscaling is the practice of changing the number of instances (or tasks, or pods) behind a workload automatically, based on a signal, so capacity follows demand instead of being fixed at the peak. Every major cloud offers it for groups of identical VMs: Amazon EC2 Auto Scaling groups (ASGs), Google Cloud managed instance groups (MIGs), and Azure Virtual Machine Scale Sets (VMSS). Container platforms add their own layers, such as Application Auto Scaling for Amazon ECS services and the Kubernetes Horizontal Pod Autoscaler.

The hard part is not turning autoscaling on. It is choosing which kind of policy should drive the decision, because each one reacts to a different kind of information.

The four policy families

Reactive, target based. You pick a metric and a target value, and the autoscaler adds or removes capacity to hold the metric near the target. On AWS this is a target tracking policy; on Google Cloud it is the default mode of the MIG autoscaler, which adds a CPU utilization signal when you turn autoscaling on.

Reactive, threshold based. You define alarm thresholds and how much capacity to add or remove at each level of breach. AWS calls this step scaling. Azure VMSS autoscale rules follow the same pattern: a metric, an aggregation, a threshold, and a scale-out or scale-in action.

Time based. You tell the autoscaler that a given capacity is needed at a given time. EC2 Auto Scaling scheduled actions take a cron expression and a time zone, Google Cloud scaling schedules set a minimum instance count for a start time and duration, and Azure uses recurring or fixed-date autoscale profiles.

Forecast based. The provider learns daily or weekly patterns from history and launches capacity before the forecast load arrives. See predictive scaling for how the three clouds differ.

How to choose

Start from the shape of the demand, not the feature list:

• Load you cannot predict, with a metric that moves in proportion to capacity (average CPU, requests per target): use target tracking. AWS explicitly recommends target tracking for metrics like average CPU utilization or average request count per target.
• Load that arrives in large bursts, where you want explicit control over how hard to react: use step scaling, or pair it with target tracking.
• Load that follows the clock (business hours, weekday batch windows): scheduled capacity is simple and transparent, and forecast-based scaling can learn the same pattern without you writing the schedule.
• Load tied to a known date (a sale, a launch, a migration cutover): a one-off scheduled action. This is the core of the event readiness playbook.

Combining policies safely

Policies can coexist, and the providers resolve conflicts in favour of availability. When several target tracking policies are attached to one ASG, EC2 Auto Scaling scales out if any of them wants to, and scales in only when all of them agree. A Google Cloud MIG with multiple signals computes a recommended size per signal and uses the largest. Overlapping Google Cloud scaling schedules resolve to the greatest required instance count.

Two failure modes are worth designing out. The first is flapping, where scale-out and scale-in conditions are true at the same time. Microsoft’s autoscale guidance is to drive both directions from the same metric and to keep an adequate margin between the minimum and maximum instance counts; a setting with minimum and maximum both at 2 can never scale. The second is reacting to instances that are still booting. AWS uses an instance warmup period, and Google Cloud uses an initialization period (60 seconds by default), so new instances do not distort the metric before they serve traffic.

Where ZopNight fits

ZopNight manages autoscaling policies for AWS ASGs, AWS ECS services, Azure VMSS, and GCP MIGs. The mode follows the cloud account’s permission level: a read-only account gets monitor mode, while a read + write account can use recommend or autopilot. When a target already has a policy you created in the cloud console, ZopNight asks whether to adopt it unchanged or replace it, rather than overwriting it silently. Its autoscaler recommendations flag, for example, an ASG with no scaling policy, a VMSS with no autoscale setting, a target set above 90% or below 30%, and cooldowns shorter than 120 seconds.