Outcome
By the end of this lesson, you will be able to recognize the three policy shapes that block Replace, diagnose why each can’t be reconstructed, and choose the right alternative (Adopt vs manual cleanup).
| Prerequisites | M2.5.L1 - L3 |
| Time | 9 minutes |
1. Concept
Replace only goes ahead when ZopNight can re-create each of your policies from a typed saved request without losing settings.
On an ECS service, three kinds of policy cannot be restored reliably from what AWS gives back when you read them. For those three, Replace is refused rather than attempted, and none of your policies is deleted. On an Auto Scaling group there is no refusal: ZopNight adds its own policies next to yours and only marks these shapes as not editable.
THE THREE REFUSALS: 1. PredictiveScaling policy type 2. StepScaling with >2 step adjustments 3. Customized metric specs with math or multiple dimensions
PURPOSE: avoid silent restoration drift; safety architectureThe refusals are pessimistic: better to refuse than risk a bad restore.
There is also a fourth ECS refusal that is not about policy shape: if any scheduled action exists on the scalable target, Replace is refused. Scheduled actions are not captured, so deleting the policies would leave them dangling. Remove them in AWS first, or pick Adopt.
Refusal 1: PolicyType = PredictiveScaling
WHY REFUSED: On Remove, ZopNight re-creates your original policies from its own typed restore model
That model has no fields for predictive scaling Deleting the policy and re-creating it would silently lose its configuration
REFUSAL MESSAGE: "cannot replace: pre-existing policy <name> on <service> uses PredictiveScaling, which ZopNight cannot recreate on Remove. Delete it manually in the AWS console or pick Adopt instead"
ALTERNATIVE: Adopt, or delete the predictive policy yourself first.ZopNight’s restore model has no predictive-scaling fields, which makes it un-reconstructible.
Refusal 2: Step Scaling with >2 step adjustments
WHY REFUSED: ZopNight's typed restore state models only two adjustments (scale-out and scale-in) Restoring a policy with 3+ steps would collapse it to two on Remove, silently losing the step ladder ZopNight refuses Replace on these
EXAMPLE OF PROBLEMATIC POLICY: policy_type: StepScaling step_adjustments: - lower: 0, upper: 25, scaling: +1 - lower: 25, upper: 50, scaling: +2 - lower: 50, upper: 75, scaling: +3 - lower: 75, upper: 100, scaling: +5 - lower: 100, upper: null, scaling: +8
(5 step adjustments; ZopNight refuses Replace)
REFUSAL MESSAGE: "cannot replace: pre-existing policy <name> on <service> uses StepScaling with 5 step adjustments, but ZopNight's typed restore state only models 2 (scale-out + scale-in). Recreating it on Remove would silently lose adjustments. Delete the policy manually in the AWS console or pick Adopt instead"
ALTERNATIVE: Adopt; OR manually convert to target tracking + a single step, then Replace.Two adjustments in, two adjustments out: anything more cannot survive the round trip.
Refusal 3: Customized metric specs
WHY REFUSED: Target tracking can use a customized metric
If that customized metric has: Metric math (combining multiple metrics) More than one dimension
ZopNight's typed restore model holds one simple metric with no metric-math support, so either shape would be flattened on Remove
ZopNight refuses Replace here
EXAMPLE: Customized metric: Metric math: (RequestCount / Latency) * Errors Dimensions: 3 (region, environment, version)
Restoring this exactly is fragile
REFUSAL MESSAGE: "cannot replace: pre-existing policy <name> on <service> uses a customized metric specification with metric math (Metrics field), which ZopNight's typed AutoscaleTrigger does not model. Recreating it on Remove would lose the metric expression. Delete the policy manually in the AWS console or pick Adopt instead" (a similar message covers more than one dimension)
ALTERNATIVE: Adopt; OR replace the customized metric with a simpler target tracking policy before Replace.A single-metric model cannot hold metric math or extra dimensions, so a restore would flatten them.
What happens at Replace time
REPLACE PROCESS WITH RECONSTRUCTIBILITY CHECK:
1. Wizard offers Adopt or Replace; you pick Replace and apply2. At Apply, the reconstructibility check runs against each policy For each policy: Check predictive scaling Check step adjustments count Check customized metric complexity Then: check for scheduled actions on the target
3. IF ANY CHECK FAILS: The Apply fails with the reason None of your scaling policies are deleted
4. IF ALL CHECKS PASS: Replace proceeds Saved + executed normally
USER EXPERIENCE: Sees the Apply fail Sees the specific reason Picks: Adopt, or manual cleanup, or cancel Existing scaling policies stay in placeThe check is automatic; the explanation is concrete.
The editable=false flag
For policies in the three refusal categories, the UI marks them editable=false:
POLICY: legacy-step-policy-with-5-steps─────────────────────────────────────────────────────────Source: adoptedEditable: false (step scaling with 5 adjustments)
The Edit button is hidden. You can: Observe this policy (Adopt mode) Remove it (cloud-side state unchanged since Adopt didn't mutate)
WHY editable=false: Editing would trigger auto-promote to recommended Recommended requires that Remove can re-create the policy But this policy can't be reconstructed So editing isn't allowed
WORKAROUND: Simplify the cloud-side policy manually Then re-Adopt (or re-Replace if reconstructibility now passes)The flag protects against accidental ownership changes that would create unsafe state.
Why so conservative
THE COST OF A BAD RESTORE:
Predictive scaling restored without its settings: Forecast-driven scaling lost Could under-provision during forecasted peak Customer impact: latency, errors
Step scaling restored with drift: Actions fire at wrong thresholds Could over-scale or under-scale Customer impact: cost overrun or saturation
Customized metric restored incorrectly: Scaling driven by wrong metric Could under-respond to real load Customer impact: variable; potentially severe
REVERSIBILITY IS THE CONTRACT REPLACE MAKES If reversibility can't be guaranteed, the contract is void Better to refuse than break the contractThe conservative posture builds trust through guaranteed safety.
Workarounds
SHAPE WORKAROUND──────────────────────────────────────────────────────────Predictive scaling Adopt only Cannot upgrade to Replace without recreating cloud-side
Step scaling with >2 steps Manually consolidate the steps in the cloud console first (down to 2) Then Replace
Customized metric with math Replace the cloud-side metric with a simpler target tracking policy (single CloudWatch metric; no math) Then Replace via ZopNightIn all cases, the workaround requires manual cleanup in the cloud console before Replace.
How to plan migrations from refused policies
SCENARIO: customer wants to take ZopNight ownership of a predictive scaling policy that's been refused
OPTIONS:
OPTION 1: stay with Adopt Pros: zero work; observation continues Cons: ZopNight can't optimize this policy Default: this is fine if the policy is well-tuned
OPTION 2: replace the predictive scaling with target tracking Steps: 1. In cloud console: delete predictive scaling policy 2. In cloud console: create target tracking policy 3. In ZopNight: trigger Replace (now passes reconstructibility) 4. ZopNight manages target tracking going forward Pros: ZopNight ownership; cleaner setup Cons: temporary period without predictive scaling
OPTION 3: hybrid (not possible on ECS) Keeping the predictive policy and adding a ZopNight one runs the Replace path again, which would delete every existing policy and is refused by Refusal 1 (On an Auto Scaling group ZopNight policies sit alongside yours, but there nothing is refused in the first place)The right path depends on the workload’s actual needs.
2. Demo
A team encountering a refusal:
T+0 Wizard for an ECS service with step scaling: 5 step adjustments
T+5s Reconstructibility check runs: Predictive scaling: not present ✓ Step scaling with >2 steps: PRESENT (5 steps) ✗
T+5s Replace REFUSED
T+5s Wizard shows: "Step scaling policy with 5 step adjustments cannot be reliably restored. Choose: - Adopt (observe only) - Cancel - [Reference: simplify the step structure manually first]"
T+10s Customer picks Adopt Policy tracked as adopted Cloud-side unchanged (zero mutation)
LATER (3 months): Customer reviews adopted policy Decides: "I want ZopNight to manage this"
Customer simplifies the step structure in CloudFormation: Was: 5 step adjustments Now: 2 step adjustments
Customer re-triggers Replace Reconstructibility check passes (2 steps ≤ 2; passes)
T+5 min Re-Replace: succeeds Source flips to recommended ZopNight manages the policy going forward
OUTCOME: Refusal protected against silent risk Customer chose deliberately when to upgrade Cloud-side restoration capability preserved throughoutThe refusal protects against silent risk. The customer chose deliberately when to upgrade.
3. Hands-on (5 min)
Identify reconstructibility issues in your estate:
□ STEP 1: Open ECS services with autoscaling
□ STEP 2: Check each for refusal triggers Predictive scaling? Yes/No Step scaling steps count: _____ Customized metric? Yes/No
□ STEP 3: Classify each Replaceable (passes all checks): _____ Refused (one or more check fails): _____
□ STEP 4: Plan for refused policies Stay adopted (no work needed): _____ Simplify and replace later: _____ (which ones)
□ STEP 5: Schedule simplification work (if planned) Owner: __________ Target completion: __________A 10-minute audit reveals the refusal landscape.
4. Knowledge check
Q1
A policy with predictive scaling. Can it be Replaced?
A. No: predictive scaling cannot be re-created from the saved request
B. Yes
C. Only on AWS
D. Yes, but only with an explicit confirmation step first
Show answer
Correct: A. Refusal #1. ZopNight’s restore model has no predictive-scaling fields, so it could not re-create the policy on Remove. Use Adopt, or delete the predictive policy yourself first.
Q2
A step scaling policy has 2 step adjustments. Can it be Replaced?
A. No
B. Yes: 2 adjustments are within the bound. ≥3 is refusal #2
C. Only adopted
D. Yes, after downgrading it to a simpler step policy
Show answer
Correct: B. Customer can Replace this normally. 2 adjustments is fine; 3+ triggers refusal #2.
Q3
A target tracking policy uses a customized metric that combines RequestCount and Latency via metric math. Can it be Replaced?
A. No: refusal #3 (customized metric with math)
B. Yes
C. With confirmation
D. Yes, provided the metric math is simple
Show answer
Correct: A. Use Adopt, or simplify the metric first (single CloudWatch metric, no math). A single-metric saved request cannot hold it, so Remove could not re-create it. Refusal #3.
5. Apply
The reconstructibility check runs automatically. Refusals show up as a failed Apply with the reason. Editable=false flag visible on policy detail pages.
For your team: classify your policies; understand which fall into refusal categories; plan workarounds for the ones you want to migrate.
Module quiz
Complete M2.5 → 10-question module quiz.