AWS schaltet den alten Namespace von AWS Agent Registry am 30. Oktober 2026 ab. Bestehende Daten werden nicht automatisch migriert: AWS beendet dann den Lese- und Schreibzugriff, und Daten, die noch im alten Namespace liegen, gehen verloren. Teams müssen den Umzug selbst anstoßen und neben den Datensätzen auch Anwendungen und Integrationen anpassen (AWS-Migrationsleitfaden).

Der Wechsel betrifft AWS Agent Registry, nicht sämtliche Angebote von Amazon Bedrock AgentCore. Identity, Gateway, Runtime und Policy sind laut AWS davon nicht betroffen. Auch Berechtigungen für Workload Identity und OAuth-Anbieter für Zugangsdaten bleiben teilweise im Namespace bedrock-agentcore.

Welche Migrationsmethode passt zu Ihrer Registry?

AWS beschreibt drei Wege. Die Wahl hängt vor allem davon ab, ob Sie einmalig migrieren, den Vorgang automatisieren oder währenddessen weiter in die Registry schreiben müssen.

AnsatzGeeignet fürLade- und Umschaltmuster
Lokale Migration oder AWS CloudShellEine einmalige vollständige MigrationDas Migrationstool wird lokal oder in CloudShell ausgeführt und überträgt die Registry-Daten in einem Durchlauf.
Verwaltete AWS-Glue-JobsUnbeaufsichtigte Abläufe oder eine spätere inkrementelle LadungEin bereitgestellter CDK-Stack richtet Glue-Jobs ein. Nach der ersten vollständigen Migration kann zum Umschaltzeitpunkt eine inkrementelle Ladung folgen.
Active-ActiveProduktions-Registries, in die fortlaufend geschrieben wirdNach der vollständigen Migration schreiben Anwendungen in beide Namespaces. Nach der Prüfung wechseln Lese- und Schreibzugriffe auf agent-registry.

Das Migrationstool extrahiert die vorhandenen Registries und Datensätze, wandelt sie in das neue Schema um und lädt sie in neu angelegte Registries im selben AWS-Konto und derselben Region. AWS migriert die Daten also nicht im Hintergrund; das Team muss den Lauf planen und den Zielbestand prüfen.

So planen Sie den Umzug

  1. Wählen Sie den Migrationsweg. Nutzen Sie die lokale Ausführung oder CloudShell für einen einmaligen vollständigen Lauf. AWS Glue eignet sich für unbeaufsichtigte Abläufe und eine inkrementelle Ladung zum Umschaltzeitpunkt. Bei laufenden Schreibzugriffen beschreibt AWS Active-Active mit parallelen Schreibvorgängen vor dem Wechsel.
  2. Prüfen Sie IAM-synchronisierte Datensätze vor dem Live-Laden. Verwenden Datensätze Zugangsdaten einer IAM-Rolle, muss deren Vertrauensrichtlinie agent-registry.amazonaws.com vertrauen. AWS zufolge erkennt das Migrationstool diese Abhängigkeit nicht. Für OAuth-authentifizierte oder nicht authentifizierte Datensätze gilt diese spezielle Voraussetzung nicht.
  3. Führen Sie die Migration aus. Das Tool extrahiert, transformiert und lädt Registries und Datensätze in die neuen Ziel-Registries. Bei fortlaufend beschriebenen Registries richtet sich der Zeitpunkt der Umschaltung nach dem gewählten Verfahren.
  4. Passen Sie Anwendungen und Betriebsintegrationen an. Der neue Namespace ändert mehr als den Namen: Aktualisieren Sie die betroffenen API-Aufrufe, Zugriffsrechte, Clients und Überwachung sowie Ereignisregeln.
  5. Prüfen Sie den neuen Bestand vor dem Stichtag. Vergleichen Sie die Anzahl der Registries und die Datensatzanzahl je Registry, prüfen Sie stichprobenartig umgewandelte Datensätze und testen Sie Lese- und Schreibzugriffe im neuen Namespace. Bei Active-Active erfolgt der Wechsel laut AWS nach der Validierung.

Was sich in Code, IAM und Integrationen ändert

Die API-Schemata sind nicht abwärtskompatibel. Anwendungen, die Registry-Anfragen oder -Antworten erstellen oder auswerten, müssen angepasst werden. Zu den Änderungen gehören die erforderlichen Felder name und recordType, eine neu strukturierte Beschreibung der Datensätze sowie der Wechsel von inlineContent zu data. schemaVersion und protocolVersion werden durch dataSchemaVersion ersetzt; bei synchronisierten Datensätzen wandert source in die Beschreibungsfelder.

Prüfen Sie außerdem die konkreten Integrationspunkte:

  • Endpunkte: Der Datenebenen-Endpunkt wechselt von bedrock-agentcore.{region}.amazonaws.com zu agent-registry.{region}.api.aws. Für die Steuerungsebene wird aus bedrock-agentcore-control.{region}.amazonaws.com der Endpunkt agent-registry-control.{region}.api.aws.
  • IAM und Service-Prinzipal: Aktionsnamen wechseln von bedrock-agentcore:* zu agent-registry:*; der Registry-Service-Prinzipal von bedrock-agentcore.amazonaws.com zu agent-registry.amazonaws.com. Auch Registry- und Datensatz-ARNs ändern sich.
  • Zugriffsrichtlinien: BedrockAgentCoreFullAccess erhält nicht automatisch die Berechtigungen agent-registry:*. AWS nennt AgentRegistryFullAccess als Richtlinie für den Zugriff auf die Registry. Entfernen Sie jedoch nicht pauschal alle Berechtigungen mit dem alten Präfix: Workload Identity und OAuth-Anbieter für Zugangsdaten verwenden es weiterhin teilweise.
  • SDK und CLI: Die SDK-Clients heißen künftig AgentRegistryClient und AgentRegistryControlClient statt BedrockAgentCoreClient und BedrockAgentCoreControlClient. In der CLI wird aus aws bedrock-agentcore der Aufrufbereich aws agent-registry.
  • Überwachung und Ereignisse: Der CloudWatch-Namespace wechselt von AWS/BedrockAgentCore zu AWS/AgentRegistry. EventBridge-Ereignisse verwenden die Quelle aws.agent-registry statt aws.bedrock-agentcore; Regeln, die die alte Quelle oder geänderte Detailtypen abgleichen, müssen angepasst werden.

IAM-Fehler bei einem migrierten Datensatz beheben

Landet ein IAM-synchronisierter Datensatz nach dem Laden im Status CREATE_FAILED, aktualisieren Sie die Vertrauensrichtlinie der Rolle so, dass sie agent-registry.amazonaws.com vertraut. Löschen Sie anschließend den fehlgeschlagenen Datensatz in der neuen Registry und führen Sie den Ladevorgang erneut aus. Die Vertrauensrichtlinie muss bereits vor dem Live-Laden passen, damit dieser Fehler gar nicht erst auftritt.

Für den Abschluss empfiehlt AWS, Registry- und Datensatzanzahlen abzugleichen, umgewandelte Datensätze stichprobenartig zu kontrollieren, Integrationen zu aktualisieren und Lese- sowie Schreibzugriffe in agent-registry zu testen. Am 30. Oktober 2026 endet der Zugriff auf den alten Namespace; dort verbliebene Daten gehen verloren.