# 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:
1. **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.
1. **Ä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.
1. **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 ](https://github.com/awslabs/agentcore-samples) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html).
**Anmerkung**
Wenn Sie derzeit die [BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html) AWS verwaltete Richtlinie für den Zugriff auf die AWS Agentenregistrierung verwenden (siehe [BedrockAgentCoreFullAccess Richtliniendetails](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam-awsmanpol.html#security-iam-awsmanpol-BedrockAgentCoreFullAccess)), müssen Sie sie durch die neue **AgentRegistryFullAccess**verwaltete 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:
+ `authorizerType`und `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`,, `A2A``AGENT_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 zu`dataSchemaVersion`.
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 wird`displayName`, 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`
`source`ist 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 (unter`mcpServer.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
`SearchRegistryRecords`wird `SearchDiscoverableRegistryRecords` (`POST /discoverable-records-search`). Ihre Anfrage und Antwort übernehmen die neuen Feldnamen und das neue Datenmodell:
+ Filtert nach `recordType` (ersetzt`descriptorType`).
+ Filtert nach `recordVersion` (ersetzt`version`).
+ Die Antwort gibt Deskriptoren im neuen Format zurück, ohne. `credentialProviderConfigurations`
Das MCP-Suchtool `search_registry_records` wird`search_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": "", "values": [""] }` 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 bis`GET`. `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 unter`discoveryConfiguration`), neue Felder im Registrierungseintrag (`name`und`recordType`), 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](https://aws.amazon.com/support).