Guía completa de migración de registros

AWS Registro de agentes: migración al nuevo espacio de nombres agent-registry

Introducción

Como parte del lanzamiento del nuevo espacio de agent-registry nombres el 6 de agosto de 2026, AWS Agent Registry está introduciendo cambios importantes en el principal del servicio, los datos y el modelo de API. Si usó AWS Agent Registry en el espacio de bedrock-agentcore nombres, debe completar una migración que abarque tres áreas:

Esta guía cubre cada área en detalle con ejemplos del antes y el después para ayudarlo a planificar y ejecutar la migración.

¿Cuál es el cronograma de migración?

Hay dos hitos importantes que debes recordar para esta migración:

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.

Puntos de conexión de servicio

Sus aplicaciones deben apuntar a los nuevos nombres de host de los terminales. Los nuevos puntos finales utilizan el .api.aws dominio.

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.

Si tienes una automatización que analiza los ARN o los almacena, actualiza también esas referencias. Las políticas personalizadas con condiciones en el prefijo de acción o el principal de servicio de IAM deben actualizarse para que coincidan con los nuevos valores. Para ver la lista completa de los permisos de IAM asociados al registro de AWS agentes, consulte la referencia de permisos de IAM del registro de AWS agentes.

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 nuevo espacio de nombres de la CLI.

Si anteriormente solicitaste aumentos de cuotas personalizados con el código bedrock-agentcore de servicio, debes volver a solicitarlos aquí. agent-registry

Observabilidad y eventos

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

EventBridge notificaciones

En el espacio de bedrock-agentcore nombres, AWS Agent Registry emitió dos EventBridge eventos de Amazon en la fuente del aws.bedrock-agentcore evento. La fuente de eventos ahora pasa a seraws.agent-registry, los ARN de los recursos adoptan el nuevo espacio de nombres y la cobertura de las notificaciones se amplía a todo el ciclo de vida del registro, el registro y el registro. Los eventos siguen yendo al EventBridge bus predeterminado de la propia cuenta del recurso. Debes actualizar todas EventBridge las reglas que coincidan en la antigua fuente o en las cadenas de tipo detalle antiguas.

Registry-record eventos. Se emite cuando un registro de registro pasa de un estado a otro del flujo de trabajo de aprobación. Resourceses el ARN completo del registro; contiene y. detail registryRecordId registryId

Registrar eventos. Se emite durante el aprovisionamiento del registro y las transiciones del ciclo de vida. Resourceses el ARN completo del registro; detail contiene registryId y. registryName

Ejemplo de evento (registro de registro).

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

{
  "version": "0",
  "detail-type": "Registry Record State changed to Pending Approval",
  "source": "aws.bedrock-agentcore",
  "account": "123456789012",
  "region": "us-west-2",
  "resources": ["arn:aws:bedrock-agentcore:us-west-2:123456789012:registry/REG_ID/record/REC_ID"],
  "detail": { "registryRecordId": "REC_ID", "registryId": "REG_ID" }
}

Después (espacio de agent-registry nombres):

{
  "version": "0",
  "detail-type": "Registry Record State changed to Pending Approval",
  "source": "aws.agent-registry",
  "account": "123456789012",
  "region": "us-west-2",
  "resources": ["arn:aws:agent-registry:us-west-2:123456789012:registry/REG_ID/record/REC_ID"],
  "detail": { "registryRecordId": "REC_ID", "registryId": "REG_ID" }
}

Ejemplo: actualizar las políticas de IAM

Sustituya el prefijo de la acción y el espacio de nombres ARN del recurso en todas sus políticas de IAM.

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

{
  "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 (espacio de agent-registry nombres):

{
  "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:*"]
  }]
}

"bedrock-agentcore:CreateWorkloadIdentity",
"bedrock-agentcore:GetWorkloadIdentity",
"bedrock-agentcore:DeleteWorkloadIdentity"

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 (espacio de bedrock-agentcore nombres, quedará obsoleto):

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 (espacio de agent-registry nombres):

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: actualizar los comandos de la CLI

Sustituya el espacio de nombres de la CLI en todos los scripts y automatizaciones.

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

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 (espacio de agent-registry nombres):

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 del espacio de agent-registry nombres. Estos cambios mejoran la coherencia y la extensibilidad de la API en función de los comentarios del espacio de nombres. bedrock-agentcore Esta sección cubre cada categoría de cambio con ejemplos de antes y 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 la forma en que se accede al plano de datos del registro, ahora se encuentra en un discoveryConfiguration contenedor dedicado 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 de enumeración booleana a una matriz de enumeración extensible.

Los cambios de campo específicos son:

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

{
  "name": "string",
  "description": "string",
  "authorizerConfiguration": { ... },
  "authorizerType": "string",
  "approvalConfiguration": {
    "autoApproval": true
  }
}

Después (espacio de agent-registry nombres): con Approval ALL

{
  "name": "string",
  "description": "string",
  "discoveryConfiguration": {
    "authorizerConfiguration": { ... },
    "authorizerType": "string"
  },
  "approvalConfiguration": {
    "autoApprovalRules": ["APPROVE_ALL"]
  }
}

Después (espacio de agent-registry nombres): 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 incluyen dos nuevos campos obligatorios de nivel superior para facilitar la categorización y la deduplicación. Debe especificar ambos campos al crear un registro de registro mediante la CreateRegistryRecord API y puede cambiarlos más adelante mediante la API. UpdateRegistryRecord

Cambio 3: Reestructuración de registros

El descriptors campo pasa de ser una unión discriminada a una estructura de clave plana.

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 burda de protocolo o formato. Ese campo ya no existe. recordType, un atributo de nivel superior independiente, lo reemplaza en la categorización semántica. La API aplica claves descriptoras válidas para cada uno recordType en tiempo de ejecución, en lugar de hacerlo estructuralmente en la forma. Cada clave de nivel superior que aparece 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 pasa a ser. data Los protocolVersion campos schemaVersion y se consolidan endataSchemaVersion.

El synchronizationConfiguration atributo de nivel superior se convierte en 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 nuevo desde cero sirve como clave de deduplicación y debe ser único en todos los registros de un registro. Si especifica ambos name recordVersion para el mismo registro, su combinación debe ser única.

Se cambia el nombre de los siguientes campos:

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

{
  "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 (espacio de agent-registry nombres):

{
  "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"
    }
  }
  ...
}

Existen las siguientes limitaciones:

Se puede rellenar exactamente una clave descriptora principal por registro. Los descriptores principales válidos por recordType son:

sourcees por descriptor y no por bloque único de nivel superior. Se adjunta a los descriptores que contienen un source campo en el esquema, y. mcpServer a2aAgentCard El tools hijo (debajomcpServer.additionalData), el agentSkillsDefinition padre y el custom descriptor no llevan el número. source

En el espacio de agent-registry nombres, solo source.fromUrl se admite.

Auto-synchronization solo se activa para los descriptores mcpServer y a2aAgentCard principales, es decir, los tipos de registro MCP y AGENT. La letra «sourceon» del skillMd hijo persiste, pero no se usa para ejecutar la sincronización, y los registros SKILL no se pueden sincronizar automáticamente. Los registros PERSONALIZADOS se deben crear manualmente proporcionándolos directamente. data

Cambio 4: actualizaciones de los filtros 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:

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

Cambio 5: Nuevas API de navegación

Dos nuevas API de plano de datos permiten crear experiencias de navegación y catálogo a partir de los registros aprobados. Estas API no requieren ninguna migración explícita; las mencionamos aquí como adiciones al modelo de API de registro de AWS agentes en el espacio de agent-registry nombres.

ListDiscoverableRegistryRecords— Devuelve una lista paginada de los registros de registro aprobados. Utilícela 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 los detalles completos 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 ID de registro). La forma agrupada es compatible desde el futuro con el procesamiento por lotes entre registros en versiones futuras.

Cambio 6: las API de lista adoptan el parámetro de filtros estructurados

En el espacio de bedrock-agentcore nombres, las API de lista muestran cada campo filtrable como su propio parámetro de consulta (por ejemplo,--status READY). --recordType MCP En el espacio de agent-registry nombres, un único filters parámetro estructurado reemplaza 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 en lugar de 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) no se modifican.

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

GET /registries?status=READY&authorizerType=AWS_IAM
GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP

Después (espacio de agent-registry nombres):

// 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 espacio de nombres al espacio de bedrock-agentcore nombres. agent-registry Proporcionamos una herramienta de migración para ayudar con la migración. La herramienta se encarga de 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. La herramienta crea nuevos registros en el espacio de agent-registry nombres dentro de la misma cuenta y región. Migra todos los registros existentes de tus registros antiguos a los nuevos, teniendo en cuenta los cambios en el espacio de nombres y en el esquema de la API.

La herramienta de migración está disponible en el repositorio agentcore-samples del sitio web. GitHub Para obtener instrucciones de configuración completas, referencias de comandos y orientación operativa, consulte el archivo README del repositorio.

Cómo elegir el enfoque de migración

El enfoque correcto depende de si basta con una migración completa de una sola vez o de si se necesita una ejecución desatendida y la capacidad de ejecutar una carga incremental en el momento de la transición.

Caso 1: migración sencilla

Caso 2: migración gestionada con AWS Adherencia

Caso 3: migración Active-active

Verificación de la migración

Tras ejecutar la migración, confirme que los datos se han migrado correctamente:

Actualice las políticas de confianza de IAM para los registros sincronizados

Si alguno de tus registros utiliza la opción Sincronizar con el tipo de credencial de rol de IAM, debes actualizar la política de confianza del rol antes de ejecutar la carga en tiempo real. El principal de servicio que asume el rol cambió de bedrock-agentcore.amazonaws.com a agent-registry.amazonaws.com en en el nuevo espacio de nombres. Los registros que utilizan credenciales de OAuth o no tienen autorización no se ven afectados.

Actualice la política de confianza del rol al que hace referencia cada registro afectado.

Antes (espacio de bedrock-agentcore nombres, quedará obsoleto):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Después (espacio de agent-registry nombres):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "agent-registry.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Si un registro ya ha fallado por este motivo, el registro migrado existe en CREATE_FAILED estado. La herramienta de migración se niega a sobrescribir un registro en estado de error, por lo que corregir la política de confianza por sí solo no resuelve el problema. Para recuperarlo:

Preguntas frecuentes

¿Qué está cambiando en AWS ¿Registro de agentes?

AWS El registro de agentes se está trasladando del espacio de bedrock-agentcore nombres al nuevo espacio de agent-registry nombres dedicado. La migración abarca tres áreas: cambios en el espacio de nombres y configuración (puntos finales, IAM, SDK, CLI, ARN, observabilidad), cambios en el esquema de 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 básico de agentcore?

Su uso actual del Registro en el espacio de bedrock-agentcore nombres continúa funcionando sin interrupción durante el período de migración. Sin embargo, le recomendamos que comience la migración tan pronto como las herramientas estén disponibles para asegurarse de que dispone de tiempo suficiente para completar tanto la migración de datos como las actualizaciones del código.

Sin embargo, si no tenía registros o registros existentes al 6 de agosto de 2026, no podrá acceder al espacio de bedrock-agentcore nombres del Registro de AWS agentes a partir del 6 de agosto de 2026. Si tenía registros o registros existentes al 6 de agosto de 2026, tendrá acceso al espacio de bedrock-agentcore nombres del Registro de AWS agentes 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 proporcionamos. Consulta la sección Migración de datos para obtener más información sobre los enfoques disponibles en función de tu escala.

¿Qué cambios en el esquema de la API se incluyen?

Además del cambio en el espacio de nombres, actualizamos el modelo de datos de la API en seis áreas: la entidad de registro (la configuración de autorización se agrupa endiscoveryConfiguration), los nuevos campos del registro (nameyrecordType) del registro, la reestructuración del registro (los descriptores se han reducido y los nombres de los campos), las actualizaciones de los filtros de la API de búsqueda (,)recordType, las nuevas API de navegación (ListDiscoverableRegistryRecords,recordVersion) y los filtros estructurados para las operaciones de lista. BatchGetDiscoverableRegistryRecord

¿Cuánto tiempo durará 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, espera que la migración se complete en menos de 15 minutos si se ejecuta como una tarea gestionada.

¿Qué sucede si tengo una implementación a gran escala con escrituras activas?

Si está escribiendo datos de forma activa en el espacio de bedrock-agentcore nombres en producción, utilice el enfoque de migración activa-activa tal como se describe en el caso 3. Comience con una migración completa para actualizar el espacio de agent-registry nombres y, a continuación, escriba en ambos espacios de nombres simultáneamente para validar sus integraciones y fomentar la confianza en el nuevo espacio de nombres. Reduzca las lecturas y escrituras para agent-registry cuando esté listo.

¿Dónde puedo obtener ayuda?

Si tienes preguntas o necesitas ayuda con la migración, ponte en contacto con el equipo de AWS soporte.