Guide complet de migration de registres

AWS Registre des agents — Migration vers le nouvel espace de noms agent-registry

Introduction

Dans le cadre du lancement du nouvel agent-registry espace de noms le 6 août 2026, AWS Agent Registry introduit des modifications importantes au principal de service, aux données et au modèle d'API. Si vous avez utilisé le registre des AWS agents sous l'bedrock-agentcoreespace de noms, vous devez effectuer une migration qui couvre trois domaines :

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 ?

Vous devez garder à l'esprit deux étapes importantes lors de cette migration :

Changements d'espace de noms et de configuration

L'agent-registryespace de noms bedrock-agentcore se remplace aux endroits suivants. Cette section répertorie toutes les surfaces qui changent et fournit des exemples de mise à jour de votre code.

Points de terminaison de service

Vos applications doivent pointer vers les nouveaux noms d'hôte des terminaux. Les nouveaux points de terminaison utilisent le .api.aws domaine.

IAM et sécurité

Toutes les politiques IAM, les politiques de contrôle des services (SCP) et les limites d'autorisation qui font référence bedrock-agentcore doivent être mises à jour. Les ARN des ressources changent également pour refléter le nouvel espace de noms.

Si vous disposez d'une automatisation qui analyse les ARN ou les stocke, mettez également à jour ces références. Les politiques personnalisées dont les conditions concernent le préfixe d'action IAM ou le 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, consultez la référence des autorisations IAM du registre des AWS agents.

SDK, interface de ligne de commande 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 CLI.

Si vous avez déjà demandé des augmentations de quota personnalisées sous le code bedrock-agentcore de service, vous devez les demander à nouveau sousagent-registry.

Observabilité et organisation d'événements

Mettez à jour toutes 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.

EventBridge notifications

Dans l'bedrock-agentcoreespace de noms, le registre des AWS agents a émis deux EventBridge événements Amazon sous la source de l'aws.bedrock-agentcoreévénement. La source de l'événement passe désormais àaws.agent-registry, les ARN des ressources adoptent le nouvel espace de noms et la couverture des notifications s'étend à l'ensemble de l'enregistrement et au cycle de vie du registre. Les événements continuent d'être transférés vers le EventBridge bus par défaut dans le propre compte de la ressource. Vous devez mettre à jour toutes EventBridge les règles qui correspondent à l'ancienne source ou aux anciennes chaînes de type de détail.

Registry-record événements. Émis lorsqu'un enregistrement de registre passe d'un état de flux de travail d'approbation à un autre. Resourcesest l'ARN de l'enregistrement complet ; detail contient registryRecordId etregistryId.

Événements du registre. Émis lors du provisionnement du registre et des transitions de cycle de vie. Resourcesest l'ARN complet du registre ; detail contient registryId etregistryName.

Exemple d'événement (enregistrement de registre).

Avant (espace de bedrock-agentcore noms, à déprécier) :

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

Après (agent-registryespace de noms) :

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

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 (espace de bedrock-agentcore noms, à déprécier) :

{
  "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 (agent-registryespace de noms) :

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

Exemple : mise à jour de la configuration du client du SDK

Mettez à jour le nom du service, la classe de client et l'URL du point de terminaison dans vos appels au SDK.

Avant (espace de bedrock-agentcore noms, à déprécier) :

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 (agent-registryespace de noms) :

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

Avant (espace de bedrock-agentcore noms, à déprécier) :

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 (agent-registryespace de noms) :

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 d'API

Outre la migration de l'espace de noms, nous avons mis à jour le registre et les modèles de données d'enregistrement de registre dans l'espace de agent-registry noms. Ces modifications améliorent la cohérence et l'extensibilité de l'API en fonction des commentaires provenant de l'espace de bedrock-agentcore noms. 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 la manière dont le plan de données d'un registre est accessible, se trouve désormais dans un discoveryConfiguration wrapper dédié qui rend son objectif explicite. La configuration d'approbation (qui contrôle si les enregistrements soumis au PENDING_APPROVAL statut passent automatiquement à l'APPROVEDétat) passe d'un tableau booléen à un tableau d'énumération extensible.

Les modifications spécifiques apportées aux champs sont les suivantes :

Avant (espace de bedrock-agentcore noms, à déprécier) :

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

Après (espace de agent-registry noms) : avec Approval ALL

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

Après (agent-registryespace de noms) : 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 de registre obtiennent 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'CreateRegistryRecordAPI, et vous pouvez les modifier ultérieurement à l'aide de l'UpdateRegistryRecordAPI.

Modification 3 : Restructuration des dossiers 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, A2AAGENT_SKILLS,CUSTOM) déterminait la forme intérieure. Cela a couplé le contenu du descripteur à un protocole grossier ou à une classification de format. Ce champ n'existe plus. recordType, un attribut de niveau supérieur distinct, le remplace pour la catégorisation sémantique. L'API applique des clés de description 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,, a2aAgentCardmcpServer,agentSkillsDefinition). custom Les descripteurs supplémentaires (par exemple,tools,skillMd) sont imbriqués sous le descripteur principal. additionalData Le inlineContent terrain devientdata. Les protocolVersion champs schemaVersion et se regroupent dansdataSchemaVersion.

L'synchronizationConfigurationattribut de niveau supérieur devient source et se déplace à l'intérieur de chaque descripteur (y compris additionalData les enfants).

Le name champ existant devientdisplayName, ce qui rend sa signification plus explicite. Un nouveau name champ sert de clé de déduplication et doit être unique pour 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 (espace de bedrock-agentcore noms, à déprécier) :

{
  "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 (agent-registryespace de noms) :

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

Les contraintes suivantes s’appliquent :

Exactement une clé de description primaire peut être renseignée par enregistrement. Les descripteurs principaux valides recordType sont les suivants :

sourceest défini par descripteur plutôt que comme un seul bloc de niveau supérieur. Il s'attache aux descripteurs qui contiennent un source champ dans le schéma — mcpServer eta2aAgentCard. L'toolsenfant (en dessous demcpServer.additionalData), le agentSkillsDefinition parent et le custom descripteur portent nonsource.

Dans l'espace de agent-registry noms, seul source.fromUrl est pris en charge.

Auto-synchronization est uniquement déclenchée pour les descripteurs mcpServer et a2aAgentCard principaux, c'est-à-dire les types d'enregistrement MCP et AGENT. Un source sur l'skillMdenfant 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 CUSTOM doivent être créés manuellement en fournissant data directement.

Modification 4 : mises à jour du filtre du plan de données

SearchRegistryRecordsdevient SearchDiscoverableRegistryRecords (POST /discoverable-records-search). Sa requête et sa réponse récupèrent les nouveaux noms de champs et le nouveau modèle de données :

L'outil de recherche MCP search_registry_records devientsearch_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 catalogage par rapport à 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 AWS Agent Registry dans l'agent-registryespace de noms.

ListDiscoverableRegistryRecords— Renvoie une liste paginée des enregistrements de registre approuvés. Utilisez-le pour créer des interfaces de navigation sur le 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 de l'enregistrement et un errors tableau pour tous les enregistrements qui n'ont pas pu être récupérés.

Au lancement, exactement une entrée (un registre, 1 à 100 identifiants d'enregistrement) est acceptée. La forme groupée est rétrocompatible avec le traitement par lots entre registres dans les prochaines versions.

Modification 6 : les API de liste adoptent le paramètre de filtres structurés

Dans l'bedrock-agentcoreespace de noms, les API List exposent chaque champ filtrable comme son propre paramètre de requête (par exemple--status READY,--recordType MCP). Dans l'agent-registryespace de noms, un seul filters paramètre structuré remplace ces paramètres discrets. La filters valeur est une liste d'{ "name": "<dotted.path>", "values": ["<value>"] }entrées contenant un chemin name d'attribut délimité par des points. Les nouveaux champs filtrables, y compris ceux 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) sont inchangés.

Avant (espace de bedrock-agentcore noms, à déprécier) :

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

Après (agent-registryespace de noms) :

// 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-registryespace de noms. Nous fournissons un outil de migration pour faciliter la migration. L'outil 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. L'outil crée de nouveaux registres dans l'agent-registryespace de noms 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.

L'outil de migration est disponible dans le référentiel agentcore-samples du site Web. GitHub Pour obtenir des instructions de configuration complètes, des références de commandes et des conseils opérationnels, consultez le README du référentiel.

Choisir votre approche de migration

La bonne approche dépend de la question de savoir si une migration complète unique est suffisante ou si vous avez besoin d'une exécution sans assistance et de la possibilité d'exécuter une charge incrémentielle au moment du basculement.

Cas 1 : migration simple

Cas 2 : migration gérée avec AWS Glue

Cas 3 : Active-active migration

Vérification de votre migration

Après avoir effectué la migration, vérifiez que vos données ont été correctement migrées :

Mettre à jour les politiques de confiance IAM pour les enregistrements synchronisés

Si l'un de vos enregistrements de registre utilise Synchroniser avec le type d'identification du rôle IAM, vous devez mettre à jour la politique de confiance du rôle avant d'exécuter le chargement en temps réel. Le principal de service qui assume le rôle est passé de bedrock-agentcore.amazonaws.com à agent-registry.amazonaws.com dans le nouvel espace de noms. Les enregistrements qui utilisent des informations d'identification OAuth ou qui ne sont pas autorisés ne sont pas affectés.

Mettez à jour la politique de confiance sur le rôle référencé par chaque enregistrement concerné.

Avant (espace de bedrock-agentcore noms, à déprécier) :

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

Après (agent-registryespace de noms) :

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

Si un enregistrement a déjà échoué pour cette raison, le CREATE_FAILED statut de l'enregistrement migré existe. L'outil de migration refuse de remplacer un enregistrement en état d'échec. Par conséquent, la correction de la politique de confiance ne suffit pas à résoudre le problème. Pour récupérer :

FAQ

Qu'est-ce qui change dans AWS Registre des agents ?

AWS Le registre des agents passe de l'bedrock-agentcoreespace de noms au nouvel espace de agent-registry noms dédié. La migration couvre trois domaines : les changements d'espace de noms et de 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'bedrock-agentcoreespace de noms continue de fonctionner sans interruption pendant la fenêtre de migration. Nous vous recommandons toutefois de commencer votre migration dès que les outils seront disponibles afin de disposer de suffisamment de temps pour terminer la migration des données et les mises à jour du code.

Toutefois, si vous n'avez pas de registres ou d'enregistrements existants au 6 août 2026, vous ne pourrez pas accéder à l'bedrock-agentcoreespace de noms du registre des AWS agents à partir du 6 août 2026. Si vous disposez de registres ou d'enregistrements existants au 6 août 2026, vous avez accès à l'bedrock-agentcoreespace 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 la migration vous-même à l'aide des outils de migration que nous mettons à votre disposition. Consultez la section Migration des données pour plus de détails sur les approches disponibles en fonction de votre échelle.

Quelles modifications du schéma d'API sont 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 regroupée sousdiscoveryConfiguration), nouveaux champs d'enregistrement de registre (nameetrecordType), restructuration de l'enregistrement de registre (descripteurs aplatis, renommages de 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 durera la migration des données ?

La durée de la 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 lorsqu'elle est exécutée en tant que 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'bedrock-agentcoreespace de noms en production, utilisez l'approche de migration active-active décrite dans le cas 3. Commencez par une migration complète pour mettre l'agent-registryespace de noms à jour, puis écrivez simultanément dans les deux espaces de noms pour valider vos intégrations et renforcer la confiance dans le nouvel espace de noms. Réduisez les lectures et les écritures au agent-registry moment où vous êtes prêt.

Où puis-je obtenir de l'aide ?

Pour toute question ou assistance concernant votre migration, contactez le AWS support.