Introducción ¿Cuál es el cronograma de migración?Cambios en el espacio de nombres y la configuración Cambios en el esquema de la API Migración de datos Preguntas frecuentes

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:

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.
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.
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 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.

nota

Si actualmente utiliza la política BedrockAgentCoreFullAccess AWS gestionada para acceder al registro de AWS agentes (consulte los detalles de la BedrockAgentCoreFullAccess política), debe sustituirla por la nueva política AgentRegistryFullAccessgestionada (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 usoBatchGet.

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:

authorizerTypey 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,, A2AAGENT_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 ejemplotools,skillMd) se encuentran debajo del descriptor principal. additionalData El inlineContent campo se convierte en. data Los protocolVersion campos schemaVersion y se consolidan endataSchemaVersion.

El synchronizationConfiguration atributo de nivel superior pasa a estar dentro de cada descriptor (incluidos los secundarios) source y se mueve dentro de éladditionalData.

El name campo existente pasa a serdisplayName, 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

sourcees 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 (menormcpServer.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

SearchRegistryRecordsse convierte en SearchDiscoverableRegistryRecords (POST /discoverable-records-search). Su solicitud y respuesta recogen los nuevos nombres de campo y modelo de datos:

Filtrar por recordType (reemplazadescriptorType).
Filtrar por recordVersion (reemplazaversion).
La respuesta devuelve los descriptores en el nuevo formato, sin credentialProviderConfigurations ellos.

La herramienta de búsqueda MCP search_registry_records pasa a sersearch_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": "<dotted.path>", "values": ["<value>"] } 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 endiscoveryConfiguration), registro de registro nuevos campos (nameyrecordType), 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.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Resolución de problemas

Seguridad