Autoscaling

ZopNight’s autoscaler (Automate → Auto Scaling) sizes your fleet for the moment, not for the peak. It manages scaling policies for VM scaling groups (AWS ASG, Azure VMSS, GCP MIG) and AWS ECS services, and is separate from the cloud-native autoscalers: ZopNight either configures them on your behalf or sits alongside them in observe mode. Existing policies are adopted, never silently overwritten, and restored on removal.

Automate → Auto Scaling: one card per policy with its status, mode, target, instance range, and lifecycle actions, filterable by provider, status, and type.

Before you start

• A connected cloud account with the scaling group or ECS service you want to manage. See Cloud accounts.
• A Read + Write cloud account for Recommend or Autopilot. A Read-only account gives you Monitor mode only.
• The cloud-side scaling permissions for the provider (for example, autoscaling:PutScalingPolicy and autoscaling:UpdateAutoScalingGroup for an AWS Auto Scaling group, or write access to autoscale settings for an Azure VM scale set). See Cloud permissions.

How it works

Modes

The autoscaler runs in one of three modes, derived from the connected cloud account’s permission level.

Mode	Permission	What ZopNight does
Monitor	Read-only account	Observe scaling patterns and surface recommendations. No writes to cloud.
Recommend	Read + Write account	Generate scaling policy suggestions; you click Apply to push them to the cloud.
Autopilot	Read + Write account	Apply and tune scaling policies automatically based on observed traffic.

Mode auto-detects from the account’s permission level at connection time. You can downgrade (autopilot → recommend → monitor) any time; upgrading needs the right cloud-side permissions first.

Supported metrics

Policies can scale on CPU, memory, request count, custom CloudWatch / Cloud Monitoring / Azure Monitor metrics, latency, error rate, and queue depth. On AWS ASG, policies can also use step scaling (scale-out and scale-in adjustments).

Which metrics are available depends on the provider and target type, and the wizard’s metric picker filters to what’s valid for the selected target. On an Azure VMSS, latency, error rate, and queue depth triggers need an explicit metric configuration naming the source resource, because they are read from another resource.

Schedule triggers

Time-based scaling for predictable traffic patterns, set with cron. Three presets are built in: Business Hours, Peak Hours, and Weekend Scale-Down. Each is a starting cron expression you can edit before you apply it.

For a one-off spike on a known date, such as a launch or a sale, use Event readiness instead.

Create a policy with Quick Setup

Automate → Auto Scaling → Create Autoscaling Policy with Quick Setup is the fastest way to put autoscaling on a target. Smart defaults compute min/max/target/cooldown from observed CPU using online statistics (Welford-based; average, stddev, P90/P95/P99).

1. Pick a cloud account and target

   Cloud account dropdown → pick the resource type (ASG, VMSS, MIG, or ECS service) → pick the specific target.

2. Review the smart defaults

   Min/max/target/cooldown are pre-filled. The card shows the CPU distribution underneath so you can sanity-check them.

3. Create the policy

   One click. ZopNight writes the policy to the cloud-side autoscaler (ASG Target Tracking, VMSS Autoscale Setting, MIG Autoscaler, or ECS Application Auto Scaling).

Adopt or Replace existing policies

If you already have scaling policies on the target (defined manually, via Terraform, or by another tool), ZopNight does not silently overwrite them. The wizard detects existing policies and asks you to pick.

Target a resource group

You can target an autoscaler policy at a resource group (Advanced mode in the wizard), so a single policy applies to the scaling targets in that group.

Lifecycle

Each policy has its own lifecycle, independent of the others.

Action	Effect
Apply	Write the policy to the cloud autoscaler (ASG / VMSS / MIG / ECS)
Pause	Suspend the policy without removing it from the cloud
Resume	Re-enable a paused policy
Remove	Delete the ZopNight policy and restore the configuration that was there before

Apply uses provider-specific calls: AWS ASG PutScalingPolicy + UpdateAutoScalingGroup, ECS RegisterScalableTarget + PutScalingPolicy (policies prefixed zopnight-ecs- for safe identification on Remove), Azure Autoscale Settings API, and GCP Autoscaler API.

Adopted policies skip the write path entirely. Remove on an adopted policy is a no-op cloud-side.

Autoscaling recommendations

The same audit engine surfaces rules specific to scaling configuration: six are defined and five are active. Click Remediate on any of these to configure or tune via the autoscaler in one click. One-click apply needs Recommend or Autopilot mode; in Monitor mode the autoscaler is read-only and can’t remediate.

What it catches	Providers
Scaling group has no scaling policies	AWS (ASG)
Autoscale setting missing	Azure (VMSS)
Scaling target too high (> 90%)	Azure (VMSS)
Scaling target too low (< 30%)	Azure (VMSS)
Cooldown too short (< 120s)	Azure (VMSS)

The GCP MIG rule (autoscaler missing) is defined but not active, because a MIG’s spend is already counted on its member VMs and a group-level finding would double-count it.

See Recommendations for how the recommendation engine works.

Event log

Every Apply / Pause / Resume / Remove action writes an event row per policy with status, error message, and timestamp. The event log is your source of truth for “why is this policy in this state?”

Troubleshooting

Next steps