Orchestrating SageMaker AI endpoint auto scaling with AWS CDK

CDK 部署 SageMaker 端点更新必挂？用 3 个自定义资源编排 deregister/register 自动伸缩

更新 SageMaker AI 实时端点配置会因 Application Auto Scaling 目标未先注销导致 CloudFormation 或 AWS CDK 部署失败；手动注销又会造成失去自动扩缩、找不到资源或回滚失败。AWS 博客用可复用 CDK construct 以 custom resources 替代原生 ScalableTarget 与 ScalingPolicy，按先注销、端点更新、等待 InService 后注册目标、等待可查询后应用 target tracking 策略的顺序自动编排，并用 ConfigHash 将端点与扩缩参数绑定，任何变化都触发重配；首次部署时注销步骤会忽略目标不存在的错误。异步等待由 provider waiter 驱动，注册目标总超时 1 小时，应用策略总超时 15 分钟。用户可克隆 sample-sagemaker-endpoint-autoscaling，在 config.yaml 配置模型镜像、S3 权重、实例类型与容量后部署 InferenceStack，也可把 construct 加入现有栈；更新实例类型后用 CLI 验证，销毁栈会清理端点、Lambda、IAM 和告警。官方称可在单次部署中完成配置与扩缩更新，但栈内会额外生成 provider 框架的 Lambda 与 Step Functions 资源。

1. 13 个 Custom Resource 按依赖序包裹端点更新
2. 2异步 waiter 每 30s 轮询，总超时 1h/15min
3. 3部署后栈含 12 个 Lambda + 2 个 Step Functions

为什么重要　解决 CloudFormation/CDK 更新 SageMaker 端点时 Application Auto Scaling 资源冲突导致的部署失败与回滚卡死问题适合　用 CDK/CloudFormation 管理 SageMaker 推理端点的 MLOps 工程师

来源

aws.amazon.com

发布

2026/10/24

作者

Lauren Eterno