Outcome
By the end of this lesson, you will be able to explain what a policy’s mode records, pick Autopilot or Manual for a workload, and know who presses Apply and what does the scaling.
| Prerequisites | M2.4.L1 - L3 |
| Time | 9 minutes |
1. Concept
Every autoscaler policy carries a mode field with one of three values: monitor, recommend or autopilot.
The most important fact about mode is what it does not do. The backend never branches on it. No mode makes ZopNight scale anything, and no mode stops Apply from working. Mode is a record of intent: who is expected to press Apply on this policy.
WHAT ACTUALLY HAPPENS, IN EVERY MODE────────────────────────────────────────────────────────────────────1. You create the policy Stored in ZopNight as a draft. Nothing is written to the cloud.2. Someone presses Apply ZopNight queues an apply for the executor, which writes the policy to the ASG, VMSS, MIG or ECS service.3. The cloud's own autoscaler It reads its metrics and adds or does the scaling removes instances. ZopNight is not in that loop.There is no ZopNight scaling loop sitting behind autopilot. After Apply, the scaling you see is the cloud provider’s native autoscaler following the rules ZopNight wrote.
The three values
MODE SHOWN AS HOW A POLICY GETS IT────────────────────────────────────────────────────────────────────autopilot "Autopilot" Picked in the form; the default on read-write accountsrecommend "Manual" Picked in the form, or forced when the cloud account is read-onlymonitor by account* API or MCP only; the form does not offer it and it is never auto-derivedThe form’s “Scaling mode” section offers two cards, Autopilot and Manual. Its prompt is “Choose who applies scaling decisions on this resource”, which is the right way to read the field.
What mode changes, and what it does not
BEHAVIOUR autopilot recommend monitor────────────────────────────────────────────────────────────────────Smart-default suggestions Yes Yes YesApply button on a draft policy Yes Yes YesApply writes the policy to cloud On click On click On clickZopNight scales by itself No No NoSaving an edit that changes cloud Re-applies Re-applies Re-applies settings (min, max, triggers...)Badge on the policy card Autopilot Manual By account*
* A monitor-mode policy's badge follows the cloud account's permission: a read-write account shows "Autopilot" and a read-only account shows "Manual". "Monitor" appears only when the permission level is unknown.Two moments push to the cloud: pressing Apply, and saving an edit that changes a cloud-relevant field (min, max, desired capacity, cooldown, scaling mode or triggers). The edit drawer’s save chains into an apply in that case, whatever the mode. A rename alone, or a mode change alone, never touches the cloud.
The Autopilot card’s copy says ZopNight “applies scaling on this resource automatically”. Read that as “the cloud autoscaler scales automatically once this policy is applied”. Apply itself is still a click.
Read-only accounts
The cloud account’s permission level is the one thing that really constrains behaviour, and it acts on Apply, not on mode:
READ-WRITE ACCOUNT Create: mode defaults to autopilot if you leave it empty Apply: allowed
READ-ONLY ACCOUNT Create: mode is forced to recommend, whatever was requested Form: the Autopilot card is greyed out with "This account is read-only, switch to a read-write account to enable Autopilot" Apply: blocked by the backend with a 403, and the executor also rejects write intents from read-only accounts Card: shows "Manual" and a "Read-only account" badgeIf the permission check itself fails, Apply is blocked too (fail closed), rather than letting a write through for an account that may be read-only.
Nothing upgrades on its own. When an account gains write access, existing policies keep recommend until someone edits them and picks Autopilot.
Mode is per policy
Each policy has its own mode, so one team can mix them:
POLICY MODE WHY────────────────────────────────────────────────────────────────────prod-api-asg autopilot Owning team applies its own editspayments-batch-asg recommend Change board signs off each Applydev-experiment-asg autopilot Low risk, fast iterationlegacy-reporting-vmss recommend Account connected read-onlyThe mode badge on each policy card makes “which policies need a human sign-off?” answerable at a glance.
Picking a mode
CHOOSE AUTOPILOT WHEN CHOOSE MANUAL WHEN────────────────────────────────────────────────────────────────────The team that edits the policy is A separate approver must press trusted to push its own changes Apply (change board, SRE review)Edits should land in the cloud as You want the policy staged as a soon as they are saved draft and applied laterThe account is read-write The account is read-only (forced)Because the backend treats both the same, this is a team-process decision. If you need a real control on who can write to the cloud, use the levers that are enforced: the cloud account’s permission level, and the roles that decide who can update policies at all.
Changing mode
STEPS: 1. Automate → Auto Scaling, open the policy 2. Edit it 3. Select Autopilot or Manual 4. Save
EFFECT: The mode field changes; nothing is pushed to the cloud An "update" row is written to the policy's event log (L6) An already-applied policy keeps scaling exactly as before To stop cloud scaling, Remove the policy (L5)Switching to Manual is not an off switch. Neither is Pause (L5). Only Remove takes ZopNight’s rules out of the cloud.
Mode and adopt-or-replace
Mode is also not what decides whether an existing cloud policy is kept. The policy’s source field does (M2.5):
source = adopted Your existing cloud config is kept; Apply records it and makes no cloud changesource = recommended Apply writes ZopNight's config, replacing what was there, and saves the old config so Remove can restore itNothing is replaced without an Apply, in any mode.
Misreadings to avoid
MISREADING REALITY────────────────────────────────────────────────────────────────────"Autopilot means ZopNight scales" The cloud autoscaler scales, after Apply, in every mode"Manual stops scaling" Mode never touches the cloud; use Remove"Monitor is a safe observe-only stage" Monitor is a label; Apply still works on a monitor policy"Start in monitor, graduate to autopilot" There is no ladder; pick the mode that matches who presses Apply"Read-only accounts can observe in Read-only accounts get monitor mode" recommend, and Apply is blocked2. Demo
A platform team sets up two policies in one afternoon.
POLICY 1: checkout-asg (regulated payments workload, read-write account) Change policy: every cloud change needs a change-board ticket.
Create in Quick Setup → Scaling mode: Manual → Create Policy saved as a draft; card badge "Manual" Event log: create, completed, actor = sre-lead@
Change board approves ticket CHG-4412 two days later Approver opens Automate → Auto Scaling → checkout-asg → Apply Event log: apply, queued, actor = approver@ Event log: status_update, completed (executor callback, previousConfig captured for Remove) From here the ASG's own target-tracking policy scales the group.
POLICY 2: search-indexer-asg (internal tool, read-write account) Create in Quick Setup → Scaling mode: Autopilot (the default) Owning engineer presses Apply straight away A week later they raise max from 6 to 8 and save: The drawer saves and chains into an apply Event log: update, then apply, then status_update completed
POLICY 3 (attempted): reporting-vmss on a read-only Azure account Autopilot card greyed out; mode forced to Manual Apply returns "cloud account has read-only permissions" Fix: connect the subscription with write access, then edit the policy and press ApplySame backend path for both working policies. The only difference is who was expected to press Apply, and the mode badge makes that visible to everyone reading the list.
3. Hands-on (5 min)
Audit the modes on your policies:
□ STEP 1: Open Automate → Auto Scaling
□ STEP 2: For each policy, note mode badge and account access Policy: __________ Mode: ________ Read-only badge? __ Policy: __________ Mode: ________ Read-only badge? __ Policy: __________ Mode: ________ Read-only badge? __
□ STEP 3: Check that each mode matches your process Autopilot where the owning team pushes its own changes? □ Manual where someone else must approve each Apply? □
□ STEP 4: Find any policy whose team believes Manual or Pause stops cloud scaling. If it must stop, plan a Remove (L5). Policy: __________4. Knowledge check
Q1
A team connects its AWS account with read-only IAM credentials and creates a policy. What happens?
A. The policy is created in autopilot and Apply runs with reduced scope
B. The policy cannot be created at all until write access is granted
C. Mode is forced to recommend (shown as Manual) and Apply is blocked
D. Mode is set to monitor, which observes and scales without writing
Show answer
Correct: C. Read-only accounts are forced to recommend, and the backend refuses Apply with a 403. Monitor is never auto-derived. Nothing upgrades on its own: grant write access, then edit the policy.
Q2
A policy in autopilot mode has been applied to an ASG. What does the scaling?
A. The ASG’s own autoscaler, following the rules ZopNight wrote at Apply
B. A ZopNight scaling loop that watches metrics and resizes the group
C. The ZopNight executor, which polls CloudWatch every evaluation period
D. Nothing, until a user approves each scale-out in the ZopNight console
Show answer
Correct: A. No mode adds a ZopNight scaling loop. Apply writes the policy to the cloud, and the provider’s native autoscaler scales from then on, in every mode.
Q3
An applied policy’s owner switches its mode from Autopilot to Manual and saves. What changes in the cloud?
A. ZopNight removes its scaling rules and restores the old config
B. The ASG stops scaling until someone presses Apply again
C. Scaling pauses until the next scheduled evaluation window
D. Nothing: mode is not pushed to the cloud, so scaling continues
Show answer
Correct: D. Mode is deliberately excluded from the fields that trigger a re-apply. The event log gets an “update” row, and the applied rules keep scaling. To take them out of the cloud, Remove the policy.
5. Apply
Automate → Auto Scaling → open a policy → Edit → Scaling mode. Pick Autopilot where the owning team pushes its own changes, and Manual where someone else must approve each Apply.
For your team: write down which mode means what in your process, and remember that the enforced controls are account permissions and roles, not mode.
Related lessons
- L1: Scaling policy basics
- L2: Welford stats
- L3: Quick setup
- L5: Lifecycle (next)
- L6: Event log
- M2.5: Adopt or replace