# Guide complet de migration de registre
* AWS Registre des agents : migration de la version préliminaire publique à la disponibilité générale*
## Introduction
Dans le cadre du lancement en tant que service généralement disponible (GA) le 6 août 2026, AWS Agent Registry introduit des modifications importantes au principal du service, aux données et au modèle d'API. Si vous avez utilisé AWS Agent Registry lors de la version préliminaire publique, vous devez effectuer une migration qui couvre trois domaines :
1. **Changements d'espace de noms et de configuration** — Nous déplaçons le registre des AWS agents de l'espace de AgentCore noms AWS Bedrock vers son propre espace de noms dédié. Ce changement d'espace de noms s'applique uniquement au registre des AWS agents. Toutes les autres AgentCore offres, telles que Identity, Gateway, Runtime et Policy, restent inchangées. Pour le registre des AWS agents, l'espace de noms du service passe de `bedrock-agentcore` à`agent-registry`. Cela affecte toutes les surfaces qui font référence au service : les points de terminaison, les politiques IAM, les clients du SDK, les commandes CLI, les ARN des ressources et les intégrations d'observabilité. Vous devez mettre à jour votre code et votre infrastructure pour utiliser le nouvel espace de noms.
1. **Modifications du schéma de l'API** — Les modèles de données du registre et des enregistrements de registre sont mis à jour en fonction des commentaires des clients lors de la version préliminaire publique. Ces modifications rompent la rétrocompatibilité avec les schémas d'API existants. Le code de votre application qui construit ou analyse les demandes et réponses d'API doit être mis à jour pour refléter le nouveau schéma, dans le cadre de la migration vers le nouvel espace de noms.
1. **Migration des données** : vous devez migrer vos registres et enregistrements de registre existants de l'ancien espace de noms vers le nouveau. Nous fournissons des outils de migration pour extraire vos données, les transformer dans le nouveau schéma et les charger dans le nouvel espace de noms. Les données sont migrées vers le même compte et la même région ; seul l'espace de noms change.
Ce guide couvre chaque domaine en détail avec des exemples avant-après pour vous aider à planifier et à exécuter votre migration.
## Quel est le calendrier de migration ?
Il y a deux étapes importantes dont vous devez tenir compte lors de cette migration :
+ **6 août 2026** — Le registre des AWS agents devient généralement disponible et le nouvel espace de `agent-registry` noms est officiellement lancé. Si vous avez des registres et des enregistrements existants, vous avez accès simultanément aux espaces de `agent-registry` noms `bedrock-agentcore` et. Les outils de migration sont disponibles dans le référentiel [agentcore-samples GitHub ](https://github.com/awslabs/agentcore-samples). Vous pouvez commencer le processus de migration.
**Note**
Si vous êtes un nouveau client sans registres ou enregistrements existants au 6 août 2026, vous ne pouvez pas accéder au registre des AWS agents via l'`bedrock-agentcore`espace de noms. Commencez à utiliser le registre des AWS agents directement depuis l'espace de `agent-registry` noms.
+ **17 septembre 2026** — Fermeture de la fenêtre de migration. L'ancien espace de `bedrock-agentcore` noms s'arrête à cette date. Vous perdez read/write l'accès au service et à toutes les données restantes dans l'ancien espace de noms. Après cette date, vous devez utiliser l'espace de `agent-registry` noms.
## Changements d'espace de noms et de configuration
L'espace de `agent-registry` noms est remplacé `bedrock-agentcore` aux emplacements suivants. Cette section répertorie toutes les surfaces modifiées et fournit des exemples de mise à jour de votre code.
**Important**
Les modifications de l'espace de noms n'affectent que les API proposées par AWS Agent Registry, mais pas le reste de AWS Bedrock AgentCore, comme AWS AgentCore Identity. Ainsi, l'identité de la charge de travail et les ressources du fournisseur d'informations d'identification OAuth restent dans l'espace de noms. `bedrock-agentcore`
### Points de terminaison de service
Vos applications doivent pointer vers les nouveaux noms d'hôte des points de terminaison. Les nouveaux points de terminaison utilisent le `.api.aws` domaine.
| Surface | Ancienne valeur | Nouvelle valeur |
| --- | --- | --- |
| Point final du plan de données | `bedrock-agentcore.{region}.amazonaws.com` | `agent-registry.{region}.api.aws` |
| Point final du plan de contrôle | `bedrock-agentcore-control.{region}.amazonaws.com` | `agent-registry-control.{region}.api.aws` |
### IAM et sécurité
Toutes les politiques IAM, les politiques de contrôle des services (SCP) et les limites d'autorisation auxquelles il est fait référence `bedrock-agentcore` doivent être mises à jour. Les ARN des ressources changent également pour refléter le nouvel espace de noms.
| Surface | Ancienne valeur | Nouvelle valeur |
| --- | --- | --- |
| Préfixe d'action IAM | `bedrock-agentcore:*` | `agent-registry:*` |
| Principal du service | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| ARN du registre | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}` |
| Enregistrer l'ARN | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}` |
Si vous disposez d'une automatisation qui analyse les ARN ou les stocke, mettez également à jour ces références. Les politiques personnalisées assorties de conditions relatives au préfixe d'action IAM ou au principal de service doivent être mises à jour pour correspondre aux nouvelles valeurs. Pour consulter la liste complète des autorisations IAM associées au registre des AWS agents, reportez-vous à la référence des [autorisations IAM du registre des AWS agents](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html).
**Note**
Si vous utilisez actuellement la politique [BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html) AWS gérée pour accéder au registre des AWS agents (voir [les détails de la BedrockAgentCoreFullAccess politique](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam-awsmanpol.html#security-iam-awsmanpol-BedrockAgentCoreFullAccess)), vous devez la remplacer par la nouvelle politique **AgentRegistryFullAccess**gérée (disponible chez GA). L'ancienne politique BedrockAgentCoreFullAccess gérée **ne sera PAS** mise à jour pour inclure `agent-registry:*` les autorisations.
### SDK, CLI et infrastructure
Mettez à jour le code de votre application, vos scripts de déploiement et vos modèles d'infrastructure en tant que code pour faire référence à la nouvelle classe client et à l'espace de noms de la CLI.
| Surface | Ancienne valeur | Nouvelle valeur |
| --- | --- | --- |
| Classe client du SDK Dataplane | `BedrockAgentCoreClient` | `AgentRegistryClient` |
| Classe client du SDK Controlplane | `BedrockAgentCoreControlClient` | `AgentRegistryControlClient` |
| espace de noms CLI | `aws bedrock-agentcore` | `aws agent-registry` |
| Code des Quotas de Service | `bedrock-agentcore` | `agent-registry` |
Si vous avez déjà demandé des augmentations de quotas personnalisées en vertu du code de `bedrock-agentcore` service, vous devez les demander à nouveau en vertu `agent-registry` du code de service.
### Observabilité et organisation d'événements
Mettez à jour les requêtes CloudTrail Lake, les requêtes Athena, les intégrations SIEM, les EventBridge règles, les CloudWatch tableaux de bord et les alarmes qui font référence à l'ancien espace de noms.
| Surface | Ancienne valeur | Nouvelle valeur |
| --- | --- | --- |
| CloudTrail source de l'événement | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| EventBridge source | `aws.bedrock-agentcore` | `aws.agent-registry` |
| CloudWatch espace de noms | `AWS/BedrockAgentCore` | `AWS/AgentRegistry` |
### Exemple : mise à jour des politiques IAM
Remplacez le préfixe d'action et l'espace de noms ARN des ressources dans toutes vos politiques IAM.
**Avant (avant-première publique) :**
```
{
"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:*"]
}]
}
```
**Après (disponibilité générale) :**
```
{
"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:*"]
}]
}
```
**Note**
L'`BatchGetDiscoverableRegistryRecord`API ne possède pas sa propre action IAM. Il autorise chaque enregistrement demandé par rapport à l'`agent-registry:GetDiscoverableRegistryRecord`action. Assurez-vous que votre politique inclut `GetDiscoverableRegistryRecord` l'utilisation`BatchGet`.
**Important**
L'identité de la charge de travail et les ressources du fournisseur d'informations d'identification OAuth restent dans l'espace de noms. `bedrock-agentcore` Si vos registres utilisent URL sync (`source.fromUrl`) avec des informations d'identification OAuth ou IAM, vous devez conserver les autorisations suivantes en plus de vos nouvelles autorisations : `agent-registry:*`
```
"bedrock-agentcore:CreateWorkloadIdentity",
"bedrock-agentcore:GetWorkloadIdentity",
"bedrock-agentcore:DeleteWorkloadIdentity"
```
Ne remplacez pas toutes les `bedrock-agentcore` actions : ces ressources d'identité conservent intentionnellement l'ancien espace de noms.
### Exemple : mise à jour de la configuration du client SDK
Mettez à jour le nom du service, la classe du client et l'URL du point de terminaison dans vos appels au SDK.
**Avant (avant-première publique) :**
```
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"
)
```
**Après (disponibilité générale) :**
```
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"
)
```
### Exemple : mise à jour des commandes CLI
Remplacez l'espace de noms CLI dans tous les scripts et automatismes.
**Avant (avant-première publique) :**
```
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
```
**Après (disponibilité générale) :**
```
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
```
## Modifications du schéma de l'API
Outre la migration de l'espace de noms, nous avons mis à jour les modèles de données du registre et des enregistrements de registre pour la disponibilité générale. Ces modifications améliorent la cohérence et l'extensibilité de l'API en fonction des commentaires issus de la version préliminaire publique. Cette section couvre chaque catégorie de modification avec des exemples avant et après afin que vous puissiez mettre à jour le code de votre application.
### Modification 1 : mises à jour des entités de registre
La configuration d'autorisation sur la ressource de registre, qui contrôle le mode d'accès au plan de données d'un registre, se trouve désormais dans un `discoveryConfiguration` wrapper dédié qui précise son objectif. La configuration d'approbation (qui contrôle si les enregistrements soumis au `PENDING_APPROVAL` statut passent automatiquement au `APPROVED` statut) passe d'un booléen à un tableau d'énumération extensible.
Les modifications spécifiques apportées aux champs sont les suivantes :
+ `authorizerType`et `authorizerConfiguration` sont déplacés à l'intérieur d'un nouvel `discoveryConfiguration` objet.
+ `approvalConfiguration.autoApproval`(booléen) est remplacé par `approvalConfiguration.autoApprovalRules` (tableau de chaînes enum). La valeur `"APPROVE_ALL"` a la même signification sémantique que`autoApproval: true`. Les règles spécifiées dans la liste d'énumération sont appliquées. Le fait de ne pas spécifier (null) signifie qu'une approbation est nécessaire.
**Avant (avant-première publique) :**
```
{
"name": "string",
"description": "string",
"authorizerConfiguration": { ... },
"authorizerType": "string",
"approvalConfiguration": {
"autoApproval": true
}
}
```
**Après (disponibilité générale) : avec approbation ALL**
```
{
"name": "string",
"description": "string",
"discoveryConfiguration": {
"authorizerConfiguration": { ... },
"authorizerType": "string"
},
"approvalConfiguration": {
"autoApprovalRules": ["APPROVE_ALL"]
}
}
```
**Après (disponibilité générale) : avec NULL dans la liste d'énumération**
```
{
"name": "string",
"description": "Registry with manual approval only",
"approvalConfiguration": {
"autoApprovalRules": []
}
}
```
### Modification 2 : Nouveaux champs obligatoires dans les enregistrements du registre
Les enregistrements du registre reçoivent deux nouveaux champs de premier niveau obligatoires pour permettre une meilleure catégorisation et une meilleure déduplication. Vous devez spécifier les deux champs lors de la création d'un enregistrement de registre à l'aide de l'`CreateRegistryRecord`API, et vous pouvez les modifier ultérieurement à l'aide de l'`UpdateRegistryRecord`API.
| Champ | Type | Description |
| --- | --- | --- |
| `name` | Chaîne (obligatoire) | Identifiant unique au sein du registre qui peut être spécifié par le client. Chaque enregistrement doit avoir un nom unique dans le registre. Lorsqu'il `recordVersion` est également présent, la combinaison de `name` et `recordVersion` doit être unique. |
| `recordType` | Enum (obligatoire) | Type sémantique de l'enregistrement. Valeurs valides: `AGENT`, `MCP`, `SKILL`, `CUSTOM`. Détermine sous `descriptors` quelle clé de descripteur principal est valide. Vous pouvez utiliser des API telles que `ListRegistryRecords` et `SearchDiscoverableRegistryRecords` pour filtrer les résultats selon ce type sémantique. |
### Modification 3 : Restructuration des enregistrements du registre
Le `descriptors` champ passe d'une union discriminée à une structure à clé plate.
Dans le modèle précédent, le `descriptorType` champ (`MCP`,, `A2A``AGENT_SKILLS`,`CUSTOM`) déterminait la forme intérieure. Cela associait le contenu du descripteur à un protocole grossier ou à une classification de format. Ce champ n'existe plus. `recordType`, un attribut de premier niveau distinct, le remplace pour la catégorisation sémantique. L'API applique des clés de descripteur valides pour chacun `recordType` au moment de l'exécution plutôt que de manière structurelle dans la forme. Chaque clé de niveau supérieur ci-dessous représente `descriptors` désormais un type de descripteur principal granulaire (par exemple,, `a2aAgentCard``mcpServer`,`agentSkillsDefinition`). `custom` Les descripteurs supplémentaires (par exemple`tools`,`skillMd`) sont imbriqués sous ceux du descripteur principal. `additionalData` Le `inlineContent` champ devient`data`. Les `protocolVersion` champs `schemaVersion` et se consolident dans`dataSchemaVersion`.
L'`synchronizationConfiguration`attribut de niveau supérieur devient `source` et se déplace dans chaque descripteur (y compris `additionalData` les enfants).
Le `name` champ existant le devient`displayName`, ce qui rend sa signification plus explicite. Un nouveau `name` champ net sert de clé de déduplication et doit être unique dans tous les enregistrements d'un registre. Si vous spécifiez les deux `name` et `recordVersion` pour le même enregistrement, leur combinaison doit être unique.
Les champs suivants sont renommés :
| Avant | Après | Remarques |
| --- | --- | --- |
| `name` | `displayName` | Afficher le nom de l'enregistrement. Il y aura également un nouveau `name` champ qui sera la clé de déduplication. |
| `descriptorType` | Supprimé | Remplacé par le `recordType` champ de niveau supérieur. |
| `inlineContent` | `data` | La charge utile du contenu dans chaque descripteur. |
| `schemaVersion` / `protocolVersion` | `dataSchemaVersion` | Champ de version unifié pour tous les types de descripteurs. |
| `synchronizationConfiguration` | `source` | Déplacé dans chaque descripteur (y compris `additionalData` les enfants). |
**Avant (avant-première publique) :**
```
{
"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"
}
]
}
},
...
}
```
**Après (disponibilité générale) :**
```
{
"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
...
}
```
Les contraintes suivantes s’appliquent :
Une seule clé de descripteur principal peut être renseignée par enregistrement. Les descripteurs principaux valides `recordType` sont les suivants :
+ **MANDATAIRE :** `a2aAgentCard``mcpServer`, `custom`
+ **MCP :**`mcpServer`, `custom`
+ **COMPÉTENCE :**`agentSkillsDefinition`, `custom`
+ **PERSONNALISÉ :** `custom`
`source`est un descripteur par descripteur plutôt qu'un seul bloc de haut niveau. Il s'attache aux descripteurs qui contiennent un `source` champ dans le schéma — `mcpServer` et`a2aAgentCard`. L'`tools`enfant (moins de`mcpServer.additionalData`), le `agentSkillsDefinition` parent et le `custom` descripteur portent le numéro`source`.
Chez GA, seul `source.fromUrl` est pris en charge.
Auto-synchronization n'est déclenché que pour `mcpServer` les descripteurs `a2aAgentCard` principaux, c'est-à-dire les types d'enregistrement MCP et AGENT. A `source` sur l'`skillMd`enfant est conservé mais n'est pas utilisé pour exécuter la synchronisation, et les enregistrements SKILL ne peuvent pas être synchronisés automatiquement. Les enregistrements PERSONNALISÉS doivent être créés manuellement en les fournissant `data` directement.
### Modification 4 : mises à jour du filtre du plan de données
`SearchRegistryRecords`devient `SearchDiscoverableRegistryRecords` (`POST /discoverable-records-search`). Sa demande et sa réponse reprennent les nouveaux noms de champs et le nouveau modèle de données :
+ Filtrer par `recordType` (remplace`descriptorType`).
+ Filtrer par `recordVersion` (remplace`version`).
+ La réponse renvoie les descripteurs dans le nouveau format, sans`credentialProviderConfigurations`.
L'outil de recherche MCP `search_registry_records` devient`search_discoverable_registry_records`, renvoie le nouveau format de descripteur et utilise les nouveaux noms de filtres.
### Modification 5 : nouvelles API de navigation
Deux nouvelles API de plan de données permettent de créer des expériences de navigation et de catalogue sur des enregistrements approuvés. Ces API ne nécessitent aucune migration explicite ; nous les mentionnons ici en tant qu'ajouts au modèle d'API du registre des AWS agents de GA.
**ListDiscoverableRegistryRecords**— Renvoie une liste paginée des enregistrements de registre approuvés. Utilisez-le pour créer des interfaces de navigation sur du contenu publié.
```
// 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**— Récupère tous les détails d'un lot d'enregistrements dans un ou plusieurs registres en un seul appel.
```
// 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 réponse inclut un `registryRecords` tableau contenant les détails complets des enregistrements et un `errors` tableau pour tous les enregistrements qui n'ont pas pu être récupérés.
Au lancement, une seule entrée (un registre, 1 à 100 identifiants d'enregistrement) est acceptée. La forme groupée est compatible avec le traitement par lots entre registres dans les versions futures.
### Modification 6 : les API de liste adoptent le paramètre des filtres structurés
Dans l'aperçu public, les API List exposent chaque champ filtrable comme son propre paramètre de requête (par exemple,`--status READY`,`--recordType MCP`). En GA, un seul `filters` paramètre structuré remplace ces paramètres discrets. La `filters` valeur est une liste d'`{ "name": "", "values": [""] }`entrées contenant un chemin `name` d'attribut délimité par des points. Les nouveaux champs filtrables, y compris les champs imbriqués, deviennent de nouveaux `name` chemins plutôt que de nouveaux paramètres d'API. Les opérations de liste passent également de `GET` à`POST`. Les paramètres de pagination (`maxResults`,`nextToken`) restent inchangés.
**Avant (avant-première publique) :**
```
GET /registries?status=READY&authorizerType=AWS_IAM
GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP
```
**Après (disponibilité générale) :**
```
// 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"
}
```
## Migrations des données
Vous devez migrer vos registres et enregistrements de registre existants de l'espace de `bedrock-agentcore` noms vers l'`agent-registry`espace de noms. Nous fournissons un script pour faciliter la migration. Le script gère l'extraction des données existantes, la transformation de l'ancien schéma vers le nouveau schéma et le chargement dans les registres du nouvel espace de noms. Le script crée de nouveaux registres dans l'espace de `agent-registry` noms au sein du même compte et de la même région. Il migre tous les enregistrements existants de vos anciens registres vers les nouveaux, en tenant compte des modifications de l'espace de noms et du schéma d'API.
### Choix de votre approche de migration
La bonne approche dépend de l'ampleur de l'utilisation de votre registre et de votre environnement opérationnel.
#### Cas 1 : Small-scale migration avec exécution directe de scripts
+ **Profil :** Moins de 5 registres et moins de 100 enregistrements. Vous avez un accès direct à un terminal ou CloudShell au compte cible.
+ **Approche :** exécutez directement le script Python de migration. Le script se connecte à l'espace de noms de prévisualisation, répertorie vos registres et enregistrements, transforme les données en schéma GA et les crée dans le nouvel espace de noms. Il s'agit de la solution la plus simple et ne nécessite aucun déploiement d'infrastructure.
#### Cas 2 : Migration gérée avec Lambda ou Glue
+ **Profil :** vous ne disposez pas d'un accès terminal direct à l'environnement cible, ou vous préférez un modèle d'exécution géré.
+ **Approche :** Déployez la migration sous la forme d'une fonction AWS Lambda ou d'une tâche AWS Glue. Le moteur de migration exécute le même flux de travail d'extraction, de transformation et de chargement, mais s'exécute en tant que tâche gérée au sein de votre compte. Pour la plupart des comptes, la migration complète s'effectue en moins de 15 minutes.
Le moteur de migration :
+ **Extrait** les registres et les enregistrements de l'espace de noms de prévisualisation, en prenant en charge les chargements complets et incrémentiels. Il pagine toutes les réponses de l'API et sérialise les données vers un emplacement intermédiaire.
+ **Transforme** chaque enregistrement en appliquant les modifications du schéma de l'API (renommage des champs, restructuration des descripteurs, nouveaux champs obligatoires).
+ **Charge** les données transformées dans le nouvel espace de `agent-registry` noms, en créant des registres et des enregistrements à l'aide de l'API GA.
+ **Génère un rapport** résumant ce qui a été migré, les éventuelles erreurs rencontrées et le nombre d'enregistrements à vérifier.
#### Cas 3 : Dual-write migration pour les charges de travail de production actives
+ **Profil :** vous avez créé une plateforme ou un pipeline d'automatisation sur la base des API de préversion publiques et vous rédigez activement de nouvelles données en production.
+ **Approche :** utilisez une stratégie de migration à double écriture pour éviter les pertes de données pendant la transition :
+ **Mettez à jour votre rédacteur** : modifiez votre application pour écrire simultanément dans l'espace de noms d'aperçu et dans le nouvel espace de `agent-registry` noms.
+ **Exécuter le script de migration avec déduplication** : exécutez les outils de migration pour migrer les données historiques. Le script se déduplique en fonction du `name` champ, de sorte que les enregistrements qui existent déjà dans le nouvel espace de noms (issus de votre double écriture) ne sont pas dupliqués.
+ **Changez de lecteur** : après avoir vérifié que toutes les données existent dans le nouvel espace de noms, mettez à jour votre application pour qu'elle puisse les lire exclusivement depuis`agent-registry`.
+ **Supprimer la double écriture** : après avoir vérifié que toutes les lectures et écritures sont réussies sur le nouvel espace de noms, supprimez le rédacteur d'espace de noms d'aperçu de votre application.
### Vérification de votre migration
Après avoir effectué la migration, vérifiez que vos données ont été correctement migrées :
+ Répertoriez tous les registres du nouvel espace de noms à l'aide de la commande `list-registries` CLI et vérifiez que le nombre correspond à votre source.
+ Pour chaque registre, comparez le nombre d'enregistrements à l'aide de`list-registry-records`.
+ Spot-check enregistrements individuels pour confirmer que les descripteurs ont été correctement transformés (renommage des champs, restructuration des descripteurs).
+ Mettez à jour vos politiques IAM, vos points de terminaison et vos clients SDK comme décrit dans la section Espace de noms et modifications de configuration.
+ Vérifiez que vos applications peuvent lire et écrire correctement en utilisant le nouvel espace de noms.
## FAQ
### Qu'est-ce qui change dans AWS Registre des agents ?
AWS Le registre des agents passe de l'espace de `bedrock-agentcore` noms de prévisualisation public à l'espace de `agent-registry` noms généralement disponible. La migration couvre trois domaines : les modifications de l'espace de noms et de la configuration (points de terminaison, IAM, SDK, CLI, ARN, observabilité), les modifications du schéma d'API (modèle de données restructuré pour les registres et les enregistrements) et la migration des données (déplacement de vos registres et enregistrements existants vers le nouvel espace de noms).
### Puis-je continuer à utiliser Registry sur l'espace de noms `bedrock-agentcore ?`
Votre utilisation actuelle du registre sur l'espace de `bedrock-agentcore` noms continue de fonctionner sans interruption pendant la fenêtre de migration. Toutefois, nous vous recommandons de commencer votre migration dès que les outils seront disponibles afin de disposer de suffisamment de temps pour effectuer à la fois la migration des données et les mises à jour du code.
Toutefois, si vous ne disposez pas de registres ou d'enregistrements existants au 6 août 2026, vous ne pourrez pas accéder à l'espace de `bedrock-agentcore` noms du registre des AWS agents à partir du 6 août 2026. Si vous avez des registres ou des enregistrements existants au 6 août 2026, vous avez accès à l'`bedrock-agentcore`espace de noms du registre des AWS agents pendant la période de migration (du 6 août 2026 au 17 septembre 2026).
### Mes données seront-elles automatiquement migrées ?
Non Vous devez lancer vous-même la migration à l'aide des outils de migration que nous fournissons. Consultez la section Migration des données pour plus de détails sur les approches disponibles en fonction de votre échelle.
### Quelles sont les modifications du schéma d'API incluses ?
Outre le changement d'espace de noms, nous avons mis à jour le modèle de données de l'API dans six domaines : entité de registre (configuration d'autorisation groupée ci-dessous`discoveryConfiguration`), nouveaux champs d'enregistrement du registre (`name`et`recordType`), restructuration des enregistrements de registre (descripteurs aplatis, renommage des champs), mises à jour des filtres d'API de recherche (`recordType`,`recordVersion`), nouvelles API de navigation (`ListDiscoverableRegistryRecords`,) et filtres structurés pour les opérations de liste. `BatchGetDiscoverableRegistryRecord`
### Combien de temps prendra la migration des données ?
Le délai de migration dépend du nombre de registres et d'enregistrements de votre compte. Pour les comptes contenant moins de 100 enregistrements, la migration s'effectue en quelques minutes lorsqu'elle est exécutée localement. Pour les comptes contenant des milliers d'enregistrements, attendez-vous à ce que la migration soit terminée en moins de 15 minutes s'il s'agit d'une tâche gérée.
### Et si j'ai un déploiement à grande échelle avec des écritures actives ?
Si vous écrivez activement des données dans l'espace de noms de prévisualisation en production, utilisez la stratégie de migration à double écriture décrite dans le cas 3. Cette approche garantit qu'aucune donnée n'est perdue pendant la transition en écrivant simultanément dans les deux espaces de noms, en migrant les données historiques avec déduplication, puis en réduisant le nombre de lectures.
### Où puis-je obtenir de l'aide ?
Pour toute question ou assistance concernant votre migration, contactez le [AWS Support](https://aws.amazon.com/support).