# Autoscaling

> VM and container autoscaling for ASG, VMSS, MIG, and ECS; with quick setup, smart defaults, and a safe adopt-or-replace flow.

Source: https://zop.dev/docs/zopnight/optimization/autoscaling

---

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 page listing autoscaling policies with target, mode (Monitor), instance range, and Active / Paused / Failed status, each with Pause, Resume, Detach, and Archive actions](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/aed33728-961c-4b19-8aea-665f3063f63d-autoscaling.png)

*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.

**Warning**

Replace **refuses** (with zero AWS mutation) on three policy shapes that ZopNight can't reconstruct exactly:

1. `PolicyType=PredictiveScaling`
2. `PolicyType=StepScaling` with more than 2 step adjustments
3. Customised metric specs with metric math or more than 1 dimension

If your target has one of these, you can still **Adopt** the existing policy, but Replace returns the refusal error.

## 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](https://zop.dev/docs/zopnight/optimization/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.