Outcome
By the end of this lesson, you will be able to configure Replace, understand what gets saved for restore, and execute a successful Remove that re-creates each saved policy.
| Prerequisites | M2.5.L1 · M2.5.L2 |
| Time | 9 minutes |
1. Concept
Replace is the takeover, and you ask for it in as many words.
On an ECS service, ZopNight copies down the existing policies, deletes them, and puts its own policy in place. The copy is kept, so that removing ZopNight later re-creates what it found. On an Auto Scaling group it is gentler: your policies stay where they are, ZopNight adds its own zopnight- policies, and Remove takes those out and restores the group’s min, max and desired capacity.
REPLACE GUARANTEE: ECS: save each existing policy as a typed request, delete them, create ZopNight's policy; Remove re-sends the saved requests to re-create them ASG: leave customer policies in place, add ZopNight's; Remove deletes ZopNight's policies and restores min/max/desired Scheduled actions are never captured or re-createdThe saved restore state is the safety net. Replace becomes safe because Remove always works.
What happens during Replace
REPLACE WORKFLOW:
1. Customer picks Replace in the Create form2. ZopNight calls cloud API to read the current config: - Scalable target settings (min/max) - All scaling policies (target tracking, step scaling)
3. ZopNight evaluates "reconstructibility" (ECS): Can each policy be re-created from ZopNight's typed saved request without losing settings? See L4 for the three refusal shapes; any scheduled action on the target is a fourth refusal
4. If reconstructible: Save previousConfig.existingPolicies (one typed PutScalingPolicy request per policy) ECS: delete user's existing scaling policies via cloud API ASG: leave the user's policies in place Create ZopNight's policy (target tracking with smart defaults) Track as source=recommended
5. If NOT reconstructible: Apply fails with the reason None of your scaling policies are deleted User must use Adopt insteadThe reconstructibility check is the safety gate. Some configs can’t be perfectly restored; ZopNight refuses to take risk.
What gets saved for Remove
previousConfig CAPTURED AT REPLACE TIME (ECS):─────────────────────────────────────────────────────────{ "scalableTargetExists": true, "minCapacity": 4, "maxCapacity": 12, "existingPolicies": [ { "PolicyName": "scale-out-cpu", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": {...} }, { "PolicyName": "scale-in-after-hours", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": {...} } ]}Each entry in existingPolicies is a typed request that re-creates one of your policies, built from what AWS returned when ZopNight read it. Remove re-sends each one. The policy comes back with the same name and the settings ZopNight’s model holds, but AWS sees a new policy (a new ARN), so this is a re-creation, not a byte-for-byte copy. Scheduled actions are not saved: if the target has any, Replace is refused instead.
What ZopNight creates instead
NEW POLICY on stripe-payments-asg-1─────────────────────────────────────────────────────────Target trackingCPU 65%, min 3, max 15, cooldown 300sPolicy name: "zopnight-<first 8 chars of policy id>-stripe-payments-asg-1-trigger-0"A single, simple target-tracking policy by default. The team can later customize via Edit.
Remove: the inverse
REMOVE WORKFLOW:
1. Customer clicks Remove on a replaced policy2. ZopNight retrieves previousConfig.existingPolicies3. Cloud API calls, in this order (ECS): - Delete ZopNight's policies (zopnight-...) - Restore the scalable target's saved min/max - Re-send each saved request to re-create your policies On an ASG: delete ZopNight's policies and restore the saved min/max/desired4. ZopNight's tracking record is archived
OUTCOME: Your policies are back, by name and settings Each is a new policy object to AWS (new ARN) ZopNight's own policies are goneA re-creation from saved requests, not a bit-for-bit copy: the settings ZopNight’s typed model holds come back, which is exactly why the shapes it cannot hold are refused up front.
Idempotent restore
Remove can be safely re-run. If it failed mid-way (e.g., cloud rate-limited), retrying picks up from where it left off:
REMOVE retry behavior:
Step 1: Delete ZopNight policy → succeeded Step 2: Restore scalable target min/max → succeeded Step 3: Re-create first saved policy → FAILED (rate limit)
Retry: Step 3: Re-create first saved policy → succeeded (this time) Step 4: Re-create second saved policy → succeeded
Final: restore complete
Saved config preserved across retries No risk of double-restoration Idempotent designThe idempotency = safe to retry; no partial-state corruption.
Pre-Replace safety check: reconstructibility
Before any cloud mutation, ZopNight runs the reconstructibility check:
RECONSTRUCTIBILITY CHECKS:
CHECK 1: Predictive scaling policies If any policy has policy_type = "PredictiveScaling" → refuse Replace (ZopNight's typed saved request has no predictive-scaling fields)
CHECK 2: Step scaling with >2 step adjustments If a step scaling policy has more than 2 step adjustments → refuse (the typed restore state models only two adjustments, scale-out and scale-in, so a third would be lost on Remove)
CHECK 3: Customized metrics with multiple dimensions If a target tracking policy uses a customized metric with metric math or >1 dimension → refuse (The metric specification is complex enough that restoration risks subtle behavior changes)
IF ANY CHECK FAILS: Refuse with explanation Suggest Adopt instead Zero AWS mutationThree refusals: explored in detail in L4. The refusals are pessimistic guards against subtle restore failures.
When Replace is the right call
SCENARIO RECOMMENDATION─────────────────────────────────────────────────────────────Existing config is broken Replace
Migrating from another autoscaler tool Replace
Team wants ZopNight as canonical source Replace
Existing config is fine, just observe Adopt
Risk-averse, want to be conservative Adopt
Compliance requires deliberate change Replace (documented)
Workload is non-prod Replace OK
Workload is critical prod Adopt first, Replace later When trust built
Existing config triggers reconstructibility refusal Must use Adopt Replace refusedThe path is contextual. Replace when ownership clarity matters; Adopt when preservation matters.
Risk model: what could go wrong
LOW RISK during Replace: Cloud API rate limits Transient errors (retried automatically)
MEDIUM RISK: Cloud-side state changing during the Replace operation
LOW RISK due to design: Lost previousConfig (saved before any mutation) Partial-state corruption (idempotent retry) Unrecoverable state (saved requests re-create each policy)
MITIGATIONS: Run during planned change windows for production workloads Have rollback path tested (Remove → verify) Monitor first hour after Replace for unexpected behaviorThe Replace flow is safe in practice. The reconstructibility check + saved config + idempotent restore handle the failure modes.
2. Demo
A team replacing legacy scaling on a critical workload:
SCENARIO: ECS service has 2-year-old CloudFormation scaling config Team is unsure exactly what it does Wants ZopNight to manage it cleanly
T+0 Open the Create form. Pick Replace.T+5s ZopNight fetches existing config: - 1 target tracking policy (CPU 60%) - 1 step scaling policy (2 step adjustments) - no scheduled actions (any would refuse Replace)
T+5s You keep "Our smart recommendation" selected, save, and press Apply. There is no separate confirmation dialog: choosing Replace and applying is the requestT+10s Reconstructibility check passesT+15s Cloud API calls: Delete existing policies (2 calls) Create new ZopNight policy
T+30s Validation: confirm new state on cloud-sideT+30s Replace complete. Source = recommended Policy is now ZopNight-managed
LATER: team needs to roll back
T+0 Remove triggeredT+15s Delete ZopNight's policyT+20s Restore min/max; re-create existing policies (2) by re-sending the saved requestsT+25s Check in the AWS console: both policies back by name, with their settings
OUTCOME: Replace + Remove = full reversibility Engineer confidence: high Audit trail: completeReplace + Remove = full reversibility. The safety net makes Replace acceptable.
3. Hands-on (5 min)
In a sandbox, walk through Replace:
□ STEP 1: Set up existing scaling on a sandbox ECS service Confirm: it has at least one scaling policy and no scheduled actions
□ STEP 2: Create policy via Replace Create form detects existing config Pick Replace Save, then press Apply
□ STEP 3: Inspect what got saved Open the new policy View previousConfig Check there is one saved request per policy you had (name, type, target value)
□ STEP 4: Test Remove Click Remove on the new policy Watch the cloud-side restore Check each saved policy was re-created
□ STEP 5: Verify reversibility Compare current cloud-side state to original Same policy names and settings; new policy ARNsA 15-minute exercise builds confidence in the reversibility.
4. Knowledge check
Q1
What gets saved during Replace?
A. A typed request per existing policy plus the capacity bounds, in previousConfig
B. Only the policy names, kept purely for reference when the change is later reviewed by somebody on the platform team later
C. Just min/max
D. A snapshot
Show answer
Correct: A. Saved before any cloud mutation, so restore is always possible. Scheduled actions are not saved, which is why ECS refuses Replace when any exist.
Q2
A team runs Remove on a replaced policy. The cloud-side state after Remove:
A. Empty, with no scaling configuration left behind on the target resource
B. Mixed
C. Modified
D. Your policies re-created from the saved requests, with the saved capacity bounds
Show answer
Correct: D. Remove re-sends each saved request, so your policies come back by name and settings (as new policy objects to AWS). The whole point of Replace is that Remove reverses it.
Q3
A Replace operation fails on cloud API after the first deletion. The cloud-side is now inconsistent. What does ZopNight do?
A. Discard the saved config
B. Crash
C. The saved previousConfig.existingPolicies is preserved
D. The saved config is cleared out on any such failure
Show answer
Correct: C. The operator can retry Remove (or Replace) to either: restore via Remove using saved config, or proceed with Replace from the partial state. Saved config is preserved; retries are idempotent.
5. Apply
Replace flow is in Automate → Auto Scaling → + Create Autoscaling Policy → the Create form detects existing config. Pick Replace. Remove restores via the same surface.
For your team: use Replace when taking ownership; trust the saved-config safety net.