AWS sluit op 30 oktober 2026 de oude bedrock-agentcore-namespace van AWS Agent Registry. Bestaande registries en records worden niet automatisch overgezet: je moet de migratie zelf starten. Data die na de sluiting in de oude namespace staat, gaat verloren en lezen en schrijven daar is dan niet meer mogelijk. AWS beschrijft de migratie, de drie aanpakken en de technische wijzigingen.

De migratie betreft AWS Agent Registry, niet alle onderdelen van Amazon Bedrock AgentCore. Identity, Gateway, Runtime en Policy vallen buiten deze namespacewijziging. Ook blijven workload identity- en OAuth credential-provider-resources de namespace bedrock-agentcore gebruiken.

Kies een migratieaanpak

AWS biedt drie routes. De juiste keuze hangt vooral af van de vraag of je een eenmalige overzetting uitvoert, een beheerde laadtaak nodig hebt of tijdens de overgang records blijft wijzigen.

AanpakGeschikt voorLaden en omschakelen
Eenmalige migratie via terminal of AWS CloudShellEen volledige migratie die je zelf uitvoertDe migratietool haalt de gegevens op, zet ze om en laadt ze in nieuwe registries. Je hoeft hiervoor geen infrastructuur uit te rollen.
Beheerde migratie met AWS GlueOnbeheerde uitvoering of een aanvullende laadronde bij de omschakelingAWS beschrijft Glue-jobs voor een eerste volledige migratie en een incrementele lading bij de cutover.
Active-activeProductieregistries die tijdens de overgang nieuwe schrijfacties blijven ontvangenVoer eerst de volledige migratie uit, schrijf daarna naar beide namespaces, controleer de gegevens en schakel vervolgens lezen en schrijven over naar agent-registry.

De tool laadt de gemigreerde registries en records in hetzelfde AWS-account en dezelfde regio. De gegevensverplaatsing is dus één deel van het werk; applicaties en operationele integraties moeten ook met de nieuwe namespace overweg kunnen.

Werk code, IAM en integraties bij

Plan de wijzigingen naast de dataoverzetting. Alleen de naam van de namespace of de IAM-actieprefix aanpassen is niet genoeg: AWS meldt ook wijzigingen aan endpoints, clients, API-schema’s en observability-integraties.

De data-plane-endpoint verandert van bedrock-agentcore.{region}.amazonaws.com naar agent-registry.{region}.api.aws. Voor het control plane wordt bedrock-agentcore-control.{region}.amazonaws.com vervangen door agent-registry-control.{region}.api.aws. Ook de SDK-clients veranderen van BedrockAgentCoreClient en BedrockAgentCoreControlClient naar AgentRegistryClient en AgentRegistryControlClient. Voor de CLI wordt aws bedrock-agentcore vervangen door aws agent-registry.

Werk ook IAM-acties, service principals en ARN’s voor Registry en records bij. BedrockAgentCoreFullAccess krijgt niet automatisch rechten op agent-registry:*; AWS noemt AgentRegistryFullAccess voor toegang tot Registry. Vervang echter niet zonder onderscheid elke oude permissie: workload identity en OAuth credential-provider-resources blijven onder bedrock-agentcore vallen.

De API-schema’s zijn achterwaarts incompatibel. Code die Registry-verzoeken opbouwt of antwoorden verwerkt, moet dus worden aangepast. De nieuwe schema’s vereisen onder meer de velden name en recordType; inlineContent wordt data, en schemaVersion en protocolVersion worden samengebracht in dataSchemaVersion. Ook verhuist de synchronisatiebron source naar de descriptors. Pas daarnaast CloudWatch-verwijzingen aan van AWS/BedrockAgentCore naar AWS/AgentRegistry en controleer EventBridge-regels die de bron aws.bedrock-agentcore of gewijzigde detailtypen gebruiken. De events blijven op de standaard event bus.

Controleer IAM-trust vóór live laden

Deze extra voorwaarde geldt voor records die met gegevens van een IAM-rol worden gesynchroniseerd. Vóór het live laden moet de trust policy van die rol agent-registry.amazonaws.com vertrouwen. AWS waarschuwt dat de migratietool deze afhankelijkheid niet detecteert. De specifieke voorwaarde geldt niet voor records met OAuth-verificatie of zonder autorisatie.

Als een gemigreerd record de status CREATE_FAILED krijgt, beschrijft AWS deze herstelvolgorde: pas de trust policy aan, verwijder het mislukte record in de nieuwe Registry en voer de laadactie opnieuw uit.

Controleer de migratie vóór de sluiting

Vergelijk na het laden het aantal registries en het aantal records per registry. Controleer getransformeerde records steekproefsgewijs, werk de koppelingen en bewakingsregels bij en test lezen én schrijven in de nieuwe namespace. Zo controleer je zowel de overgezette gegevens als de onderdelen van je applicatie die na de omschakeling Registry gebruiken.