AWS cerrará el 30 de octubre de 2026 el espacio de nombres bedrock-agentcore de AWS Agent Registry. Ese día terminará el acceso de lectura y escritura y se perderán los datos que sigan allí. La migración, abierta desde el 6 de agosto, no es automática: cada cliente debe trasladar sus registros al nuevo espacio agent-registry, según la guía de migración de AWS.
El cambio afecta a AWS Agent Registry. AWS indica que Identity, Gateway, Runtime y Policy quedan fuera de esta migración; algunos permisos de identidad de cargas de trabajo y de proveedores de credenciales OAuth también seguirán bajo bedrock-agentcore.
Elige una estrategia según cómo se use el Registry
AWS describe tres métodos. La elección depende de si necesitas hacer una migración puntual, automatizar la carga o mantener escrituras en un Registry de producción mientras preparas el cambio.
| Estrategia | Cuándo encaja | Carga y cambio al nuevo espacio |
| Migración local o con AWS CloudShell | Para ejecutar una migración completa una sola vez. | La herramienta extrae, transforma y carga los registros desde un terminal local o CloudShell, sin desplegar infraestructura para la migración. |
| AWS Glue | Para ejecutar trabajos gestionados sin supervisión o cargar cambios incrementales en el corte. | AWS describe un trabajo basado en una pila de AWS CDK: primero hace una carga completa y después permite una carga incremental en el momento del cambio. |
| Active-active | Para registros de producción que siguen recibiendo escrituras. | Tras la migración completa, la aplicación escribe en ambos espacios; después de validar los datos, se cambian las lecturas y escrituras al nuevo. |
En las tres rutas, la herramienta carga los registros en nuevas instancias de Registry dentro de la misma cuenta y región de AWS. Los datos existentes no se copian solos.
Prepara los cambios de aplicación e infraestructura
Cambiar bedrock-agentcore por agent-registry no basta. AWS señala que el esquema de la API es incompatible con versiones anteriores: hay que actualizar el código que construye solicitudes o interpreta respuestas. Entre los cambios están los campos obligatorios name y recordType; la reestructuración de los descriptores; inlineContent, que pasa a llamarse data; y schemaVersion y protocolVersion, que se sustituyen por dataSchemaVersion. En los registros sincronizados, source pasa a formar parte de los descriptores.
Revisa también las integraciones y sus identificadores:
- Los endpoints de datos cambian de
bedrock-agentcore.{region}.amazonaws.comaagent-registry.{region}.api.aws; los del plano de control, debedrock-agentcore-control.{region}.amazonaws.comaagent-registry-control.{region}.api.aws. - El prefijo de acciones IAM pasa de
bedrock-agentcore:*aagent-registry:*. El principal de servicio de Registry cambia debedrock-agentcore.amazonaws.comaagent-registry.amazonaws.com. - En los SDK,
BedrockAgentCoreClientyBedrockAgentCoreControlClientdan paso aAgentRegistryClientyAgentRegistryControlClient. En la CLI,aws bedrock-agentcorepasa aaws agent-registry. - CloudWatch cambia el espacio de métricas de
AWS/BedrockAgentCoreaAWS/AgentRegistry. En EventBridge, el origen pasa deaws.bedrock-agentcoreaaws.agent-registry; actualiza las reglas que dependan del origen antiguo o de tipos de detalle modificados. Los eventos siguen usando el bus predeterminado.
BedrockAgentCoreFullAccess no incorpora automáticamente permisos agent-registry:*. AWS indica que se use AgentRegistryFullAccess para acceder a Registry. A la vez, los permisos de identidad de cargas de trabajo y de proveedores de credenciales OAuth siguen bajo bedrock-agentcore, así que no conviene sustituir indiscriminadamente todos los prefijos antiguos.
Comprueba la confianza IAM antes de cargar registros sincronizados
Si un registro se sincroniza con credenciales de un rol IAM, la política de confianza de ese rol debe aceptar agent-registry.amazonaws.com antes de la carga en vivo. AWS advierte que la herramienta de migración no detecta esta dependencia. Los registros con autenticación OAuth o sin autorización no tienen este requisito específico.
Si un registro migrado termina con el estado CREATE_FAILED, la recuperación indicada por AWS es actualizar la política de confianza, eliminar el registro fallido del nuevo Registry y volver a ejecutar la carga.
Valida los datos y las lecturas antes del cambio
AWS recomienda comparar el número de registros entre ambos espacios y comprobar cuántos elementos contiene cada uno. Revisa también una muestra de los registros transformados, actualiza las integraciones afectadas y prueba lecturas y escrituras en agent-registry. Si mantienes escrituras dobles con la estrategia active-active, valida los datos antes de cambiar las lecturas y escrituras de la aplicación al nuevo espacio.
