Einführung Wie sieht der Zeitplan für die Migration aus?Namespace- und Konfigurationsänderungen Änderungen am API-Schema Datenmigrationen Häufig gestellte Fragen

Umfassender Leitfaden zur Migration von Registry

AWS Agentenregistrierung — Migration von der öffentlichen Vorversion zur allgemeinen Verfügbarkeit

Einführung

Im Rahmen der Markteinführung als allgemein verfügbar (GA) am 6. August 2026 führt AWS Agent Registry wichtige Änderungen am Service Principal, am Daten- und API-Modell ein. Wenn Sie AWS Agent Registry während der öffentlichen Vorversion verwendet haben, müssen Sie eine Migration abschließen, die drei Bereiche umfasst:

Namespace- und Konfigurationsänderungen — Wir verschieben AWS Agent Registry vom AWS AgentCore Bedrock-Namespace in einen eigenen dedizierten Namespace. Diese Änderung des Namespaces gilt nur für Agent Registry. AWS Alle anderen AgentCore Angebote — wie Identity, Gateway, Runtime und Policy — bleiben davon unberührt. Für AWS Agent Registry ändert sich der Dienst-Namespace von zu. bedrock-agentcore agent-registry Dies wirkt sich auf jede Oberfläche aus, die auf den Service verweist: Endpunkte, IAM-Richtlinien, SDK-Clients, CLI-Befehle, Ressourcen-ARNs und Observability-Integrationen. Sie müssen Ihren Code und Ihre Infrastruktur aktualisieren, um den neuen Namespace verwenden zu können.
Änderungen am API-Schema — Die Datenmodelle für die Registrierung und die Registrierungsdatensätze werden auf der Grundlage von Kundenfeedback während der öffentlichen Vorschau aktualisiert. Diese Änderungen beeinträchtigen die Abwärtskompatibilität mit den vorhandenen API-Schemas. Ihr Anwendungscode, der API-Anfragen und -Antworten erstellt oder analysiert, muss im Rahmen der Migration zum neuen Namespace aktualisiert werden, um das neue Schema widerzuspiegeln.
Datenmigration — Sie müssen Ihre vorhandenen Registrierungen und Registrierungseinträge vom alten in den neuen Namespace migrieren. Wir bieten Migrationstools, mit denen Sie Ihre Daten extrahieren, in das neue Schema umwandeln und in den neuen Namespace laden können. Die Daten werden in dasselbe Konto und dieselbe Region migriert — nur der Namespace ändert sich.

Dieser Leitfaden behandelt jeden Bereich ausführlich mit Vorher-Nachher-Beispielen, die Ihnen bei der Planung und Durchführung Ihrer Migration helfen sollen.

Wie sieht der Zeitplan für die Migration aus?

Es gibt zwei wichtige Meilensteine, an die Sie sich bei dieser Migration erinnern müssen:

6. August 2026 — Die AWS Agentenregistrierung wird allgemein verfügbar und der neue agent-registry Namespace wird offiziell gestartet. Wenn Sie über bestehende Registrierungen und Datensätze verfügen, haben Sie gleichzeitigen Zugriff auf die bedrock-agentcore Namespaces und. agent-registry Die Migrationstools werden im Agentcore-Samples-Repository verfügbar. GitHub Sie können mit dem Migrationsprozess beginnen.

Anmerkung
Wenn Sie ein neuer Kunde ohne bestehende Registrierungen oder Datensätze sind (Stand: 6. August 2026), können Sie nicht über den Namespace auf die AWS bedrock-agentcore Agentenregistrierung zugreifen. Beginnen Sie, AWS Agent Registry direkt vom Namespace aus zu verwenden. agent-registry
17. September 2026 — Das Migrationsfenster wird geschlossen. Der alte bedrock-agentcore Namespace wird an diesem Tag geschlossen. Sie verlieren den read/write Zugriff auf den Dienst und alle verbleibenden Daten im alten Namespace. Nach diesem Datum müssen Sie den agent-registry Namespace verwenden.

Namespace- und Konfigurationsänderungen

Der agent-registry Namespace ersetzt an bedrock-agentcore den folgenden Stellen. Dieser Abschnitt listet alle Oberflächen auf, die sich ändern, und enthält Beispiele dafür, wie Sie Ihren Code aktualisieren können.

Wichtig

Die Namespace-Änderungen wirken sich nur auf APIs aus, die von AWS Agent Registry angeboten werden, nicht jedoch auf den Rest von AWS Bedrock AgentCore, wie AWS AgentCore Identity. Somit verbleiben die Ressourcen der Workload-Identität und des OAuth-Anmeldeinformationsanbieters im Namespace. bedrock-agentcore

Service-Endpunkte

Ihre Anwendungen müssen auf die neuen Endpunkt-Hostnamen verweisen. Die neuen Endpunkte verwenden die .api.aws Domain.

Surface	Alter Wert	Neuer Wert
Endpunkt der Datenebene	`bedrock-agentcore.{region}.amazonaws.com`	`agent-registry.{region}.api.aws`
Endpunkt der Steuerungsebene	`bedrock-agentcore-control.{region}.amazonaws.com`	`agent-registry-control.{region}.api.aws`

IAM und Sicherheit

Alle IAM-Richtlinien, Service Control Policies (SCPs) und Berechtigungsgrenzen, auf die verwiesen wird, bedrock-agentcore müssen aktualisiert werden. Ressourcen-ARNs ändern sich ebenfalls, um den neuen Namespace widerzuspiegeln.

Surface	Alter Wert	Neuer Wert
IAM-Aktionspräfix	`bedrock-agentcore:*`	`agent-registry:*`
Dienstauftraggeber	`bedrock-agentcore.amazonaws.com`	`agent-registry.amazonaws.com`
Registrierungs-ARN	`arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}`	`arn:aws:agent-registry:{region}:{account}:registry/{id}`
ARN aufzeichnen	`arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}`	`arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}`

Wenn Sie über eine Automatisierung verfügen, die ARNs analysiert oder speichert, aktualisieren Sie auch diese Referenzen. Benutzerdefinierte Richtlinien mit Bedingungen für das IAM-Aktionspräfix oder den Dienstprinzipal müssen aktualisiert werden, damit sie den neuen Werten entsprechen. Eine vollständige Liste der mit der AWS Agentenregistrierung verknüpften IAM-Berechtigungen finden Sie in der Referenz zu den IAM-Berechtigungen der AWS Agentenregistrierung.

Anmerkung

Wenn Sie derzeit die BedrockAgentCoreFullAccess AWS verwaltete Richtlinie für den Zugriff auf die AWS Agentenregistrierung verwenden (siehe BedrockAgentCoreFullAccess Richtliniendetails), müssen Sie sie durch die neue AgentRegistryFullAccessverwaltete Richtlinie (erhältlich bei GA) ersetzen. Die alte BedrockAgentCoreFullAccess verwaltete Richtlinie wird NICHT aktualisiert, sodass sie auch agent-registry:* Berechtigungen enthält.

SDK, CLI und Infrastruktur

Aktualisieren Sie Ihren Anwendungscode, Ihre Bereitstellungsskripts und Infrastructure-as-Code-Vorlagen, sodass sie auf die neue Clientklasse und den neuen CLI-Namespace verweisen.

Surface	Alter Wert	Neuer Wert
Dataplane SDK-Clientklasse	`BedrockAgentCoreClient`	`AgentRegistryClient`
Controlplane SDK-Clientklasse	`BedrockAgentCoreControlClient`	`AgentRegistryControlClient`
CLI-Namespace	`aws bedrock-agentcore`	`aws agent-registry`
Code Service Quotas	`bedrock-agentcore`	`agent-registry`

Wenn Sie zuvor benutzerdefinierte Kontingenterhöhungen im Rahmen des bedrock-agentcore Servicecodes beantragt haben, müssen Sie diese erneut unter agent-registry beantragen.

Beobachtbarkeit und Eventing

Aktualisieren Sie alle CloudTrail Lake-Abfragen, Athena-Abfragen, SIEM-Integrationen, EventBridge Regeln, CloudWatch Dashboards und Alarme, die auf den alten Namespace verweisen.

Surface	Alter Wert	Neuer Wert
CloudTrail Quelle des Ereignisses	`bedrock-agentcore.amazonaws.com`	`agent-registry.amazonaws.com`
EventBridge Quelle	`aws.bedrock-agentcore`	`aws.agent-registry`
CloudWatch Namespace	`AWS/BedrockAgentCore`	`AWS/AgentRegistry`

Beispiel: Aktualisierung der IAM-Richtlinien

Ersetzen Sie das Aktionspräfix und den Ressourcen-ARN-Namespace in all Ihren IAM-Richtlinien.

Vorher (öffentliche Vorschau):


{
  "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:*"]
  }]
}

Nachher (allgemeine Verfügbarkeit):


{
  "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:*"]
  }]
}

Anmerkung

Die BatchGetDiscoverableRegistryRecord API hat keine eigene IAM-Aktion. Sie autorisiert jeden angeforderten Datensatz für die agent-registry:GetDiscoverableRegistryRecord Aktion. Stellen Sie sicher, dass Ihre Richtlinie GetDiscoverableRegistryRecord die Verwendung BatchGet beinhaltet.

Wichtig

Die Ressourcen der Workload-Identität und des OAuth-Anmeldeinformationsanbieters verbleiben im Namespace. bedrock-agentcore Wenn Ihre Registries URL sync (source.fromUrl) mit OAuth- oder IAM-Anmeldeinformationen verwenden, müssen Sie neben Ihren neuen Berechtigungen auch die folgenden Berechtigungen beibehalten: agent-registry:*


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

Ersetzen Sie nicht jede bedrock-agentcore Aktion — diese Identitätsressourcen behalten bewusst den alten Namespace bei.

Beispiel: Aktualisierung der SDK-Clientkonfiguration

Aktualisieren Sie den Dienstnamen, die Clientklasse und die Endpunkt-URL in Ihren SDK-Aufrufen.

Vorher (öffentliche Vorschau):


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

Nachher (allgemeine Verfügbarkeit):


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

Beispiel: Aktualisierung von CLI-Befehlen

Ersetzen Sie den CLI-Namespace in allen Skripten und Automatisierungen.

Vorher (öffentliche Vorschau):


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

Nachher (allgemeine Verfügbarkeit):


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

Änderungen am API-Schema

Zusätzlich zur Namespace-Migration haben wir die Datenmodelle der Registrierung und der Registrierungsdatensätze für die allgemeine Verfügbarkeit aktualisiert. Diese Änderungen verbessern die Konsistenz und Erweiterbarkeit der API auf der Grundlage des Feedbacks aus der öffentlichen Vorversion. Dieser Abschnitt behandelt jede Änderungskategorie mit Vorher-Nachher-Beispielen, sodass Sie Ihren Anwendungscode aktualisieren können.

Änderung 1: Aktualisierungen der Registrierungseinheit

Die Autorisierungskonfiguration auf der Registrierungsressource — die steuert, wie auf die Datenebene einer Registrierung zugegriffen wird — befindet sich jetzt unter einem speziellen discoveryConfiguration Wrapper, der ihren Zweck deutlich macht. Die Genehmigungskonfiguration (die steuert, ob an PENDING_APPROVAL den Status übermittelte Datensätze automatisch in den Status überführt werden) wechselt von einem booleschen Wert zu einem erweiterbaren Enum-Array. APPROVED

Die spezifischen Feldänderungen sind:

authorizerTypeund authorizerConfiguration werden in ein neues discoveryConfiguration Objekt verschoben.
approvalConfiguration.autoApproval(boolean) wird durch approvalConfiguration.autoApprovalRules (Array von Enum-Zeichenketten) ersetzt. Der Wert "APPROVE_ALL" hat dieselbe semantische Bedeutung wie. autoApproval: true Die in der Enum-Liste angegebenen Regeln werden angewendet. Wenn (Null) nicht angegeben wird, ist eine Genehmigung erforderlich.

Vorher (öffentliche Vorschau):


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

Nachher (allgemeine Verfügbarkeit): mit Genehmigung ALLER


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

Nachher (allgemeine Verfügbarkeit): mit NULL in der Aufzählungsliste


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

Änderung 2: Neue Pflichtfelder in Registrierungsdatensätzen

Registrierungseinträge erhalten zwei neue Pflichtfelder auf oberster Ebene, um eine bessere Kategorisierung und Deduplizierung zu unterstützen. Sie müssen beide Felder angeben, wenn Sie einen Registrierungseintrag mithilfe der CreateRegistryRecord API erstellen, und Sie können sie später mithilfe der API ändern. UpdateRegistryRecord

Feld	Typ	Description
`name`	Zeichenfolge (erforderlich)	Eine eindeutige Kennung innerhalb der Registrierung, die vom Kunden angegeben werden kann. Jeder Datensatz muss einen eindeutigen Namen in der Registrierung haben. Wenn auch vorhanden `recordVersion` ist, `recordVersion` muss die Kombination von `name` und eindeutig sein.
`recordType`	Aufzählung (erforderlich)	Der semantische Typ des Datensatzes. Zulässige Werte: `AGENT`, `MCP`, `SKILL`, `CUSTOM`. Bestimmt, unter welchem primären Deskriptorschlüssel gültig ist. `descriptors` Sie können APIs wie `ListRegistryRecords` und verwenden`SearchDiscoverableRegistryRecords`, um Ergebnisse nach diesem semantischen Typ zu filtern.

Änderung 3: Umstrukturierung von Registrierungseinträgen

Das descriptors Feld wechselt von einer diskriminierten Union zu einer Struktur mit flachen Schlüsseln.

Im Vorgängermodell bestimmte das descriptorType Feld (MCP,, A2AAGENT_SKILLS,CUSTOM) die innere Form. Dadurch wurde der Deskriptorinhalt mit einer groben Protokoll- oder Formatklassifizierung verknüpft. Dieses Feld ist nicht mehr vorhanden. recordType, ein separates Attribut der obersten Ebene, ersetzt es für die semantische Kategorisierung. Die API erzwingt zur Laufzeit gültige Deskriptorschlüssel für jeden einzelnen Schlüssel und nicht recordType strukturell in der Form. Jeder Schlüssel der obersten Ebene darunter steht descriptors jetzt für einen detaillierten primären Deskriptortyp (z. B.,,,). a2aAgentCard mcpServer agentSkillsDefinition custom Zusätzliche Deskriptoren (zum Beispiel,skillMd) befinden sich unter denen des tools primären Deskriptors. additionalData Das inlineContent Feld wird. data Die protocolVersion Felder schemaVersion und werden konsolidiert zudataSchemaVersion.

Das synchronizationConfiguration Attribut der obersten Ebene wird zu jedem Deskriptor source und bewegt sich innerhalb jedes Deskriptors (einschließlich untergeordneter Objekte)additionalData.

Das bestehende name Feld wirddisplayName, wodurch seine Bedeutung expliziter wird. Ein neues name Feld dient als Dedup-Schlüssel und muss für alle Datensätze in einer Registrierung eindeutig sein. Wenn Sie beide name und recordVersion für denselben Datensatz angeben, muss ihre Kombination eindeutig sein.

Die folgenden Felder wurden umbenannt:

Vor	Nach	Hinweise
`name`	`displayName`	Anzeigename des Datensatzes. Es wird auch ein neues `name` Feld geben, das der Dedup-Schlüssel ist.
`descriptorType`	Entfernt	Ersetzt durch das Feld der obersten Ebene. `recordType`
`inlineContent`	`data`	Die Inhaltsnutzlast in jedem Deskriptor.
`schemaVersion` / `protocolVersion`	`dataSchemaVersion`	Einheitliches Versionsfeld für alle Deskriptortypen.
`synchronizationConfiguration`	`source`	In jeden Deskriptor verschoben (einschließlich untergeordneter Objekte)`additionalData`.

Vorher (öffentliche Vorschau):


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

Nachher (allgemeine Verfügbarkeit):


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

Die folgenden Einschränkungen gelten:

Pro Datensatz kann genau ein primärer Deskriptorschlüssel aufgefüllt werden. Die gültigen primären Deskriptoren pro recordType sind:

AGENT:a2aAgentCard,, mcpServer custom
MCP:mcpServer, custom
FÄHIGKEIT:agentSkillsDefinition, custom
BENUTZERDEFINIERT: custom

sourceist eher pro Deskriptor als ein einzelner Block der obersten Ebene. Es wird an Deskriptoren angehängt, die ein source Feld im Schema enthalten — und. mcpServer a2aAgentCard Das tools Kind (untermcpServer.additionalData), das agentSkillsDefinition Elternteil und der custom Deskriptor tragen Nein. source

Wird bei GA source.fromUrl nur unterstützt.

Auto-synchronization wird nur für die Deskriptoren mcpServer und die a2aAgentCard primären Deskriptoren ausgelöst, also für die Datensatztypen MCP und AGENT. A source für das skillMd Kind wird beibehalten, aber nicht zum Ausführen der Synchronisierung verwendet, und SKILL-Datensätze können nicht automatisch synchronisiert werden. BENUTZERDEFINIERTE Datensätze müssen manuell erstellt werden, indem sie direkt bereitgestellt data werden.

Änderung 4: Aktualisierungen des Filters auf der Datenebene

SearchRegistryRecordswird SearchDiscoverableRegistryRecords (POST /discoverable-records-search). Ihre Anfrage und Antwort übernehmen die neuen Feldnamen und das neue Datenmodell:

Filtert nach recordType (ersetztdescriptorType).
Filtert nach recordVersion (ersetztversion).
Die Antwort gibt Deskriptoren im neuen Format zurück, ohne. credentialProviderConfigurations

Das MCP-Suchtool search_registry_records wirdsearch_discoverable_registry_records, gibt das neue Deskriptorformat zurück und verwendet die neuen Filternamen.

Änderung 5: Neue Browsing-APIs

Zwei neue Datenebenen-APIs unterstützen das Erstellen von Surf- und Katalogerlebnissen anhand von genehmigten Datensätzen. Für diese APIs ist keine ausdrückliche Migration erforderlich. Wir erwähnen sie hier als Ergänzung zum API-Modell der AWS Agentenregistrierung bei GA.

ListDiscoverableRegistryRecords— Gibt eine paginierte Liste der genehmigten Registrierungseinträge zurück. Verwenden Sie diese Option, um Benutzeroberflächen für veröffentlichte Inhalte zu erstellen.


// 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— Ruft in einem einzigen Aufruf alle Details für einen Stapel von Datensätzen aus einer oder mehreren Registern ab.


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

Die Antwort umfasst ein registryRecords Array mit den vollständigen Datensatzdetails und ein errors Array für alle Datensätze, die nicht abgerufen werden konnten.

Beim Start wird genau ein Eintrag (eine Registrierung, 1—100 Datensatz-IDs) akzeptiert. Die gruppierte Form ist vorwärtskompatibel mit registrierungsübergreifendem Batching in future Versionen.

Änderung 6: Listen-APIs verwenden den Parameter für strukturierte Filter

In der öffentlichen Vorschau stellen List-APIs jedes filterbare Feld als eigenen Abfrageparameter zur Verfügung (z. B.--status READY,--recordType MCP). In GA ersetzt ein einzelner strukturierter filters Parameter diese diskreten Parameter. Der filters Wert ist eine Liste von { "name": "<dotted.path>", "values": ["<value>"] } Einträgen, wobei name es sich um einen durch Punkte getrennten Attributpfad handelt. Neue filterbare Felder, einschließlich verschachtelter Felder, werden zu neuen name Pfaden und nicht zu neuen API-Parametern. Listenoperationen ändern sich ebenfalls von bisGET. POST Die Paginierungsparameter (maxResults,nextToken) sind unverändert.

Vorher (öffentliche Vorschau):


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

Nachher (allgemeine Verfügbarkeit):


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

Datenmigrationen

Sie müssen Ihre vorhandenen Registrierungen und Registrierungseinträge vom Namespace in den bedrock-agentcore Namespace migrieren. agent-registry Wir stellen ein Skript zur Verfügung, das Sie bei der Migration unterstützt. Das Skript übernimmt die Extraktion vorhandener Daten, die Transformation vom alten Schema in das neue Schema und das Laden in Registrierungen im neuen Namespace. Das Skript erstellt neue Registrierungen im agent-registry Namespace innerhalb desselben Kontos und derselben Region. Es migriert alle vorhandenen Datensätze aus Ihren alten Registern in die neuen, wobei Änderungen des Namespace und des API-Schemas berücksichtigt werden.

Wählen Sie Ihren Migrationsansatz

Der richtige Ansatz hängt vom Umfang Ihrer Registry-Nutzung und Ihrer Betriebsumgebung ab.

Fall 1: Small-scale Migration mit direkter Skriptausführung

Profil: Weniger als 5 Registrierungen und weniger als 100 Datensätze. Sie haben direkten Zugriff auf ein Terminal oder CloudShell auf das Zielkonto.
Vorgehensweise: Führen Sie das Migrations-Python-Skript direkt aus. Das Skript stellt eine Verbindung zum Vorschau-Namespace her, listet Ihre Registries und Datensätze auf, wandelt die Daten in das GA-Schema um und erstellt sie im neuen Namespace. Dies ist der einfachste Pfad und erfordert keine Bereitstellung einer Infrastruktur.

Fall 2: Verwaltete Migration mit Lambda oder Glue

Profil: Sie haben keinen direkten Terminalzugriff auf die Zielumgebung, oder Sie bevorzugen ein verwaltetes Ausführungsmodell.
Ansatz: Stellen Sie die Migration als AWS Lambda-Funktion oder als AWS Glue-Job bereit. Die Migrations-Engine führt denselben Workflow zum Extrahieren, Transformieren und Laden durch, wird jedoch als verwalteter Job in Ihrem Konto ausgeführt. Bei den meisten Konten ist die vollständige Migration in weniger als 15 Minuten abgeschlossen.

Die Migrations-Engine:

Extrahiert Registrierungen und Datensätze aus dem Vorschau-Namespace und unterstützt sowohl vollständige als auch inkrementelle Ladevorgänge. Es durchsucht alle API-Antworten und serialisiert die Daten bis zu einem Staging-Speicherort.
Transformiert jeden Datensatz, indem die API-Schemaänderungen angewendet werden (Umbenennungen von Feldern, Umstrukturierung der Deskriptoren, neue Pflichtfelder).
Lädt die transformierten Daten in den neuen agent-registry Namespace und erstellt Registrierungen und Datensätze mithilfe der GA-API.
Generiert einen Bericht mit einer Zusammenfassung der migrierten Daten, der aufgetretenen Fehler und der Anzahl der zu überprüfenden Datensätze.

Fall 3: Dual-write Migration für aktive Produktionsworkloads

Profil: Sie haben eine Plattform oder Automatisierungspipeline auf der Grundlage der öffentlichen Vorschau-APIs aufgebaut und schreiben aktiv neue Daten in der Produktion.
Ansatz: Verwenden Sie eine Migrationsstrategie mit zwei Schreibvorgängen, um Datenverluste während der Umstellung zu vermeiden:
- Aktualisieren Sie Ihren Writer — Ändern Sie Ihre Anwendung so, dass sie gleichzeitig in den Vorschau-Namespace und in den neuen agent-registry Namespace schreibt.
- Führen Sie das Migrationsskript mit Deduplizierung aus — Führen Sie das Migrationstool aus, um historische Daten zu migrieren. Das Skript dedupliziert basierend auf dem name Feld, sodass Datensätze, die bereits im neuen Namespace (aus Ihrem Dual-Write) vorhanden sind, nicht dupliziert werden.
- Wechseln Sie Ihr Lesegerät — Nachdem Sie sich vergewissert haben, dass alle Daten im neuen Namespace vorhanden sind, aktualisieren Sie Ihre Anwendung so, dass sie ausschließlich aus liest. agent-registry
- Dual-Write-Funktion entfernen — Nachdem Sie sich vergewissert haben, dass alle Lese- und Schreibvorgänge im neuen Namespace erfolgreich waren, entfernen Sie den Vorschau-Namespace-Writer aus Ihrer Anwendung.

Überprüfung Ihrer Migration

Stellen Sie nach dem Ausführen der Migration sicher, dass Ihre Daten korrekt migriert wurden:

Listen Sie mit dem list-registries CLI-Befehl alle Registrierungen im neuen Namespace auf und vergewissern Sie sich, dass die Anzahl mit Ihrer Quelle übereinstimmt.
Vergleichen Sie für jede Registrierung die Anzahl der Datensätze mit. list-registry-records
Spot-check einzelne Datensätze, um zu bestätigen, dass die Deskriptoren korrekt transformiert wurden (Umbenennung von Feldern, Umstrukturierung der Deskriptoren).
Aktualisieren Sie Ihre IAM-Richtlinien, Endpoints und SDK-Clients wie im Abschnitt Namespace- und Konfigurationsänderungen beschrieben.
Stellen Sie sicher, dass Ihre Anwendungen mit dem neuen Namespace erfolgreich lesen und schreiben können.

Häufig gestellte Fragen

Was ändert sich in AWS Agentenregistrierung?

AWS Die Agentenregistrierung wird vom öffentlichen bedrock-agentcore Vorschau-Namespace in den allgemein verfügbaren agent-registry Namespace verschoben. Die Migration umfasst drei Bereiche: Namespace- und Konfigurationsänderungen (Endpunkte, IAM, SDK, CLI, ARNs, Observability), API-Schemaänderungen (umstrukturiertes Datenmodell für Registries und Datensätze) und Datenmigration (Verschieben Ihrer vorhandenen Registries und Datensätze in den neuen Namespace).

`Kann ich Registry weiterhin im Bedrock-Agentcore-Namespace verwenden?`

Ihre bestehende Nutzung der Registrierung im bedrock-agentcore Namespace funktioniert während des Migrationsfensters weiterhin ohne Unterbrechung. Wir empfehlen jedoch, dass Sie mit der Migration beginnen, sobald die Tools verfügbar sind, um sicherzustellen, dass Sie genügend Zeit haben, sowohl die Datenmigration als auch die Codeaktualisierungen abzuschließen.

Wenn Sie jedoch bis zum 6. August 2026 nicht über bestehende Registrierungen oder Datensätze verfügen, können Sie ab dem 6. August 2026 nicht mehr auf den bedrock-agentcore Namespace für AWS Agent Registry zugreifen. Wenn Sie seit dem 6. August 2026 über bestehende Registrierungen oder Datensätze verfügen, haben Sie während des Migrationsfensters (6. August 2026 — 17. September 2026) Zugriff auf den bedrock-agentcore Namespace für AWS Agent Registry.

Werden meine Daten automatisch migriert?

Nein. Sie müssen die Migration mithilfe der von uns bereitgestellten Migrationstools selbst initiieren. Einzelheiten zu den verfügbaren Ansätzen, die auf Ihrer Skala basieren, finden Sie im Abschnitt Datenmigration.

Welche API-Schemaänderungen sind enthalten?

Zusätzlich zur Änderung des Namespaces haben wir das API-Datenmodell in sechs Bereichen aktualisiert: Registrierungseinheit (Autorisierungskonfiguration gruppiert unterdiscoveryConfiguration), neue Felder im Registrierungseintrag (nameundrecordType), Restrukturierung von Registrierungseinträgen (vereinfachte Deskriptoren, Umbenennung von Feldern), Aktualisierungen von Such-API-Filtern (recordType,recordVersion), neue Browser-APIs (ListDiscoverableRegistryRecords,BatchGetDiscoverableRegistryRecord) und strukturierte Filter für Listenoperationen.

Wie lange wird die Datenmigration dauern?

Die Migrationszeit hängt von der Anzahl der Register und Datensätze in Ihrem Konto ab. Bei Konten mit weniger als 100 Datensätzen ist die Migration innerhalb von Minuten abgeschlossen, wenn sie lokal ausgeführt wird. Bei Konten mit Tausenden von Datensätzen sollten Sie damit rechnen, dass die Migration in weniger als 15 Minuten abgeschlossen ist, wenn sie als verwalteter Job ausgeführt wird.

Was ist, wenn ich eine umfangreiche Bereitstellung mit aktiven Schreibvorgängen habe?

Wenn Sie in der Produktion aktiv Daten in den Vorschau-Namespace schreiben, verwenden Sie die Dual-Write-Migrationsstrategie, wie in Fall 3 beschrieben. Dieser Ansatz stellt sicher, dass während der Umstellung keine Daten verloren gehen, indem in beide Namespaces gleichzeitig geschrieben wird, historische Daten mit Deduplizierung migriert und dann Lesevorgänge unterbrochen werden.

Wo kann ich Hilfe bekommen?

Wenn Sie Fragen haben oder Unterstützung bei Ihrer Migration benötigen, wenden Sie sich an den AWS Support.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Fehlerbehebung

Sicherheit