# Guía completa de migración de registros * AWS Registro de agentes: migración de la versión preliminar pública a la disponibilidad general* ## Introducción Como parte de su lanzamiento como versión general (GA) el 6 de agosto de 2026, AWS Agent Registry introducirá cambios significativos en el modelo principal del servicio, los datos y la API. Si utilizó AWS Agent Registry durante la versión preliminar pública, debe completar una migración que abarque tres áreas: 1. **Cambios en el espacio de nombres y la configuración**: vamos a trasladar AWS Agent Registry del espacio de nombres de AWS Bedrock a su propio espacio de AgentCore nombres dedicado. Este cambio de espacio de nombres se aplica únicamente a Agent Registry. AWS AgentCore El resto de ofertas, como Identity, Gateway, Runtime y Policy, no se verán afectadas. En el caso de AWS Agent Registry, el espacio de nombres del servicio cambia de a. `bedrock-agentcore` `agent-registry` Esto afecta a todas las superficies que hacen referencia al servicio: puntos finales, políticas de IAM, clientes del SDK, comandos de CLI, ARN de recursos e integraciones de observabilidad. Debe actualizar el código y la infraestructura para usar el nuevo espacio de nombres. 1. **Cambios en el esquema de la API**: los modelos de datos de registro y registro se actualizan en función de los comentarios de los clientes durante la versión preliminar pública. Estos cambios rompen la compatibilidad con versiones anteriores de los esquemas de API existentes. El código de la aplicación que crea o analiza las solicitudes y respuestas de la API debe actualizarse para reflejar el nuevo esquema, como parte de la migración al nuevo espacio de nombres. 1. **Migración de datos**: debes migrar tus registros actuales y los registros de registro del espacio de nombres anterior al nuevo. Proporcionamos herramientas de migración para extraer sus datos, transformarlos en el nuevo esquema y cargarlos en el nuevo espacio de nombres. Los datos se migran a la misma cuenta y región; solo cambia el espacio de nombres. Esta guía cubre cada área en detalle con ejemplos del antes y el después para ayudarte a planificar y ejecutar la migración. ## ¿Cuál es el cronograma de migración? Hay dos hitos importantes que debe recordar para esta migración: + **6 de agosto de 2026**: el registro de AWS agentes pasa a estar disponible para el público en general y se lanza oficialmente el nuevo espacio de `agent-registry` nombres. Si tiene registros y registros existentes, tiene acceso simultáneo a los espacios de nombres y. `bedrock-agentcore` `agent-registry` [Las herramientas de migración están disponibles en el repositorio agentcore-samples. GitHub ](https://github.com/awslabs/agentcore-samples) Puede iniciar el proceso de migración. **nota** Si es un cliente nuevo sin registros o registros existentes al 6 de agosto de 2026, no podrá acceder a AWS Agent Registry a través del `bedrock-agentcore` espacio de nombres. Comience a usar AWS Agent Registry directamente desde el espacio de nombres. `agent-registry` + **17 de septiembre de 2026**: se cierra la ventana de migración. El antiguo espacio de `bedrock-agentcore` nombres se cierra en esta fecha. Pierdes el read/write acceso al servicio y a los datos restantes en el espacio de nombres anterior. Después de esta fecha, debes usar el `agent-registry` espacio de nombres. ## Cambios en el espacio de nombres y la configuración El espacio de `agent-registry` nombres reemplaza `bedrock-agentcore` en los siguientes lugares. En esta sección se enumeran todas las superficies que cambian y se proporcionan ejemplos de cómo actualizar el código. **importante** Los cambios en el espacio de nombres solo afectan a las API que ofrece AWS Agent Registry, pero no al resto de AWS Bedrock AgentCore, como Identity. AWS AgentCore Por lo tanto, la identidad de la carga de trabajo y los recursos del proveedor de credenciales de OAuth permanecen en el espacio de nombres. `bedrock-agentcore` ### Puntos de conexión de servicio Sus aplicaciones deben apuntar a los nuevos nombres de host de los terminales. Los nuevos puntos de enlace utilizan el `.api.aws` dominio. | Surface (Superficie) | Valor anterior | Valor nuevo | | --- | --- | --- | | Punto final del plano de datos | `bedrock-agentcore.{region}.amazonaws.com` | `agent-registry.{region}.api.aws` | | Punto de conexión del plano de control | `bedrock-agentcore-control.{region}.amazonaws.com` | `agent-registry-control.{region}.api.aws` | ### IAM y seguridad Todas las políticas de IAM, las políticas de control de servicios (SCP) y los límites de permisos a los que se hace referencia `bedrock-agentcore` deben actualizarse. Los ARN de los recursos también cambian para reflejar el nuevo espacio de nombres. | Surface (Superficie) | Valor anterior | Valor nuevo | | --- | --- | --- | | Prefijo de acción de IAM | `bedrock-agentcore:*` | `agent-registry:*` | | Entidad principal de servicio | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` | | ARN de registro | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}` | | ARN del registro | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}` | Si tiene una automatización que analiza los ARN o los almacena, actualice también esas referencias. Las políticas personalizadas con condiciones en el prefijo de acción de IAM o en el principio del servicio deben actualizarse para que coincidan con los nuevos valores. Para ver la lista completa de permisos de IAM asociados al Registro de AWS Agentes, consulte la referencia de permisos de [IAM del Registro de AWS Agentes](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html). **nota** Si actualmente utiliza la política [BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html) AWS gestionada para acceder al registro de AWS agentes (consulte [los detalles de la BedrockAgentCoreFullAccess política](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam-awsmanpol.html#security-iam-awsmanpol-BedrockAgentCoreFullAccess)), debe sustituirla por la nueva política **AgentRegistryFullAccess**gestionada (disponible en GA). La antigua política BedrockAgentCoreFullAccess gestionada **NO** se actualizará para incluir `agent-registry:*` los permisos. ### SDK, CLI e infraestructura Actualice el código de la aplicación, los scripts de implementación y las plantillas de infraestructura como código para hacer referencia a la nueva clase de cliente y al espacio de nombres CLI. | Surface (Superficie) | Valor anterior | Valor nuevo | | --- | --- | --- | | Clase de cliente del SDK de Dataplane | `BedrockAgentCoreClient` | `AgentRegistryClient` | | Clase de cliente Controlplane SDK | `BedrockAgentCoreControlClient` | `AgentRegistryControlClient` | | Espacio de nombres CLI | `aws bedrock-agentcore` | `aws agent-registry` | | Código Service Quotas | `bedrock-agentcore` | `agent-registry` | Si anteriormente solicitó aumentos de cuota personalizados con el código de `bedrock-agentcore` servicio, debe volver a solicitarlos con arreglo `agent-registry` a. ### Observabilidad y organización de eventos Actualice todas las consultas de CloudTrail Lake, las consultas de Athena, las integraciones de SIEM, las EventBridge reglas, los CloudWatch paneles y las alarmas que hagan referencia al espacio de nombres anterior. | Surface (Superficie) | Valor anterior | Valor nuevo | | --- | --- | --- | | CloudTrail fuente del evento | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` | | EventBridge fuente | `aws.bedrock-agentcore` | `aws.agent-registry` | | CloudWatch espacio de nombres | `AWS/BedrockAgentCore` | `AWS/AgentRegistry` | ### Ejemplo: actualización de las políticas de IAM Sustituya el prefijo de acción y el espacio de nombres del ARN del recurso en todas sus políticas de IAM. **Antes (versión preliminar pública):** ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateRegistry", "bedrock-agentcore:GetRegistry", "bedrock-agentcore:UpdateRegistry", "bedrock-agentcore:ListRegistries", "bedrock-agentcore:DeleteRegistry", "bedrock-agentcore:CreateRegistryRecord", "bedrock-agentcore:GetRegistryRecord", "bedrock-agentcore:UpdateRegistryRecord", "bedrock-agentcore:ListRegistryRecords", "bedrock-agentcore:DeleteRegistryRecord", "bedrock-agentcore:SubmitRegistryRecordForApproval", "bedrock-agentcore:UpdateRegistryRecordStatus", "bedrock-agentcore:SearchRegistryRecords" ], "Resource": ["arn:aws:bedrock-agentcore:us-west-2:123456789012:*"] }] } ``` **Después (disponibilidad general):** ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "agent-registry:CreateRegistry", "agent-registry:GetRegistry", "agent-registry:UpdateRegistry", "agent-registry:ListRegistries", "agent-registry:DeleteRegistry", "agent-registry:CreateRegistryRecord", "agent-registry:GetRegistryRecord", "agent-registry:UpdateRegistryRecord", "agent-registry:ListRegistryRecords", "agent-registry:DeleteRegistryRecord", "agent-registry:SubmitRegistryRecordForApproval", "agent-registry:UpdateRegistryRecordStatus", "agent-registry:SearchDiscoverableRegistryRecords", "agent-registry:ListDiscoverableRegistryRecords", "agent-registry:GetDiscoverableRegistryRecord" ], "Resource": ["arn:aws:agent-registry:us-west-2:123456789012:*"] }] } ``` **nota** La `BatchGetDiscoverableRegistryRecord` API no tiene su propia acción de IAM. Autoriza cada registro solicitado para impedir la `agent-registry:GetDiscoverableRegistryRecord` acción. Asegúrese de que su póliza incluya `GetDiscoverableRegistryRecord` el uso`BatchGet`. **importante** La identidad de la carga de trabajo y los recursos del proveedor de credenciales de OAuth permanecen en el espacio de nombres. `bedrock-agentcore` Si tus registros utilizan URL sync (`source.fromUrl`) con credenciales de OAuth o IAM, debes conservar los siguientes permisos junto con los nuevos: `agent-registry:*` ``` "bedrock-agentcore:CreateWorkloadIdentity", "bedrock-agentcore:GetWorkloadIdentity", "bedrock-agentcore:DeleteWorkloadIdentity" ``` No sustituyas todas las `bedrock-agentcore` acciones: estos recursos de identidad conservan intencionadamente el antiguo espacio de nombres. ### Ejemplo: actualizar la configuración del cliente del SDK Actualiza el nombre del servicio, la clase de cliente y la URL del punto final en tus llamadas al SDK. **Antes (versión preliminar pública):** ``` import boto3 session = boto3.Session(region_name="us-west-2") cp_client = session.client( "bedrock-agentcore-control", endpoint_url="https://bedrock-agentcore-control.us-west-2.amazonaws.com" ) dp_client = session.client( "bedrock-agentcore", endpoint_url="https://bedrock-agentcore.us-west-2.amazonaws.com" ) ``` **Después (disponibilidad general):** ``` import boto3 session = boto3.Session(region_name="us-west-2") cp_client = session.client( "agent-registry-control", endpoint_url="https://agent-registry-control.us-west-2.api.aws" ) dp_client = session.client( "agent-registry", endpoint_url="https://agent-registry.us-west-2.api.aws" ) ``` ### Ejemplo: actualización de comandos CLI Sustituya el espacio de nombres CLI en todos los scripts y en la automatización. **Antes (versión preliminar pública):** ``` aws bedrock-agentcore-control create-registry \ --name "MyRegistry" \ --description "Production registry" \ --region us-west-2 \ --endpoint-url https://bedrock-agentcore-control.us-west-2.amazonaws.com ``` **Después (disponibilidad general):** ``` aws agent-registry-control create-registry \ --name "MyRegistry" \ --description "Production registry" \ --region us-west-2 \ --endpoint-url https://agent-registry-control.us-west-2.api.aws ``` ## Cambios en el esquema de la API Además de la migración del espacio de nombres, actualizamos los modelos de datos de registro y registro para garantizar su disponibilidad general. Estos cambios mejoran la coherencia y la extensibilidad de la API en función de los comentarios de la versión preliminar pública. En esta sección se describe cada categoría de cambios con ejemplos del antes y el después para que puedas actualizar el código de tu aplicación. ### Cambio 1: actualizaciones de la entidad de registro La configuración de autorización del recurso de registro, que controla cómo se accede al plano de datos de un registro, ahora se encuentra bajo un `discoveryConfiguration` contenedor específico que hace explícito su propósito. La configuración de aprobación (que controla si los registros enviados al `PENDING_APPROVAL` estado pasan automáticamente al `APPROVED` estado) pasa de ser una matriz booleana a una matriz de enumeración extensible. Los cambios de campo específicos son: + `authorizerType`y `authorizerConfiguration` se mueven dentro de un `discoveryConfiguration` objeto nuevo. + `approvalConfiguration.autoApproval`(booleano) se reemplaza por `approvalConfiguration.autoApprovalRules` (matriz de cadenas de enumeración). El valor `"APPROVE_ALL"` tiene el mismo significado semántico que. `autoApproval: true` Se aplican las reglas especificadas en la lista de enumeración. Si no se especifica (nulo), es necesaria la aprobación. **Antes (versión preliminar pública):** ``` { "name": "string", "description": "string", "authorizerConfiguration": { ... }, "authorizerType": "string", "approvalConfiguration": { "autoApproval": true } } ``` **Después (disponibilidad general): con la aprobación de TODOS** ``` { "name": "string", "description": "string", "discoveryConfiguration": { "authorizerConfiguration": { ... }, "authorizerType": "string" }, "approvalConfiguration": { "autoApprovalRules": ["APPROVE_ALL"] } } ``` **Después (disponibilidad general): con NULL en la lista de enumeración** ``` { "name": "string", "description": "Registry with manual approval only", "approvalConfiguration": { "autoApprovalRules": [] } } ``` ### Cambio 2: Nuevos campos obligatorios en los registros de registro Los registros de registro cuentan con dos nuevos campos obligatorios de nivel superior para permitir una mejor categorización y deduplicación. Debe especificar ambos campos al crear un registro de registro mediante la `CreateRegistryRecord` API, y puede cambiarlos posteriormente mediante la API. `UpdateRegistryRecord` | Campo | Tipo | Description (Descripción) | | --- | --- | --- | | `name` | Cadena (obligatoria) | Un identificador único dentro del registro que puede especificar el cliente. Cada registro debe tener un nombre único en el registro. Cuando también `recordVersion` está presente, la combinación de `name` y `recordVersion` debe ser única. | | `recordType` | Enum (obligatorio) | El tipo semántico del registro. Valores válidos: `AGENT`, `MCP`, `SKILL`, `CUSTOM`. Determina en qué clave descriptora principal es válida. `descriptors` Puedes usar API como `ListRegistryRecords` y `SearchDiscoverableRegistryRecords` para filtrar los resultados por este tipo semántico. | ### Cambio 3: reestructuración de los registros El `descriptors` campo pasa de ser una unión discriminada a una estructura de teclas planas. En el modelo anterior, el `descriptorType` campo (`MCP`,, `A2A``AGENT_SKILLS`,`CUSTOM`) determinaba la forma interior. Esto combinaba el contenido del descriptor con una clasificación aproximada de protocolos o formatos. Ese campo ya no existe. `recordType`, un atributo de nivel superior independiente, lo sustituye por la categorización semántica. La API aplica claves descriptoras válidas para cada uno de ellos `recordType` en tiempo de ejecución, y no de forma estructural. Cada clave de nivel superior situada debajo `descriptors` ahora representa un tipo de descriptor principal granular (por ejemplo,,,,`a2aAgentCard`). `mcpServer` `agentSkillsDefinition` `custom` Los descriptores complementarios (por ejemplo`tools`,`skillMd`) se encuentran debajo del descriptor principal. `additionalData` El `inlineContent` campo se convierte en. `data` Los `protocolVersion` campos `schemaVersion` y se consolidan en`dataSchemaVersion`. El `synchronizationConfiguration` atributo de nivel superior pasa a estar dentro de cada descriptor (incluidos los secundarios) `source` y se mueve dentro de él`additionalData`. El `name` campo existente pasa a ser`displayName`, lo que hace que su significado sea más explícito. Un `name` campo netamente nuevo sirve como clave de deduplicación y debe ser único en todos los registros de un registro. Si especifica ambos `name` y `recordVersion` para el mismo registro, su combinación debe ser única. Se cambia el nombre de los siguientes campos: | Antes | Después | Notas | | --- | --- | --- | | `name` | `displayName` | Muestra el nombre del registro. También habrá un nuevo `name` campo que es la clave de deduplicación. | | `descriptorType` | Eliminaciones | Sustituido por el campo de nivel superior. `recordType` | | `inlineContent` | `data` | La carga útil de contenido dentro de cada descriptor. | | `schemaVersion` / `protocolVersion` | `dataSchemaVersion` | Campo de versión unificado para todos los tipos de descriptores. | | `synchronizationConfiguration` | `source` | Se ha movido dentro de cada descriptor (incluidos `additionalData` los secundarios). | **Antes (vista previa pública):** ``` { "recordId": "string", "name": "string", "descriptorType": "string", // A2A, MCP, AGENT_SKILL, CUSTOM "descriptors": { "agent": { "a2aAgentCard": { "inlineContent": "string", "schemaVersion": "string" } }, "agentSkills": { "skillDefinition": { "inlineContent": "string", "schemaVersion": "string" }, "skillMd": { "inlineContent": "string" } }, "mcp": { "server": { "inlineContent": "string", "schemaVersion": "string" }, "tools": { "inlineContent": "string", "protocolVersion": "string" } }, "custom": { "inlineContent": "string" } }, "synchronizationType": "URL", "synchronizationConfiguration": { "fromUrl": { "url": "string", "credentialProviderConfigurations": [ { "credentialProvider": { ... }, "credentialProviderType": "string" } ] } }, ... } ``` **Después (disponibilidad general):** ``` { "recordId": "string", "displayName": "string", "name": "string", "recordVersion": "string", "recordType": "AGENT" | "MCP" | "SKILL" | "CUSTOM", "descriptors": { "a2aAgentCard": { "data": "string", "dataSchemaVersion": "string", "source": { "fromUrl": { "url": "string", "credentialProviderConfigurations": [...] } } }, "mcpServer": { "data": "string", "dataSchemaVersion": "string", "source": { "fromUrl": { ... } }, "additionalData": { "tools": { "data": "string", "dataSchemaVersion": "string" } } }, "agentSkillsDefinition": { "data": "string", "dataSchemaVersion": "string", "additionalData": { "skillMd": { "data": "string", "dataSchemaVersion": "string", "source": { "fromUrl": { ... } } } } }, "custom"?: { "data": "string" } }, "metadata": Document ... } ``` Existen las siguientes limitaciones: Se puede rellenar exactamente una clave descriptora principal por registro. Los descriptores principales válidos son: `recordType` + **AGENTE:**`a2aAgentCard`,, `mcpServer` `custom` + **MCP:**`mcpServer`, `custom` + **HABILIDAD:**`agentSkillsDefinition`, `custom` + **PERSONALIZADO:** `custom` `source`es por descriptor y no por un único bloque de nivel superior. Se adjunta a los descriptores que contienen un `source` campo en el esquema, y. `mcpServer` `a2aAgentCard` El `tools` hijo (menor`mcpServer.additionalData`), el `agentSkillsDefinition` padre y el `custom` descriptor llevan un no. `source` En GA, solo `source.fromUrl` se admite. Auto-synchronization solo se activa para los `mcpServer` descriptores `a2aAgentCard` principales, es decir, los tipos de registro MCP y AGENT. A `source` on the `skillMd` child se conserva, pero no se usa para ejecutar la sincronización, y los registros de SKILL no se pueden sincronizar automáticamente. Los registros CUSTOM se deben crear manualmente proporcionándolos directamente. `data` ### Cambio 4: actualizaciones del filtro del plano de datos `SearchRegistryRecords`se convierte en `SearchDiscoverableRegistryRecords` (`POST /discoverable-records-search`). Su solicitud y respuesta recogen los nuevos nombres de campo y modelo de datos: + Filtrar por `recordType` (reemplaza`descriptorType`). + Filtrar por `recordVersion` (reemplaza`version`). + La respuesta devuelve los descriptores en el nuevo formato, sin `credentialProviderConfigurations` ellos. La herramienta de búsqueda MCP `search_registry_records` pasa a ser`search_discoverable_registry_records`, devuelve el nuevo formato de descriptor y utiliza los nuevos nombres de filtro. ### Cambio 5: Nuevas API de navegación Dos nuevas API de planos de datos permiten crear experiencias de navegación y catalogación a partir de registros aprobados. Estas API no requieren ninguna migración explícita; las mencionamos aquí como adiciones al modelo de API de AWS Agent Registry de GA. **ListDiscoverableRegistryRecords**— Devuelve una lista paginada de los registros de registro aprobados. Úselo para crear interfaces de navegación sobre el contenido publicado. ``` // HTTP: POST /registries/{registryId}/discoverable-records-list { "registryId": "string", // path param, required (ARN or ID) "maxResults": 1-100, // query param, optional "nextToken": "string", // query param, optional "filters": [ { "name": "recordType", "values": ["MCP"] } ] } { "registryRecords": [ { "registryArn": "string", "recordArn": "string", "recordId": "string", "name": "string", "displayName": "string", "description": "string", "recordType": "string", "recordVersion": "string", "status": "string", "createdAt": "string", "updatedAt": "string" } ], "nextToken": "string" } ``` **BatchGetDiscoverableRegistryRecord**— Recupera todos los detalles de un lote de registros de uno o más registros en una sola llamada. ``` // HTTP: POST /discoverable-records-batch { "entries": [ { "registryId": "reg-AAA", "recordIds": ["rec-111", "rec-222"] } ] } { "registryRecords": [ { "registryArn": "string", "recordArn": "string", "recordId": "string", "name": "string", "displayName": "string", "description": "string", "recordType": "string", "descriptors": { ... }, "recordVersion": "string", "status": "string", "createdAt": "string", "updatedAt": "string" } ], "errors": [ { "registryId": "string", "recordId": "string", "errorCode": "RESOURCE_NOT_FOUND" | "ACCESS_DENIED" | "INTERNAL_ERROR", "message": "string" } ] } ``` La respuesta incluye una `registryRecords` matriz con todos los detalles del registro y una `errors` matriz para los registros que no se hayan podido recuperar. En el momento del lanzamiento, se acepta exactamente una entrada (un registro, de 1 a 100 identificadores de registro). La forma agrupada es compatible con el procesamiento por lotes entre registros en futuras versiones. ### Cambio 6: las API de lista adoptan el parámetro de filtros estructurados En la versión preliminar pública, las API de listas muestran cada campo filtrable como su propio parámetro de consulta (por ejemplo,`--status READY`,`--recordType MCP`). En GA, un único `filters` parámetro estructurado reemplaza a estos parámetros discretos. El `filters` valor es una lista de `{ "name": "", "values": [""] }` entradas donde `name` hay una ruta de atributos delimitada por puntos. Los nuevos campos filtrables, incluidos los anidados, se convierten en nuevas `name` rutas y no en nuevos parámetros de API. Las operaciones de lista también cambian de a. `GET` `POST` Los parámetros de paginación (`maxResults`,`nextToken`) permanecen inalterados. **Antes (vista previa pública):** ``` GET /registries?status=READY&authorizerType=AWS_IAM GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP ``` **Después (disponibilidad general):** ``` // ListRegistries // POST /registries-list { "filters": [ { "name": "status", "values": ["READY"] }, { "name": "discoveryConfiguration.authorizerType", "values": ["AWS_IAM"] } ], "maxResults": 100, "nextToken": "string" } // ListRegistryRecords // POST /registries/{registryId}/records-list { "filters": [ { "name": "name", "values": ["my-agent"] }, { "name": "status", "values": ["APPROVED"] }, { "name": "recordType", "values": ["MCP"] } ], "maxResults": 100, "nextToken": "string" } ``` ## Migración de datos Debe migrar los registros y registros de registro existentes del `bedrock-agentcore` espacio de nombres al espacio de nombres. `agent-registry` Proporcionamos un script para facilitar la migración. El script gestiona la extracción de los datos existentes, la transformación del esquema anterior al nuevo y la carga en los registros del nuevo espacio de nombres. El script crea nuevos registros en el espacio de `agent-registry` nombres dentro de la misma cuenta y región. Migra todos los registros existentes de los registros antiguos a los nuevos, teniendo en cuenta los cambios en el espacio de nombres y el esquema de la API. ### Elegir el enfoque de migración El enfoque correcto depende de la escala de uso del registro y del entorno operativo. #### Caso 1: Small-scale migración con ejecución directa de scripts + **Perfil:** menos de 5 registros y menos de 100 registros. Tiene acceso directo a un terminal o a CloudShell la cuenta de destino. + **Enfoque:** ejecute el script de migración de Python directamente. El script se conecta al espacio de nombres de vista previa, muestra los registros y registros, transforma los datos en el esquema de GA y los crea en el nuevo espacio de nombres. Esta es la ruta más sencilla y no requiere el despliegue de infraestructura. #### Caso 2: Migración gestionada con Lambda o Glue + **Perfil:** No tiene acceso directo desde la terminal al entorno de destino o prefiere un modelo de ejecución gestionada. + **Enfoque:** Implemente la migración como una función de AWS Lambda o una tarea de AWS Glue. El motor de migración realiza el mismo flujo de trabajo de extracción, transformación y carga, pero se ejecuta como un trabajo gestionado dentro de su cuenta. En la mayoría de las cuentas, la migración completa se completa en menos de 15 minutos. El motor de migración: + **Extrae** registros y registros del espacio de nombres de vista previa y admite cargas completas e incrementales. Pagina todas las respuestas de la API y serializa los datos en una ubicación provisional. + **Transforma** cada registro aplicando los cambios en el esquema de la API (cambios de nombre de campos, reestructuración de descriptores, nuevos campos obligatorios). + **Carga** los datos transformados en el nuevo espacio de `agent-registry` nombres y crea registros y registros mediante la API de GA. + **Genera un informe** que resume lo que se migró, los errores encontrados y los recuentos de registros para su verificación. #### Caso 3: Dual-write migración para cargas de trabajo de producción activas + **Perfil:** Ha creado una plataforma o un canal de automatización a partir de las API de versión preliminar pública y está escribiendo nuevos datos de forma activa durante la fase de producción. + **Enfoque:** utilice una estrategia de migración de doble escritura para evitar la pérdida de datos durante la transición: + **Actualice su escritor**: modifique su aplicación para escribir simultáneamente en el espacio de nombres de vista previa y en el nuevo `agent-registry` espacio de nombres. + **Ejecute el script de migración con deduplicación**: ejecute las herramientas de migración para migrar los datos históricos. El script se deduplica en función del `name` campo, por lo que los registros que ya existen en el nuevo espacio de nombres (de la escritura dual) no se duplican. + **Cambie de lector**: después de comprobar que todos los datos existen en el nuevo espacio de nombres, actualice la aplicación para que los lea exclusivamente. `agent-registry` + **Elimine la función de escritura doble**: tras confirmar que todas las lecturas y escrituras se han realizado correctamente en el nuevo espacio de nombres, elimine la versión preliminar del espacio de nombres de la aplicación. ### Verificación de la migración Tras ejecutar la migración, confirme que los datos se migraron correctamente: + Enumere todos los registros del nuevo espacio de nombres mediante el comando `list-registries` CLI y confirme que el recuento coincide con su fuente. + Para cada registro, compare el recuento de registros utilizando. `list-registry-records` + Spot-check registros individuales para confirmar que los descriptores se transformaron correctamente (cambios de nombre de campos, reestructuración de descriptores). + Actualice las políticas de IAM, los puntos finales y los clientes del SDK tal y como se describe en la sección sobre cambios en el espacio de nombres y la configuración. + Compruebe que sus aplicaciones puedan leer y escribir correctamente con el nuevo espacio de nombres. ## Preguntas frecuentes ### ¿Qué está cambiando en AWS ¿Registro de agentes? AWS Agent Registry pasará del espacio de nombres de versión preliminar pública al `bedrock-agentcore` espacio de nombres disponible `agent-registry` de forma general. La migración abarca tres áreas: cambios en el espacio de nombres y la configuración (puntos finales, IAM, SDK, CLI, ARN y observabilidad), cambios en el esquema de la API (modelo de datos reestructurado para registros y registros) y migración de datos (traslado de los registros y registros existentes al nuevo espacio de nombres). ### `¿Puedo seguir usando Registry en el espacio de nombres bedrock-agentcore?` Su uso actual del Registro en el espacio de `bedrock-agentcore` nombres seguirá funcionando sin interrupciones durante el período de migración. Sin embargo, le recomendamos que comience la migración tan pronto como estén disponibles las herramientas para asegurarse de disponer del tiempo suficiente para completar la migración de datos y las actualizaciones del código. Sin embargo, si no tiene registros o registros existentes al 6 de agosto de 2026, no podrá acceder al espacio de `bedrock-agentcore` nombres de AWS Agent Registry a partir del 6 de agosto de 2026. Si tienes registros o registros existentes al 6 de agosto de 2026, tendrás acceso al espacio de `bedrock-agentcore` nombres de AWS Agent Registry durante el período de migración (del 6 de agosto de 2026 al 17 de septiembre de 2026). ### ¿Mis datos se migrarán automáticamente? No. Debe iniciar la migración usted mismo utilizando las herramientas de migración que le proporcionamos. Consulte la sección de migración de datos para obtener detalles sobre los enfoques disponibles en función de su escala. ### ¿Qué cambios en el esquema de API están incluidos? Además del cambio de espacio de nombres, actualizamos el modelo de datos de la API en seis áreas: entidad de registro (la configuración de autorización se agrupa en`discoveryConfiguration`), registro de registro nuevos campos (`name`y`recordType`), reestructuración de registros de registro (descriptores aplanados, cambio de nombre de campos), actualizaciones de filtros de la API de búsqueda (,), nuevas API de navegación (`recordType`,`recordVersion`) y filtros estructurados para las `BatchGetDiscoverableRegistryRecord` operaciones de lista. `ListDiscoverableRegistryRecords` ### ¿Cuánto tardará la migración de datos? El tiempo de migración depende de la cantidad de registros y registros de su cuenta. En el caso de las cuentas con menos de 100 registros, la migración se completa en minutos si se ejecuta de forma local. En el caso de las cuentas con miles de registros, se espera que la migración se complete en menos de 15 minutos si se ejecuta como un trabajo gestionado. ### ¿Qué sucede si tengo una implementación a gran escala con escrituras activas? Si escribes datos de forma activa en el espacio de nombres de vista previa durante la fase de producción, utiliza la estrategia de migración de doble escritura, tal y como se describe en el caso 3. Este enfoque garantiza que no se pierdan datos durante la transición, ya que se escriben en ambos espacios de nombres simultáneamente, se migran los datos históricos con deduplicación y, a continuación, se intercalan las lecturas. ### ¿Dónde puedo obtener ayuda? Si tiene preguntas o necesita ayuda con la migración, póngase en contacto con [AWS Support](https://aws.amazon.com/support).