AWS Agent Registry旧入口10月30日关闭：哪些权限要改，哪些要保留？

AWS迁移文档把2026年10月30日列为旧bedrock-agentcore Registry命名空间的关闭日，届时失去旧服务及剩余数据的读写访问。这个通知没有说明物理删除，也没有给出具体时区或切换时刻。

新agent-registry命名空间已于2026年8月6日推出。本文在2026年10月28日核验临近截止的迁移要求；原文未标首次发布日期，因此没有把8月的推出写成今天的新发布。Identity、Gateway、Runtime和Policy不在这次命名空间迁移范围内。

先标清字段属于谁，再决定怎么改。下表只列最容易混淆的项目，不能作为可直接部署的完整IAM策略。

检查时把“角色信任策略”和“调用方权限策略”分别展开。即使两处都出现Service字样，它们也不是同一字段。不能把一处的修改结果复制到另一处，更不能据某个请求成功推断另一条权限路径也通过。

Registry生命周期还涉及Identity权限。官方权限页列出的CreateWorkloadIdentity、GetWorkloadIdentity和DeleteWorkloadIdentity仍使用bedrock-agentcore。清理旧权限前，应确认删掉的到底是旧Registry动作，还是新Registry仍需要的Identity动作。

本站建议先收集实际使用的账户、区域、Registry标识、客户端版本、调用入口、记录同步方式和配置负责人。只读取必要的资源配置，不把令牌值或密钥放入迁移表。

每一行记录一个具体配置位置，例如某应用的SDK客户端、某条IAM Statement或某个同步角色。不要把“所有权限已修改”当作一行已完成记录。

官方迁移工具提供新旧record ID对照及逐记录比较报告。把真实目标标识回填到应用配置，不能用修改旧ARN前缀代替核对。

客户端、请求和响应结构也要一起检查。迁移工具负责数据处理，应用自己构造和解析的JSON仍需要适配。建议为一个已有记录保存脱敏输入及预期业务输出，迁移后用相同业务问题比较，避免仅检查HTTP状态。

数据不会自动搬到新命名空间。下面的顺序是本站安排建议，实际工具命令、权限和环境要求应按官方仓库执行。不要把教学顺序当作已完成迁移的证明。

以下为本站设计的假设演练，未执行，表中只有预期判断，没有实测通过率。请在隔离测试资源上安排，不直接向生产目录注入故障。

官方给出一种需要额外恢复步骤的情况：IAM同步角色仍信任旧服务，使新记录进入CREATE_FAILED。只修正信任策略不够，迁移工具不会覆盖失败状态的记录；应按官方步骤删除新命名空间内那条受影响的CREATE_FAILED记录，再重跑加载。

执行这类删除前，本站建议先保存失败原因、源记录和新旧映射，确认目标命名空间及记录ID。这个步骤仅针对上述异常，不适用于清空目录，也不要求删除源记录。若状态或原因不同，按实际错误排查，不套用删除重建。

先挑一个仍使用旧Registry的实际应用，把客户端入口、目标Registry、同步角色和调用方策略放在同一张变更账里。用四类字段对照完成分类，再安排受控验证。对于没有旧Registry资源的团队，保留此类“按字段归属迁移”的方法即可，无需因为截止提醒改动其他AgentCore服务。

AI随心创的企业AI / FDE服务涉及任务诊断、系统集成与交付。需要讨论这类迁移时，可以准备脱敏的资源关系、配置差异、调用链及尚未解决的失败记录，用于界定诊断和验收范围；文章演练不代表我们已在客户环境完成这次迁移。