Introdução Qual é o cronograma de migração?Alterações no namespace e na configuração Alterações no esquema da API Migrações de dados Perguntas frequentes

Guia abrangente de migração do registro

AWS Registro de agentes — migrando da versão prévia pública para a disponibilidade geral

Introdução

Como parte do lançamento como Generally Available (GA) em 6 de agosto de 2026, o AWS Agent Registry está introduzindo mudanças significativas no princípio do serviço, nos dados e no modelo de API. Se você usou o AWS Agent Registry durante a pré-visualização pública, deverá concluir uma migração que abrange três áreas:

Alterações no namespace e na configuração — Estamos migrando o AWS Agent Registry do namespace AWS Bedrock para seu AgentCore próprio namespace dedicado. Essa alteração de namespace se aplica somente ao Registro do AWS Agente. Todas as outras AgentCore ofertas, como Identity, Gateway, Runtime e Policy, permanecem inalteradas. Para o AWS Agent Registry, o namespace do serviço muda de bedrock-agentcore para. agent-registry Isso afeta todas as superfícies que fazem referência ao serviço: endpoints, políticas do IAM, clientes do SDK, comandos da CLI, ARNs de recursos e integrações de observabilidade. Você deve atualizar seu código e sua infraestrutura para usar o novo namespace.
Alterações no esquema da API — Os modelos de dados de registro e registro de registro são atualizados com base nos comentários dos clientes durante a pré-visualização pública. Essas alterações quebram a compatibilidade com versões anteriores dos esquemas de API existentes. O código do aplicativo que constrói ou analisa as solicitações e respostas da API deve ser atualizado para refletir o novo esquema, como parte da migração para o novo namespace.
Migração de dados — Você deve migrar seus registros e registros de registro existentes do namespace antigo para o novo. Fornecemos ferramentas de migração para extrair seus dados, transformá-los no novo esquema e carregá-los no novo namespace. Os dados são migrados para a mesma conta e região — somente o namespace é alterado.

Este guia aborda cada área em detalhes com exemplos de antes e depois para ajudá-lo a planejar e executar sua migração.

Qual é o cronograma de migração?

Há dois marcos importantes que você deve lembrar para essa migração:

6 de agosto de 2026 — O Registro de AWS Agentes se torna disponível ao público em geral e o novo agent-registry namespace é lançado oficialmente. Se você tiver registros e registros existentes, terá acesso simultâneo aos namespaces bedrock-agentcore e. agent-registry As ferramentas de migração ficam disponíveis no repositório GitHub agentcore-samples. Você pode começar o processo de migração.

nota
Se você for um novo cliente sem registros ou registros existentes em 6 de agosto de 2026, não poderá acessar o Registro do AWS Agente por meio do bedrock-agentcore namespace. Comece a usar o AWS Agent Registry diretamente do agent-registry namespace.
17 de setembro de 2026 — A janela de migração se fecha. O bedrock-agentcore namespace antigo será encerrado nessa data. Você perde o read/write acesso ao serviço e a todos os dados restantes no namespace antigo. Após essa data, você deve usar o agent-registry namespace.

Alterações no namespace e na configuração

O agent-registry namespace é substituído bedrock-agentcore nos seguintes lugares. Esta seção lista todas as superfícies que mudam e fornece exemplos de como atualizar seu código.

Importante

As mudanças no namespace afetam apenas as APIs oferecidas pelo AWS Agent Registry, mas não o resto do AWS Bedrock AgentCore, como Identity. AWS AgentCore Assim, a identidade da carga de trabalho e os recursos do provedor de credenciais OAuth permanecem sob o namespace. bedrock-agentcore

Service endpoints

Seus aplicativos devem apontar para os novos nomes de host do endpoint. Os novos endpoints usam o .api.aws domínio.

Surface	Valor antigo	Novo valor
Ponto final do plano de dados	`bedrock-agentcore.{region}.amazonaws.com`	`agent-registry.{region}.api.aws`
Endpoint do ambiente de gerenciamento	`bedrock-agentcore-control.{region}.amazonaws.com`	`agent-registry-control.{region}.api.aws`

IAM e segurança

Todas as políticas do IAM, políticas de controle de serviços (SCPs) e limites de permissão referenciados bedrock-agentcore devem ser atualizados. Os ARNs de recursos também mudam para refletir o novo namespace.

Surface	Valor antigo	Novo valor
Prefixo de ação do IAM	`bedrock-agentcore:*`	`agent-registry:*`
Entidade principal do serviço	`bedrock-agentcore.amazonaws.com`	`agent-registry.amazonaws.com`
ARN do registro	`arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}`	`arn:aws:agent-registry:{region}:{account}:registry/{id}`
ARN do registro	`arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}`	`arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}`

Se você tiver uma automação que analisa ARNs ou os armazena, atualize essas referências também. Políticas personalizadas com condições no prefixo de ação do IAM ou no principal do serviço devem ser atualizadas para corresponder aos novos valores. Para ver a lista completa das permissões do IAM associadas ao AWS Agent Registry, consulte a referência de permissões do AWS Agent Registry IAM.

nota

Se você usa atualmente a Política BedrockAgentCoreFullAccess AWS Gerenciada para acesso ao Registro do AWS Agente (consulte os detalhes da BedrockAgentCoreFullAccess política), deverá substituí-la pela nova política AgentRegistryFullAccessgerenciada (disponível no GA). A política BedrockAgentCoreFullAccess gerenciada antiga NÃO será atualizada para incluir agent-registry:* permissões.

SDK, CLI e infraestrutura

Atualize o código do aplicativo, os scripts de implantação e os modelos de infraestrutura como código para referenciar a nova classe de cliente e o namespace da CLI.

Surface	Valor antigo	Novo valor
Classe de cliente Dataplane SDK	`BedrockAgentCoreClient`	`AgentRegistryClient`
Classe de cliente Controlplane SDK	`BedrockAgentCoreControlClient`	`AgentRegistryControlClient`
Namespace CLI	`aws bedrock-agentcore`	`aws agent-registry`
Código de Service Quotas	`bedrock-agentcore`	`agent-registry`

Se você solicitou anteriormente aumentos de cota personalizados de acordo com o código de bedrock-agentcore serviço, deverá solicitá-los novamente em. agent-registry

Observabilidade e eventos

Atualize todas as consultas do CloudTrail Lake, consultas do Athena, integrações de SIEM, regras EventBridge CloudWatch , painéis e alarmes que façam referência ao namespace antigo.

Surface	Valor antigo	Novo valor
CloudTrail fonte do evento	`bedrock-agentcore.amazonaws.com`	`agent-registry.amazonaws.com`
EventBridge fonte	`aws.bedrock-agentcore`	`aws.agent-registry`
CloudWatch namespace	`AWS/BedrockAgentCore`	`AWS/AgentRegistry`

Exemplo: atualização das políticas do IAM

Substitua o prefixo da ação e o namespace ARN do recurso em todas as suas políticas do IAM.

Antes (versão prévia 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:*"]
  }]
}

Depois (disponibilidade geral):


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

A BatchGetDiscoverableRegistryRecord API não tem sua própria ação do IAM. Ele autoriza cada registro solicitado contra a agent-registry:GetDiscoverableRegistryRecord ação. Certifique-se de que sua política GetDiscoverableRegistryRecord inclua o usoBatchGet.

Importante

A identidade da carga de trabalho e os recursos do provedor de credenciais OAuth permanecem sob o namespace. bedrock-agentcore Se seus registros usam URL sync (source.fromUrl) com credenciais OAuth ou IAM, você deve manter as seguintes permissões junto com suas novas permissões: agent-registry:*


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

Não substitua todas as bedrock-agentcore ações — esses recursos de identidade retêm intencionalmente o namespace antigo.

Exemplo: atualização da configuração do cliente SDK

Atualize o nome do serviço, a classe do cliente e o URL do endpoint em suas chamadas do SDK.

Antes (versão prévia 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"
)

Depois (disponibilidade geral):


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"
)

Exemplo: atualização de comandos da CLI

Substitua o namespace CLI em todos os scripts e automação.

Antes (versão prévia 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

Depois (disponibilidade geral):


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

Alterações no esquema da API

Além da migração do namespace, atualizamos o registro e os modelos de dados do registro de registro para disponibilidade geral. Essas mudanças melhoram a consistência e a extensibilidade da API com base no feedback da versão prévia pública. Esta seção aborda cada categoria de alteração com exemplos de antes e depois para que você possa atualizar o código do seu aplicativo.

Alteração 1: atualizações da entidade de registro

A configuração de autorização no recurso de registro — que controla como o plano de dados de um registro é acessado — agora fica sob um discoveryConfiguration invólucro dedicado que torna sua finalidade explícita. A configuração de aprovação (que controla se os registros enviados ao PENDING_APPROVAL status são automaticamente transferidos para o APPROVED status) passa de uma matriz booleana para uma matriz de enumeração extensível.

As alterações específicas do campo são:

authorizerTypee authorizerConfiguration são movidos para dentro de um novo discoveryConfiguration objeto.
approvalConfiguration.autoApproval(booleano) é substituído por approvalConfiguration.autoApprovalRules (matriz de cadeias de caracteres enumeradas). O valor "APPROVE_ALL" tem o mesmo significado semântico queautoApproval: true. As regras especificadas na lista de enumeração são aplicadas. Não especificar (nulo) significa que a aprovação é necessária.

Antes (versão prévia pública):


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

Depois (disponibilidade geral): com aprovação ALL


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

Depois (disponibilidade geral): com NULL na lista de enumeração


{
  "name": "string",
  "description": "Registry with manual approval only",
  "approvalConfiguration": {
    "autoApprovalRules": []
  }
}

Alteração 2: Novos campos obrigatórios nos registros do registro

Os registros de registro ganham dois novos campos obrigatórios de nível superior para oferecer suporte a uma melhor categorização e desduplicação. Você deve especificar os dois campos ao criar um registro de registro usando a CreateRegistryRecord API e pode alterá-los posteriormente usando a UpdateRegistryRecord API.

Campo	Tipo	Description
`name`	Cadeia de caracteres (obrigatório)	Um identificador exclusivo no registro que pode ser especificado pelo cliente. Cada registro deve ter um nome exclusivo no registro. Quando também `recordVersion` está presente, a combinação de `name` e `recordVersion` deve ser única.
`recordType`	Enum (obrigatório)	O tipo semântico do registro. Valores válidos: `AGENT`, `MCP`, `SKILL`, `CUSTOM`. Determina em qual chave do descritor primário é válida. `descriptors` Você pode usar APIs como `ListRegistryRecords` e `SearchDiscoverableRegistryRecords` para filtrar os resultados por esse tipo semântico.

Alteração 3: reestruturação do registro de registro

O descriptors campo muda de uma união discriminada para uma estrutura de chave plana.

No modelo anterior, o descriptorType campo (MCP,, A2AAGENT_SKILLS,CUSTOM) determinava a forma interna. Isso acoplou o conteúdo do descritor a um protocolo ou classificação de formato aproximado. Esse campo não existe mais. recordType, um atributo de nível superior separado, o substitui para categorização semântica. A API impõe chaves descritoras válidas para cada uma recordType em tempo de execução, em vez de estruturalmente na forma. Cada chave de nível superior abaixo descriptors agora representa um tipo de descritor primário granular (por exemplo,,, a2aAgentCardmcpServer,agentSkillsDefinition). custom Os descritores suplementares (por exemplo,tools,skillMd) se aninham abaixo dos descritores primários. additionalData O inlineContent campo se tornadata. Os protocolVersion campos schemaVersion e se consolidam em. dataSchemaVersion

O synchronizationConfiguration atributo de nível superior se torna source e se move dentro de cada descritor (incluindo additionalData filhos).

O name campo existente se tornadisplayName, tornando seu significado mais explícito. Um novo name campo líquido serve como chave de desduplicação e deve ser exclusivo em todos os registros em um registro. Se você especificar ambos name e recordVersion para o mesmo registro, a combinação deles deverá ser exclusiva.

Os campos a seguir foram renomeados:

Before	Depois	Observações
`name`	`displayName`	Nome de exibição do registro. Também haverá um novo `name` campo que é a chave de desduplicação.
`descriptorType`	Remoção	Substituído pelo `recordType` campo de nível superior.
`inlineContent`	`data`	A carga útil do conteúdo em cada descritor.
`schemaVersion` / `protocolVersion`	`dataSchemaVersion`	Campo de versão unificado para todos os tipos de descritores.
`synchronizationConfiguration`	`source`	Movido para dentro de cada descritor (incluindo `additionalData` crianças).

Antes (versão prévia 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"
        }
      ]
    }
  },
  ...
}

Depois (disponibilidade geral):


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

As limitações a seguir aplicam-se:

Exatamente uma chave descritora primária pode ser preenchida por registro. Os descritores primários válidos por recordType são:

AGENTE:a2aAgentCard,mcpServer, custom
MCP:mcpServer, custom
HABILIDADE:agentSkillsDefinition, custom
PERSONALIZADO: custom

sourceé por descritor em vez de um único bloco de nível superior. Ele se anexa a descritores que carregam um source campo no esquema — e. mcpServer a2aAgentCard A tools criança (menor de mcpServer.additionalData idade), o agentSkillsDefinition pai e o custom descritor não source têm.

No GA, somente source.fromUrl é suportado.

Auto-synchronization só é acionado para os mcpServer descritores a2aAgentCard primários, ou seja, os tipos de registro MCP e AGENT. A source na skillMd criança persiste, mas não é usada para executar a sincronização, e os registros SKILL não podem ser sincronizados automaticamente. Os registros PERSONALIZADOS devem ser criados manualmente, fornecendo data diretamente.

Alteração 4: atualizações do filtro do plano de dados

SearchRegistryRecordsse torna SearchDiscoverableRegistryRecords (POST /discoverable-records-search). Sua solicitação e resposta selecionam os novos nomes de campo e modelo de dados:

Filtrar por recordType (substituidescriptorType).
Filtrar por recordVersion (substituiversion).
A resposta retorna descritores no novo formato, semcredentialProviderConfigurations.

A ferramenta de pesquisa MCP search_registry_records se tornasearch_discoverable_registry_records, retorna o novo formato do descritor e usa os novos nomes dos filtros.

Alteração 5: novas APIs de navegação

Duas novas APIs de plano de dados oferecem suporte à criação de experiências de navegação e catálogo sobre registros aprovados. Essas APIs não exigem nenhuma migração explícita; nós as mencionamos aqui como adições ao modelo de API do AWS Agent Registry no GA.

ListDiscoverableRegistryRecords— Retorna uma lista paginada de registros de registro aprovados. Use isso para criar interfaces de navegação sobre o conteúdo 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 os detalhes de um lote de registros em um ou mais registros em uma única chamada.


// 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"
    }
  ]
}

A resposta inclui uma registryRecords matriz com os detalhes completos do registro e uma errors matriz para todos os registros que não puderam ser recuperados.

No lançamento, exatamente uma entrada (um registro, 1-100 IDs de registro) é aceita. A forma agrupada é compatível com versões futuras com lotes de registros cruzados em versões futuras.

Alteração 6: APIs de lista adotam parâmetros de filtros estruturados

Na visualização pública, as APIs de lista expõem cada campo filtrável como seu próprio parâmetro de consulta (por exemplo,,--status READY). --recordType MCP No GA, um único filters parâmetro estruturado substitui esses parâmetros discretos. O filters valor é uma lista de { "name": "<dotted.path>", "values": ["<value>"] } entradas em que name há um caminho de atributo delimitado por pontos. Novos campos filtráveis, incluindo os aninhados, se tornam novos name caminhos em vez de novos parâmetros de API. As operações de lista também mudam de GET paraPOST. Os parâmetros de paginação (maxResults,nextToken) permanecem inalterados.

Antes (versão prévia pública):


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

Depois (disponibilidade geral):


// 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"
}

Migrações de dados

Você deve migrar seus registros e registros de registro existentes do namespace para o bedrock-agentcore namespace. agent-registry Fornecemos um script para auxiliar na migração. O script lida com a extração de dados existentes, a transformação do esquema antigo para o novo esquema e o carregamento em registros no novo namespace. O script cria novos registros no agent-registry namespace dentro da mesma conta e região. Ele migra todos os registros existentes dos seus registros antigos para os novos, levando em conta as alterações no namespace e no esquema da API.

Escolhendo sua abordagem de migração

A abordagem correta depende da escala de uso do registro e do ambiente operacional.

Caso 1: Small-scale migração com execução direta de script

Perfil: Menos de 5 registros e menos de 100 registros. Você tem acesso direto a um terminal ou CloudShell à conta de destino.
Abordagem: execute o script Python de migração diretamente. O script se conecta ao namespace de visualização, lista seus registros e registros, transforma os dados no esquema GA e os cria no novo namespace. Esse é o caminho mais simples e não requer implantação de infraestrutura.

Caso 2: migração gerenciada com Lambda ou Glue

Perfil: Você não tem acesso direto ao terminal ao ambiente de destino ou prefere um modelo de execução gerenciado.
Abordagem: implante a migração como uma função AWS Lambda ou uma tarefa do AWS Glue. O mecanismo de migração executa o mesmo fluxo de trabalho de extração, transformação e carregamento, mas é executado como um trabalho gerenciado em sua conta. Para a maioria das contas, a migração completa é concluída em menos de 15 minutos.

O mecanismo de migração:

Extrai registros e registros do namespace de visualização, suportando cargas completas e incrementais. Ele pagina todas as respostas da API e serializa os dados em um local de teste.
Transforma cada registro aplicando as alterações do esquema da API (renomeação de campo, reestruturação do descritor, novos campos obrigatórios).
Carrega os dados transformados no novo agent-registry namespace, criando registros e registros usando a API GA.
Gera um relatório resumindo o que foi migrado, quaisquer erros encontrados e contagens de registros para verificação.

Caso 3: Dual-write migração para cargas de trabalho de produção ativas

Perfil: você criou uma plataforma ou um pipeline de automação com base nas APIs de visualização pública e está gravando ativamente novos dados na produção.
Abordagem: use uma estratégia de migração de gravação dupla para evitar a perda de dados durante a transição:
- Atualize seu gravador — modifique seu aplicativo para gravar no namespace de visualização e no novo agent-registry namespace simultaneamente.
- Execute o script de migração com desduplicação — execute as ferramentas de migração para migrar dados históricos. O script desduplica com base no name campo, para que os registros que já existem no novo namespace (da sua gravação dupla) não sejam duplicados.
- Troque seu leitor — Depois de verificar se todos os dados existem no novo namespace, atualize seu aplicativo para ler exclusivamente do. agent-registry
- Remova a gravação dupla — Depois de confirmar que todas as leituras e gravações foram bem-sucedidas no novo namespace, remova o gravador do namespace de visualização do seu aplicativo.

Verificando sua migração

Depois de executar a migração, confirme se seus dados foram migrados corretamente:

Liste todos os registros no novo namespace usando o comando list-registries CLI e confirme se a contagem corresponde à sua fonte.
Para cada registro, compare a contagem de registros usandolist-registry-records.
Spot-check registros individuais para confirmar que os descritores foram transformados corretamente (renomeação de campo, reestruturação de descritores).
Atualize suas políticas, endpoints e clientes SDK do IAM conforme descrito na seção Alterações de namespace e configuração.
Verifique se seus aplicativos conseguem ler e gravar com êxito usando o novo namespace.

Perguntas frequentes

O que está mudando em AWS Registro de agentes?

AWS O Agent Registry está migrando do bedrock-agentcore namespace de visualização pública para o namespace geralmente disponívelagent-registry. A migração abrange três áreas: alterações no namespace e na configuração (endpoints, IAM, SDK, CLI, ARNs, observabilidade), alterações no esquema da API (modelo de dados reestruturado para registros e registros) e migração de dados (mover seus registros e registros existentes para o novo namespace).

Posso continuar usando o Registry no namespace `bedrock-agentcore`?

Seu uso atual do Registro no bedrock-agentcore namespace continua funcionando sem interrupção durante a janela de migração. No entanto, recomendamos que você inicie sua migração assim que as ferramentas estiverem disponíveis para garantir que você tenha tempo suficiente para concluir a migração de dados e as atualizações de código.

No entanto, se você não tiver registros ou registros existentes em 6 de agosto de 2026, não poderá acessar o bedrock-agentcore namespace do Registro do AWS Agente a partir de 6 de agosto de 2026. Se você tiver registros ou registros existentes em 6 de agosto de 2026, terá acesso ao bedrock-agentcore namespace do Registro do AWS Agente durante a janela de migração (6 de agosto de 2026 a 17 de setembro de 2026).

Meus dados serão migrados automaticamente?

Não. Você mesmo deve iniciar a migração usando as ferramentas de migração que fornecemos. Consulte a seção Migração de dados para obter detalhes sobre as abordagens disponíveis com base em sua escala.

Quais mudanças no esquema da API estão incluídas?

Além da alteração do namespace, atualizamos o modelo de dados da API em seis áreas: entidade de registro (configuração de autorização agrupada emdiscoveryConfiguration), novos campos do registro do registro (nameerecordType), reestruturação do registro do registro (descritores nivelados, renomeações de campos), atualizações do filtro da API de pesquisa (,), novas APIs de navegação (recordType,recordVersion) e filtros estruturados para operações de lista. ListDiscoverableRegistryRecords BatchGetDiscoverableRegistryRecord

Quanto tempo levará a migração de dados?

O tempo de migração depende do número de registros e registros em sua conta. Para contas com menos de 100 registros, a migração é concluída em minutos quando executada localmente. Para contas com milhares de registros, espere que a migração seja concluída em menos de 15 minutos quando executada como um trabalho gerenciado.

E se eu tiver uma implantação em grande escala com gravações ativas?

Se você estiver gravando dados ativamente no namespace de visualização em produção, use a estratégia de migração de gravação dupla, conforme descrito no Caso 3. Essa abordagem garante que nenhum dado seja perdido durante a transição, gravando nos dois namespaces simultaneamente, migrando dados históricos com desduplicação e, em seguida, cortando as leituras.

Onde posso obter ajuda?

Em caso de dúvidas ou assistência com sua migração, entre em contato com o AWS Support.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Solução de problemas

Segurança

Guia abrangente de migração do registro

Introdução

Qual é o cronograma de migração?

nota

Alterações no namespace e na configuração

Importante

Service endpoints

IAM e segurança

nota

SDK, CLI e infraestrutura

Observabilidade e eventos

Exemplo: atualização das políticas do IAM

nota

Importante

Exemplo: atualização da configuração do cliente SDK

Exemplo: atualização de comandos da CLI

Alterações no esquema da API

Alteração 1: atualizações da entidade de registro

Alteração 2: Novos campos obrigatórios nos registros do registro

Alteração 3: reestruturação do registro de registro

Alteração 4: atualizações do filtro do plano de dados

Alteração 5: novas APIs de navegação

Alteração 6: APIs de lista adotam parâmetros de filtros estruturados

Migrações de dados

Escolhendo sua abordagem de migração

Caso 1: Small-scale migração com execução direta de script

Caso 2: migração gerenciada com Lambda ou Glue

Caso 3: Dual-write migração para cargas de trabalho de produção ativas

Verificando sua migração

Perguntas frequentes

O que está mudando em AWS Registro de agentes?

Posso continuar usando o Registry no namespace bedrock-agentcore?

Meus dados serão migrados automaticamente?

Quais mudanças no esquema da API estão incluídas?

Quanto tempo levará a migração de dados?

E se eu tiver uma implantação em grande escala com gravações ativas?

Onde posso obter ajuda?

Posso continuar usando o Registry no namespace `bedrock-agentcore`?