用 AWS CDK 编排 SageMaker AI 端点自动扩缩容

在 AWS CDK 或 CloudFormation 中更新 SageMaker AI 实时端点配置（更换实例类型、调整实例数量或修改环境变量）时，部署会失败。原因是 SageMaker AI 要求在更新端点前先注销可扩缩目标，而一旦注销，CloudFormation 就无法继续跟踪 Application Auto Scaling 资源。

三种典型失败路径

第一种：扩缩容仍注册时直接改端点配置。CloudFormation 尝试更新端点，SageMaker AI 直接拒绝，报错提示 AllTraffic 变体必须先作为可扩缩目标从 Application Auto Scaling 注销，才能删除或更新实例类型。

第二种：先用 AWS CLI 手动注销，再只改端点配置重新部署。部署会成功，但 CloudFormation 不会重新注册扩缩容——因为模板里的扩缩容参数没有变化，它不会重新注册可扩缩目标或重新应用扩缩容策略。端点就此在无扩缩容状态下运行，且没有任何报错提示。

第三种：手动注销后同时修改扩缩容参数。CloudFormation 试图更新已不存在的 ScalableTarget 资源，报资源未找到；更麻烦的是回滚也失败（UPDATE_ROLLBACK_FAILED），栈进入损坏状态，需要在 CloudFormation 控制台人工恢复。

解决方案的编排顺序

AWS 给出的做法是用一个可复用的 CDK construct，把原生的 AWS::ApplicationAutoScaling::ScalableTarget 和 ScalingPolicy 资源替换为三个自定义资源，通过 CDK 的 node.add_dependency 显式约束依赖顺序：

• 注销（自定义资源）：在端点更新开始前移除可扩缩目标；首次部署时尚无可扩缩目标，处理器会容错并继续。
• 端点更新（CDK 管理）：正常更新端点资源，切换到新配置。
• 注册可扩缩目标（自定义资源）：等待端点进入 InService 状态后注册。
• 附加扩缩容策略（自定义资源）：等待可扩缩目标可查询后应用目标跟踪策略。

后两个自定义资源采用 CDK provider 的异步完成模式：on_event 处理器立即返回，is_complete 处理器由 provider 的 waiter 每 30 秒重新调用，直到就绪检查通过。总等待时间由 total_timeout 约束——注册可扩缩目标为 1 小时，附加策略为 15 分钟，因此不受单次 Lambda 调用超时限制。每个自定义资源上的 ConfigHash 属性会在配置值变化时强制 CloudFormation 重新调用 Lambda。

端点配置与扩缩容参数需要一起定义，因为同一个 ConfigHash 驱动整个扩缩容编排。

部署栈的实际资源数量

虽然 construct 只定义三个自定义资源，实际部署的栈里 Lambda 函数不止三个。每个自定义资源背后是一个 CDK cr.Provider，provider 框架会生成自己的辅助函数：同步 provider（注销）增加一个框架函数；异步 provider（注册可扩缩目标、附加策略）各增加 onEvent、isComplete、onTimeout 三个函数，外加一个驱动 waiter 的 Step Functions 状态机。最终栈内包含 3 个自定义资源、2 个 Step Functions 状态机和 12 个 Lambda 函数，其中 5 个承载 construct 自身的处理器代码，其余 7 个由框架生成。这些框架函数无需编写和维护，但审查部署资源时应把它们计入。

编辑部观察

这一方案针对的是 CloudFormation 与 SageMaker AI 扩缩容生命周期之间的顺序冲突，而非扩缩容策略本身的调优。它把原本需要人工介入的注销—更新—重注册流程固化为声明式依赖，代价是栈内资源数量上升，且异步等待依赖 Step Functions 与 Lambda 的配合。对已经在用 CDK 管理 SageMaker 端点的团队，值得在非生产栈先验证首次部署、仅改端点配置、同时改扩缩容参数这三种场景，并确认回滚路径是否符合预期。原文未给出具体性能数据或成本影响，实际收益需结合自身部署频率评估。