這篇 AWS 機器學習博客討論了在 Amazon SageMaker AI 實時終端節點上使用 Application Auto Scaling 時，CloudFormation 或 AWS CDK 更新配置會失敗的常見問題。問題源於 SageMaker 的要求：在刪除終端節點變體或修改其實例類型前，必須先在 Application Auto Scaling 中註銷對應的可擴縮目標；但一旦在 CloudFormation 之外手動註銷，CloudFormation 就無法繼續跟蹤這些擴縮資源。
文章歸納了三種失敗情形。第一，如果可擴縮目標仍處於註冊狀態就修改終端節點配置，CloudFormation 會先嚐試更新端點，而 SageMaker 會拒絕操作，並提示 AllTraffic 變體必須先註銷為可擴縮目標，之後才能移除或更新實例類型。第二，如果用户通過 AWS CLI 手動註銷目標，然後只修改終端節點配置，部署雖能成功，但 CloudFormation 不會重新註冊擴縮目標，也不會重新應用擴縮策略，因為模板中的擴縮參數沒有變化；結果是端點靜默失去自動擴縮能力。第三，如果手動註銷後又修改擴縮參數，CloudFormation 會嘗試更新已不存在的 ScalableTarget 資源並報錯；更嚴重的是回滾也可能失敗，堆棧進入 UPDATE_ROLLBACK_FAILED 狀態，需要在控制台人工恢復。
解決方案是一個可複用的 CDK construct。它不再直接使用原生 AWS::ApplicationAutoScaling::ScalableTarget 和 ScalingPolicy 資源，而是用三個 CloudFormation 自定義資源，並通過 CDK 的 add_dependency 明確編排順序：先註銷可擴縮目標，再由 CDK 更新終端節點，然後等待端點進入 InService 後註冊可擴縮目標，最後等待目標可查詢後附加目標跟蹤擴縮策略。首次部署時還沒有可擴縮目標，註銷處理程序會捕獲 ObjectNotFoundException 並繼續。
註冊目標和附加策略採用 CDK provider 的異步完成模式。每個自定義資源的 on_event 處理器立即返回，is_complete 處理器則由 provider 的 waiter 每隔約 30 秒重新調用，直到就緒檢查通過。Register Scalable Target 的總超時為 1 小時，Attach Scaling Policy 為 15 分鐘，因此等待不受單次 Lambda 調用超時限制。每個自定義資源還帶有 ConfigHash 屬性；只要端點配置或擴縮參數變化，CloudFormation 就會重新調用相關 Lambda。文章強調，端點配置和擴縮參數必須放在同一個 ConfigHash 中，因為一次哈希變化會驅動整套擴縮編排。
部署後的堆棧並不只有三個 Lambda。每個自定義資源背後都有一個 CDK cr.Provider，provider 框架會生成輔助函數：同步 provider 的 Deregister 增加一個框架函數；異步 provider 的 Register Scalable Target 和 Attach Scaling Policy 各增加 onEvent、isComplete、onTimeout 三個函數，並由 AWS Step Functions 狀態機驅動 waiter。因此，堆棧實際包含三個自定義資源、兩個 Step Functions 狀態機和十二個 Lambda 函數。其中五個資源承載 construct 自身的處理代碼，另外七個由 provider 框架生成；這些函數無需用户維護，但在審查部署資源時應計入。
文章給出了完整演練。用户需要具備 SageMaker AI、Lambda、IAM、Application Auto Scaling 和 CloudWatch 權限的 AWS 賬户，安裝 AWS CDK v2、Python 3.12 或更高版本以及 uv，並準備 S3 中的模型構件和 ECR 鏡像，或使用 SageMaker 內置算法容器。演練先克隆 GitHub 示例倉庫並運行 uv sync，然後在 config/config.yaml 中同時配置 endpoint 和 autoscaling。端點參數對應 CreateModel 和 CreateEndpointConfig API，擴縮參數對應 RegisterScalableTarget 和 PutScalingPolicy API。隨後執行 cdk bootstrap 和 cdk deploy InferenceStack，並用 describe-scalable-targets 與 describe-scaling-policies 檢查可擴縮目標和策略是否註冊成功。
更新測試只需修改 config/config.yaml，例如把實例類型從 ml.m5.large 改為 ml.m5.xlarge，再重新部署；部署完成後再次查詢，確認自動擴縮仍然註冊並反映新值。若已有 CDK 堆棧，可把 sagemaker_autoscaling/constructs/ 目錄複製到項目中，在端點資源旁實例化 SagemakerAutoscalingConstruct，並傳入端點、AutoscalingConfig 以及同時包含端點與擴縮參數的 config_hash。
實現細節方面，Deregister 自定義資源在端點更新前調用 deregister_scalable_target，並針對首次部署沒有目標的情況捕獲 ObjectNotFoundException；CDK 通過 endpoint.node.add_dependency(deregister) 建立依賴。Register Scalable Target 不能只依賴 CloudFormation 認為端點資源已完成，因為可擴縮目標必須在端點進入 InService 後才能註冊；因此它使用異步完成模式，on_event 立即返回，is_complete 持續查詢端點狀態，若狀態為 Failed 則拋出異常。Attach Scaling Policy 同樣等待可擴縮目標可查詢後再應用策略。原文在 Register 處理程序的條件檢查處被截斷，但上述編排邏輯和配置要點已經完整説明了方案。