Autoscaling
VM and container autoscaling for ASG, VMSS, MIG, and ECS; with quick setup, smart defaults, and a safe adopt-or-replace flow.
ZopNight runs an autoscaler that manages scaling policies for VM scaling groups (AWS ASG, Azure VMSS, GCP MIG) and AWS ECS services. It’s separate from the cloud-native autoscalers. ZopNight either configures them on your behalf or sits alongside them in observe mode.
Auto Scaling; per-policy target, mode, instance range, and lifecycle actions across ASG, VMSS, MIG, and ECS.
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 credentials | Observe scaling patterns and surface recommendations. No writes to cloud. |
| Recommend | Read-write credentials | Generate scaling policy suggestions; you click Apply to push them to the cloud. |
| Autopilot | Read-write credentials | Apply and tune scaling policies automatically based on observed traffic. |
Mode auto-detects from the credential at connection time. You can downgrade (autopilot → recommend → monitor) any time; upgrading needs the right cloud-side permissions first.
Quick Setup
The fastest way to get autoscaling on a target. Smart defaults compute min/max/target/cooldown from observed CPU using online statistics (Welford-based; average, stddev, P90/P95/P99).
Pick a cloud account and target
Cloud account dropdown → pick the resource type (ASG, VMSS, MIG, or ECS service) → pick the specific target.
Review the smart defaults
Min/max/target/cooldown are pre-filled. The card shows the CPU distribution underneath so you can sanity check.
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).
Supported metrics
Available metrics depend on the target type. The wizard’s metric picker filters to what’s valid for the selected target.
| Metric | Targets |
|---|---|
| CPU utilisation | ASG, VMSS, MIG, ECS |
| Memory utilisation | ASG, VMSS, MIG |
| Request count per target | ASG (with ALB), ECS (with ALB) |
| Custom CloudWatch / Cloud Monitoring / Azure Monitor | ASG, VMSS, MIG |
| Latency | ASG (with ALB). VMSS rejects without explicit metric_config override |
| Error rate | ASG (with ALB). VMSS rejects without explicit override |
| Queue depth (SQS, etc.) | ASG. VMSS rejects without explicit override |
| Step scaling (scale-out / scale-in adjustments) | ASG |
Schedule triggers
Time-based scaling for predictable traffic patterns. Three presets out of the box:
- Business Hours: scale out for the working day, scale in overnight on weekdays
- Peak Hours: short midday scale-out for predictable lunch / midday traffic spikes
- Weekend Scale-Down: scale in for the weekend, scale back out at the start of the work week
Exact cron expressions are configurable per preset before apply.
Each preset writes a cloud-native scheduled action (no polling): AWS PutScheduledUpdateGroupAction, ECS PutScheduledAction, Azure FixedDate profile, GCP scalingSchedules.
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.
Adopt
Zero-mutation observation. ZopNight tracks the existing policy as source: adopted and reports on it without changing it. Editing any field in ZopNight silently promotes the policy to source: recommended and starts managing it.
Replace
ZopNight deletes the existing policy and writes its own. The full pre-existing config is captured before deletion so Remove restores byte-accurately.
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 previousConfig |
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, 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 six rules specific to scaling configuration. 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) |
| Autoscaler missing | GCP (MIG) |
| Scaling target too high (> 90%) | All providers |
| Scaling target too low (< 30%) | All providers |
| Cooldown too short (< 120s) | All providers |
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?”
Resource group targeting
You can target an autoscaler policy at a resource group (Advanced mode in the wizard). ZopNight expands the group at apply time and writes one cloud-side policy per member. Group membership changes don’t automatically re-apply; re-apply explicitly when you want new members covered.