個問題：改 endpoint 就撞牆
用 CloudFormation 或者 AWS CDK（Cloud Development Kit，雲開發套件）部署咗一個 SageMaker AI 實時 endpoint，再改 instance type、instance count 或者環境變數，部署就會失敗。原因係 SageMaker AI 要求你喺改 endpoint 之前先 deregister（註銷）該 scalable target，但一旦你 deregister 咗，CloudFormation 就跟唔到 Application Auto Scaling 嗰資源。
失敗有三種
原blog 列咗三種失敗模式：
自動伸縮仲掛住時改 endpoint：SageMaker AI 喺 CloudFormation 去到 auto scaling 資源之前已經 reject 咗個 update，直接報錯。
手動 deregister 之後只改 endpoint：用 AWS CLI 手動 deregister 完再 redeploy，部署成功，但 CloudFormation 發現 auto scaling 參數冇變，就唔會重新 register scalable target 或者重新套用 scaling policy。endpoint 照常運行，但冇 auto scaling，仲冇任何錯誤提示。呢個係最危險嘅失敗模式——冇嘢報錯，但服務已經冇保護。
手動 deregister 之後再改 auto scaling 參數：CloudFormation 去 update 一個已經唔存在嘅 ScalableTarget 資源，失敗。更麻煩係 rollback 都失敗（UPDATE_ROLLBACK_FAILED），整個 stack 爛咗，要人手入 CloudFormation console 先可以 recover。
解決方案：三個 custom resource 串起嚟
原blog 嘅 CDK construct 用三個 custom resource 取代原本嘅 AWS::ApplicationAutoScaling::ScalableTarget 同 AWS::ApplicationAutoScaling::ScalingPolicy 原生資源，用 node.add_dependency 強制執行順序：
- Deregister（custom resource）：喺 endpoint update 開始之前移除 scalable target。首次部署時 scalable target 仲未存在，handler 會優雅咗處理呢個錯誤然後繼續。
- Endpoint update（CDK 管理）：CDK 正常更新 endpoint 資源。
- Register Scalable Target（custom resource）：等 endpoint 到達 InService 狀態，先 register scalable target。
- Attach Scaling Policy（custom resource）：等 scalable target 可以 query，先套用 target tracking policy。
呢個做法令 endpoint 配置同 auto scaling 參數可以喺一次部署同時更新，唔使人手介入。
阿調搞兩下
呢個係一個非常 practical 嘅部署問題。最恐怖唔係部署失敗報錯，而係「部署成功但 auto scaling 靜默消失」——endpoint 照住運行，但失去伸縮保護，直到流量飆升先發現冇嘢接。呢類「無聲失敗」喺生產環境係最難查嘅。用 custom resource 將 deregister / register 拆開做顯式步驟，加上 dependency ordering，係一個乾淨嘅 IAC（Infrastructure as Code）實踐，都係 AWS 生態入面常見嘅 workaround 模式。
阿調｜深度調教
