部署显示成功，推理服务却已经失去自动伸缩，这比一个明确的报错更容易留下隐患。AWS在10月23日公开一套SageMaker AI端点更新的CDK参考方案，把注销伸缩目标、更新端点、重新注册和挂回策略放进同一条编排链。它针对的是基础设施状态衔接，不是模型性能升级，也不是一项新上线的托管服务功能。

快速看点：一，手工解除伸缩注册后，模板未变化可能导致伸缩没有恢复；二，三个自定义资源为四个阶段规定顺序，并等待实际就绪状态；三，参考代码需要自己部署维护，不承诺无中断、自动解决所有回滚故障或带来通用成本收益。

模板里还写着，不代表线上资源还在

SageMaker实时端点与Application Auto Scaling分别维护服务和伸缩状态。当某些端点配置变更涉及移除变体或更换实例类型，伸缩目标仍处于注册状态就可能阻止更新。CloudFormation先遇到端点错误，还没机会处理后面的伸缩资源，简单调整模板排列并不能代替明确依赖。

手工注销看似解开了第一道锁，却可能让模板记录与实际状态分离。若后续只修改端点配置，伸缩资源在模板里没有变化，CloudFormation可能不会重新创建目标和策略。于是端点已经运行，部署也没有再报错，但自动伸缩并未恢复，压力到来时才会显出问题。

另一条路径是注销后同时修改伸缩参数，部署又试图更新已经不存在的资源，甚至可能进入UPDATE_ROLLBACK_FAILED。这里讨论的是特定部署组合下的失败模式，不是所有SageMaker更新都会失败；已有服务的配置、变体与发布方式仍需分别核对。

四个阶段，分清请求接受与真正就绪

参考构件使用三个Lambda支持的自定义资源，替代对应的原生伸缩目标和策略资源。第一步先注销目标；第二步仍由CDK管理端点更新；第三步等待端点达到InService再注册目标；第四步等目标可查询后应用目标跟踪策略。它将原来依靠操作人员记忆的顺序写成部署依赖。

重新注册与挂回策略采用异步完成模式：事件处理器先返回，再由提供者的等待机制按间隔检查是否满足条件，而不是让单次Lambda调用一直阻塞。示例每30秒检查，重新注册总等待上限为1小时，挂回策略为15分钟。这些是参考配置，不是服务恢复时间保证。

代码还检查端点Failed状态并显式失败，避免把失败当成永远等下去。伸缩目标注册返回之后，也不立即假设其他调用已经能查到它。这个细节对应分布式系统常见的可见性延迟：一个接口接受操作与下一个接口读到新状态，未必发生在同一时刻。

配置变化要触发全链，迁移也有边界

各自定义资源带有ConfigHash属性，让相关配置变化能够重新触发编排。示例把端点与自动伸缩配置一起纳入，避免只修改实例或环境参数时漏掉恢复动作。接入已有工程时，如果摘要遗漏某一类配置，即使代码看起来已经整合，依然可能没有触发团队期待的路径。

当前可检查代码以AllTraffic变体和按实例调用量的目标跟踪策略为示例。它不是对任意多变体、任意伸缩指标或全部部署策略的通用适配器。已有栈需要审查资源归属和迁移计划，不能直接把原生资源与自定义资源叠加，让两套逻辑同时管理同一个线上对象。

代码也让成本和权限成为实施工作的一部分。自定义资源背后还有提供者框架生成的函数与状态机，并非只多三个轻量配置项。示例中的部分权限使用通配资源范围，需要安全团队结合服务授权条件审查；不能因为来自参考仓库，就跳过权限、日志保留与资源费用检查。

最重要的验收不是端点能响应一次请求，而是更新后伸缩目标、上下限和策略都与预期一致，再用代表性负载验证行为。暂停自动伸缩的窗口内，容量如何保障、请求如何排队和回滚由谁接手，都需要预先设计；本轮没有在客户云账户部署，也未获得生产可用性或节省金额的独立验证。

小编判断：发布成功，应当包含能力恢复

这套参考方案没有让运维问题消失，它把一个隐蔽问题变得可以讨论：发布流程若临时关闭了某种保护或弹性能力，恢复这项能力就应该属于完成条件，而不应变成发布后想起来才补的一步。这条经验也适用于限流、告警与临时权限。

对企业AI交付团队而言，值得复用的是明确依赖、状态检查和失败出口，而不是照搬某组等待参数。把“请求已接受”“服务已就绪”“伸缩已恢复”分别记录，才有办法判断系统到底停在哪一层。服务能够回答一个问题，不等于它已经具备继续承接业务波动的能力。