Outcome
By the end of this lesson, you will be able to adopt an existing cloud-side scaling configuration without mutation, verify that no cloud-side changes occurred, and migrate to ZopNight management when ready.
| Prerequisites | M2.5.L1 |
| Time | 9 minutes |
1. Concept
Adopt changes nothing at all.
ZopNight reads the policy that is already there, shows you what it says, and tracks it from then on. The policy in your cloud account is left byte for byte as it was.
ADOPT GUARANTEE: Zero cloud-side mutation during adoption Existing scaling continues as before ZopNight observes; doesn't act Customer can audit before / after; state unchangedAdopt is the safe starting point for any existing scaling configuration. It is advice, not a form default: the Create form preselects the recommendation.
What happens during adopt
ADOPT WORKFLOW:
1. Customer picks Adopt in the Create form2. ZopNight reads the current scaling configuration from the cloud API so the form can show it3. Nothing is captured for restore: the saved state records only source = adopted (no previousConfig snapshot, no copy of your policies)4. ZopNight creates a tracking record with: source = adopted target = the cloud-side target min, max, target, cooldown = current values mode = autopilot on a read-write account, recommend on a read-only one (nothing special for adopted)5. NO cloud API mutations. Cloud-side state unchanged.6. Customer sees the policy in the Autoscaler pageNothing needs restoring later because nothing was changed. That is why Remove on an adopted policy is a no-op.
What gets stored
ADOPTED POLICY: stripe-payments-asg-1─────────────────────────────────────────────────────────Source: adoptedCloud target: stripe-payments-asg-1 (ASG)Last seen: 2026-05-20T08:00:00ZMode: autopilot (read-write account default)
CURRENT CLOUD-SIDE CONFIG: Scalable target: min 4, max 12, desired 6
Scaling policies: "scale-out-cpu": Target tracking, CPU 60% "scale-out-step-1": Step scaling, alarm thresholds "scheduled-action-1": Scheduled action, weekday 8 AM
SAVED RESTORE STATE: { "source": "adopted" } (nothing else)The current config is what ZopNight read from the cloud, shown for context. The saved restore state holds only the adopted marker: there is no snapshot of your policies, because Remove on an adopted policy never touches the cloud and so has nothing to restore.
What the customer sees in the UI
AUTOSCALER PAGE: stripe-payments-asg-1───────────────────────────────────────────────────────── Provider: aws Target: ASG: stripe-payments-asg-1 Source: adopted ← key indicator Mode: autopilot
ZopNight knows this policy exists but does not modify it.The “adopted” badge is prominent. There is no ambiguity about ownership.
Recommendations on adopted policies
ZopNight’s recommendations still run on the cloud resources behind adopted policies. The target and cooldown rules (RC-ASC-004, RC-ASC-006) are registered only on Azure VMSS; an AWS ASG gets neither:
RECOMMENDATIONS for web-vmss-1 (adopted Azure VMSS)─────────────────────────────────────────────────────────RC-ASC-004 Scaling target too high (>90%) Current target: 90% Suggested target: 70%
Why: scaling triggers at saturation; latency suffers
[Dismiss][Snooze]The recommendation is raised on the scale set, not on the ZopNight policy, so no button applies it. To act on it, edit the adopted policy: the edit auto-promotes it to recommended, and the cloud changes only after you re-apply.
When to use Adopt
SCENARIO USE ADOPT?─────────────────────────────────────────────────────────Existing config from Terraform/CFN YES (preserve IaC)
Existing config from console YES (preserve manual setup)
Config from another scaling or FinOps tool YES (don't disrupt them)
Config seems well-tuned YES (don't second-guess)
New workload; no existing config NO (skip adopt; create direct)
Recently-changed config; team uncertain YES (observe before acting)
Config seems broken or outdated Maybe (consider Replace instead)Start with Adopt for any non-trivial existing config.
Removing an adopted policy
REMOVE on adopted policy = effectively no-op:
1. Customer clicks Remove on an adopted policy 2. ZopNight has nothing to undo (no cloud mutations performed) 3. Tracking record deleted from ZopNight 4. Cloud-side state remains exactly as it was
EFFECTIVELY: "stop tracking this" Cloud-side scaling continues as before ZopNight no longer shows the policy Reversible: re-adopt anytimeAdopt is cheap to undo; that’s part of its safety.
Auto-promote flow recap
When editing an adopted policy, the source auto-promotes:
Editing adopted policy:
T+0 Adopted: target 60% T+5s User clicks Edit; changes target to 65% T+5s Source promoted silently; policy now recommended T+5s UI shows a re-apply banner T+15s User clicks Re-apply T+30s Cloud-side updated to target 65%
ONE-WAY TRANSITION: Once recommended, stays recommended Don't accidentally edit adopted policies you want to keep as adoptedThe auto-promote is explicit; documented in audit log.
Cost-impact recommendations for adopted
ZopNight provides cost-impact analysis even on adopted policies:
COST IMPACT for adopted policy (analytical view):
Estimated cost from current config: $1,200/mo Estimated cost if target were 65%: $920/mo Potential savings: $280/mo
Scaling pattern analysis: 47 scaling actions in past month (high; due to aggressive target) Average instances: 5.8 (vs theoretical optimal 4.2) Latency impact: minimal (target is high; not at saturation often)
Recommendation: tune target to 65% for cost savings + lower churnThe analysis is non-actionable in adopt mode but informative. Customer can choose to act.
2. Demo
A team adopting all existing scaling on day one:
T+0 Team has 47 ASGs across prod and non-prod Each with existing cloud-side scaling from CloudFormation
T+5 min Team's onboarding playbook: adopt all existing configurations For each ASG: Create policy → wizard detects existing config → Adopt
ZopNight tracks 47 policies, all source=adopted Zero cloud-side mutations
T+1 MONTH: Team reviews the adopted configs by hand (the target and cooldown rules run only on Azure VMSS, not on ASGs): 12 ASGs have target too high (>90%) 8 have cooldown too short 5 have step scaling that's poorly tuned The rest: configured well
T+2 MONTHS: Team works through the list For each, editing an adopted policy auto-promotes to recommended Tests the change in staging first; then production
T+3 MONTHS: 32 ASGs now ZopNight-recommended (managed) 15 still adopted (no changes needed; well-tuned originally)
RESULTS: Cost savings: ~$8K/mo across the optimized 32 policies Latency: improved (less scaling churn) Trust built: zero incidents from auto-management Team comfortable with ZopNight ownershipThe adopt-then-edit pattern is the standard onboarding pattern for teams with existing scaling.
3. Hands-on (5 min)
In a sandbox with existing cloud-side scaling:
□ STEP 1: Adopt one policy Trigger Create on a target with existing scaling Pick Adopt Save, then press Apply (no cloud change for adopted)
□ STEP 2: Verify zero cloud-side change Compare cloud-side config before and after Should be identical (Adopt changes nothing)
□ STEP 3: Check the policy detail Source: __________ (should be "adopted") Mode: __________ Recorded as adopted (no rollback snapshot): □ Yes □ No
□ STEP 4: Review recommendations (if any) Recommendations for this policy: _____ Action available: __________
□ STEP 5: Plan future transition Will you re-evaluate in 30 days? □ Yes Edit policy to take ownership? __________ (when)A 10-minute exercise reveals the adopt flow’s safety.
Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. A group that already has cloud-native scaling on it: an ASG with a scaling policy, a MIG with an autoscaler, or a VM Scale Set rule.ASK "What scaling policies already exist here, and adopt the one on this group."CHECK that adopt did not replace. The three refusals in L4 apply to an assistant exactly as they apply to you.Tools behind it: list_cloud_scaling_policies (read, Operate), create_autoscaler_policy with source set to adopted (write, tier 2). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
What cloud API mutations happen during Adopt?
A. ZopNight modifies the policies
B. Zero: Adopt is “observe only.” The cloud-side state is unchanged
C. ZopNight creates a copy
D. ZopNight deletes and then recreates every single one of them
Show answer
Correct: B. ZopNight reads the config to show it, records the policy as adopted, and never mutates. This is the architectural guarantee that makes Adopt safe. Zero mutation is the design.
Q2
Removing an adopted policy:
A. No-op for cloud-side state (nothing was changed); only deletes the ZopNight tracking record
B. Restores the original cloud configuration that was captured back at the adopt time
C. Deletes the policy
D. Triggers an error
Show answer
Correct: A. Adopt was no-op; Remove is no-op too. Cloud-side scaling continues as it was, and there is no saved snapshot to restore (B describes something Adopt never captures).
Q3
Adopted policy recommendations are:
A. Auto-applied
B. Hidden
C. Advisory: the user sees the recommendation
D. Suppressed entirely while it stays adopted
Show answer
Correct: C. Acting on it means editing the policy, which auto-promotes it to recommended; the cloud changes only after the user re-applies. ZopNight never modifies adopted policies without explicit consent. Advisory only, requires explicit user action.
5. Apply
The Adopt wizard option is in Automate → Auto Scaling → + Create Autoscaling Policy. Source = adopted shows on the policy detail page.
For your team: start with Adopt for any existing scaling; review monthly; transition to Recommended when ready.