本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
完整的登錄檔遷移指南
AWS 客服人員登錄檔 — 遷移至新的agent-registry命名空間
簡介
作為 2026 年 8 月 6 日推出新agent-registry命名空間的一部分, AWS Agent Registry 正在為服務主體、資料和 API 模型引入重大變更。如果您在 bedrock-agentcore 命名空間下使用 AWS 代理程式登錄檔,您必須完成跨越三個區域的遷移:
-
命名空間和組態變更 – 我們將 AWS 代理程式登錄檔從 AWS Bedrock AgentCore 命名空間移至自己的專用命名空間。此命名空間變更僅適用於 AWS 客服人員登錄檔。所有其他 AgentCore 產品,例如 Identity、Gateway、Runtime 和 Policy,都不會受到影響。對於 AWS 客服人員登錄檔,服務命名空間會從 變更為
bedrock-agentcoreagent-registry。這會影響參考服務的每個表面:端點、IAM 政策、SDK 用戶端、CLI 命令、資源 ARNs 和可觀測性整合。您必須更新程式碼和基礎設施,才能使用新的命名空間。 -
API 結構描述變更 – 登錄檔和登錄檔記錄資料模型會根據來自
bedrock-agentcore命名空間的客戶意見回饋進行更新。這些變更會破壞與現有 API 結構描述的回溯相容性。建構或剖析 API 請求和回應的應用程式程式碼必須更新,以反映新的結構描述,作為遷移至新命名空間的一部分。 -
資料遷移 – 您必須將現有的登錄檔和登錄檔記錄從舊命名空間遷移到新的命名空間。我們提供遷移工具來擷取您的資料、將其轉換為新的結構描述,並將其載入新的命名空間。資料會遷移至相同的帳戶和區域,只有命名空間會變更。
本指南提供before-and-after範例,詳細說明每個區域,協助您規劃和執行遷移。
什麼是遷移時間表?
您必須為此遷移記住兩個重要的里程碑:
-
2026 年 8 月 6 日 — AWS 代理程式登錄檔的新
agent-registry命名空間正式啟動。在 AWS Agent Registry 主控台中存取 服務。如果您有現有的登錄檔和記錄,您可以同時存取 bedrock-agentcore和agent-registry命名空間。遷移工具可在 GitHub 網站上的 agentcore-samples 儲存庫中使用。您可以開始遷移程序。 注意
如果您是新客戶,且自 2026 年 8 月 6 日起沒有現有的登錄檔或記錄,則無法透過
bedrock-agentcore命名空間存取 AWS 客服人員登錄檔。直接從agent-registry命名空間開始使用 AWS 代理程式登錄檔。 -
2026 年 9 月 17 日 — 遷移時段關閉。舊
bedrock-agentcore命名空間在此日期關閉。您會失去對服務和舊命名空間中任何剩餘資料的讀取/寫入存取權。在此日期之後,您必須使用agent-registry命名空間。
命名空間和組態變更
agent-registry 命名空間bedrock-agentcore會在下列位置取代 。本節列出變更的每個表面,並提供如何更新程式碼的範例。
重要
命名空間變更只會影響 AWS Agent Registry 提供的 APIs,但不會影響 AWS Bedrock AgentCore 的其餘部分,例如 AWS AgentCore Identity。因此,工作負載身分和 OAuth 憑證提供者資源會保留在 bedrock-agentcore 命名空間下。
服務端點
您的應用程式必須指向新的端點主機名稱。新的端點使用 .api.aws網域。
| Surface | 舊值 | 新值 |
|---|---|---|
|
資料平面端點 |
|
|
|
控制平面端點 |
|
|
IAM 和安全性
必須bedrock-agentcore更新參考的所有 IAM 政策、服務控制政策 (SCPs) 和許可界限。資源 ARNs也會變更以反映新的命名空間。
| Surface | 舊值 | 新值 |
|---|---|---|
|
IAM 動作字首 |
|
|
|
服務主體 |
|
|
|
登錄檔 ARN |
|
|
|
記錄 ARN |
|
|
如果您有剖析 ARNs 或存放它們的自動化,也請更新這些參考。具有 IAM 動作字首或服務主體條件的自訂政策必須更新,以符合新值。若要查看與 AWS 客服人員登錄檔相關聯的 IAM 許可完整清單,請參閱AWS 客服人員登錄檔 IAM 許可參考。
注意
如果您目前使用 BedrockAgentCoreFullAccess AWS 受管政策進行 AWS 代理程式登錄存取 (請參閱 BedrockAgentCoreFullAccess 政策詳細資訊),則必須將其取代為新的 AgentRegistryFullAccess 受管政策 (已於 2026 年 8 月 6 日提供)。舊的 BedrockAgentCoreFullAccess 受管政策將不會更新為包含agent-registry:*許可。
SDK、CLI 和基礎設施
更新您的應用程式程式碼、部署指令碼和infrastructure-as-code範本,以參考新的用戶端類別和 CLI 命名空間。
| Surface | 舊值 | 新值 |
|---|---|---|
|
Dataplane SDK 用戶端類別 |
|
|
|
控制平面 SDK 用戶端類別 |
|
|
|
CLI 命名空間 |
|
|
|
Service Quotas 程式碼 |
|
|
如果您先前在bedrock-agentcore服務代碼下請求增加自訂配額,則必須在 下重新請求。 agent-registry
可觀測性和事件
更新任何參考舊命名空間的 CloudTrail Lake 查詢、Athena 查詢、SIEM 整合、EventBridge 規則、CloudWatch 儀表板和警示。
| Surface | 舊值 | 新值 |
|---|---|---|
|
CloudTrail 事件來源 |
|
|
|
EventBridge 來源 |
|
|
|
CloudWatch 命名空間 |
|
|
EventBridge 通知
在 bedrock-agentcore 命名空間下, AWS 代理登錄檔會在事件來源下發出兩個 Amazon EventBridge aws.bedrock-agentcore事件。事件來源現在會變更為 aws.agent-registry,資源 ARNs 會採用新的命名空間,而通知涵蓋範圍會擴展至完整的登錄記錄和登錄生命週期。事件會繼續前往資源自己的帳戶中的預設 EventBridge 匯流排。您必須更新與舊來源或舊詳細資訊類型字串相符的任何 EventBridge 規則。
| Surface | 舊值 | 新值 |
|---|---|---|
|
事件來源 |
|
|
|
資源 ARN 命名空間 |
|
|
|
事件匯流排 |
預設匯流排 |
預設匯流排 (未變更) |
|
登錄記錄事件 |
1 詳細資訊類型 ( |
5 種詳細資訊類型 (完整核准生命週期) |
|
登錄檔事件 |
1 詳細資訊類型 ( |
7 種詳細資訊類型 (完整登錄生命週期) |
|
事件 |
|
(未變更) |
重要
登錄檔 (父系) 詳細資訊類型從句子變更為簡短狀態字串。符合詳細資訊類型的規則Registry State transitions from Creating to Ready不會再觸發 - 將其更新為 Registry Ready。登錄記錄詳細資訊類型Registry Record State changed to Pending Approval保持不變,因此相符的規則會在您更新 後繼續運作source。
登錄檔記錄事件。當登錄檔記錄在核准工作流程狀態之間轉換時發出。 Resources是完整記錄 ARN; detail包含 registryRecordId和 registryId。
| 詳細資訊類型 | 觸發條件 |
|---|---|
|
|
記錄版本進入 |
|
|
|
|
|
記錄轉換至 |
|
|
記錄轉換至 |
|
|
記錄轉換至 |
登錄檔事件。在登錄檔佈建和生命週期轉換時發出。 Resources是完整的登錄檔 ARN; detail 包含 registryId和 registryName。
| 詳細資訊類型 | 觸發條件 |
|---|---|
|
|
登錄檔進入 |
|
|
登錄檔變成 |
|
|
登錄檔進入 |
|
|
登錄檔進入 |
|
|
登錄檔進入 |
|
|
登錄檔進入 |
|
|
登錄檔進入 |
範例事件 (登錄記錄)。
之前 (bedrock-agentcore要取代的命名空間):
{ "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" } }
After (agent-registry 命名空間):
{ "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" } }
注意
若要使用單一規則比對任何登錄記錄狀態變更,請在 source(aws.agent-registry) 上比對 加上 的detail-type字首Registry Record State changed to。若要符合任何登錄生命週期變更,請在 `Registry ` detail-type 字首上進行比對。
範例:更新 IAM 政策
取代所有 IAM 政策中的動作字首和資源 ARN 命名空間。
之前 (bedrock-agentcore要取代的命名空間):
{ "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:*"] }] }
After (agent-registry 命名空間):
{ "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:*"] }] }
注意
BatchGetDiscoverableRegistryRecord API 沒有自己的 IAM 動作。它會針對 agent-registry:GetDiscoverableRegistryRecord動作授權每個請求的記錄。確保您的政策包含 GetDiscoverableRegistryRecord以使用 BatchGet。
重要
工作負載身分和 OAuth 登入資料提供者資源會保留在 bedrock-agentcore 命名空間下。如果您的登錄檔使用 URL 同步 (source.fromUrl) 搭配 OAuth 或 IAM 登入資料,您必須保留下列許可以及新的agent-registry:*許可:
"bedrock-agentcore:CreateWorkloadIdentity", "bedrock-agentcore:GetWorkloadIdentity", "bedrock-agentcore:DeleteWorkloadIdentity"
請勿取代每個bedrock-agentcore動作 — 這些身分資源刻意保留舊命名空間。
範例:更新 SDK 用戶端組態
更新 SDK 呼叫中的服務名稱、用戶端類別和端點 URL。
之前 (bedrock-agentcore要取代的命名空間):
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" )
After (agent-registry 命名空間):
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" )
範例:更新 CLI 命令
取代所有指令碼和自動化中的 CLI 命名空間。
之前 (bedrock-agentcore要取代的命名空間):
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
After (agent-registry 命名空間):
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
API 結構描述變更
除了命名空間遷移之外,我們也更新agent-registry了命名空間中的登錄檔和登錄檔記錄資料模型。這些變更會根據 bedrock-agentcore 命名空間的意見回饋,改善 API 的一致性和可擴展性。本節涵蓋範例前後的每個變更類別,讓您可以更新應用程式程式碼。
變更 1:登錄實體更新
登錄檔資源上的授權組態 — 控制登錄檔資料平面的存取方式 — 現在位於專用discoveryConfiguration包裝函式下,以明確其用途。核准組態 (控制提交至PENDING_APPROVAL狀態的記錄是否自動轉換為APPROVED狀態) 從布林值移至可擴展列舉陣列。
特定欄位變更包括:
-
authorizerType和authorizerConfiguration會在新discoveryConfiguration物件內移動。 -
approvalConfiguration.autoApproval(布林值) 取代為approvalConfiguration.autoApprovalRules(列舉字串陣列)。此值"APPROVE_ALL"具有與 相同的語意意義autoApproval: true。系統會套用列舉清單中指定的規則。未指定 (空) 表示需要核准。
之前 (bedrock-agentcore要取代的命名空間):
{ "name": "string", "description": "string", "authorizerConfiguration": { ... }, "authorizerType": "string", "approvalConfiguration": { "autoApproval": true } }
After (agent-registry 命名空間):含 Approval ALL
{ "name": "string", "description": "string", "discoveryConfiguration": { "authorizerConfiguration": { ... }, "authorizerType": "string" }, "approvalConfiguration": { "autoApprovalRules": ["APPROVE_ALL"] } }
After (agent-registry 命名空間):列舉清單中具有 NULL
{ "name": "string", "description": "Registry with manual approval only", "approvalConfiguration": { "autoApprovalRules": [] } }
變更 2:登錄檔記錄上的新必要欄位
登錄檔記錄會取得兩個新的必要頂層欄位,以支援更好的分類和重複資料刪除。使用 CreateRegistryRecord API 建立登錄檔記錄時,您必須指定這兩個欄位,之後可以使用 UpdateRegistryRecord API 進行變更。
| 欄位 | Type | 說明 |
|---|---|---|
|
|
字串 (必要) |
登錄檔中的唯一識別符,可由客戶指定。每個記錄都必須在登錄檔中具有唯一的名稱。當 |
|
|
Enum (必要) |
記錄的語意類型。有效值: |
變更 3:登錄檔記錄重組
descriptors 欄位會從區分的聯集變更為平面鍵控結構。
在先前的模型中, descriptorType 欄位 (MCP、A2A、AGENT_SKILLS、CUSTOM) 決定了內部形狀。此結合描述項內容至粗略通訊協定或格式分類。該欄位不再存在。 recordType是單獨的頂層屬性,會將其取代為語意分類。API 會在recordType執行時間對每個 強制執行有效的描述項索引鍵,而不是在結構上強制執行形狀。下的每個最上層索引鍵descriptors現在代表精細的主要描述項類型 (例如 a2aAgentCard、mcpServer、agentSkillsDefinition、)custom。補充描述項 (例如 tools、skillMd) 在主要描述項的 下巢狀additionalData。inlineContent 欄位會變成 data。schemaVersion 和 protocolVersion 欄位合併為 dataSchemaVersion。
最上層synchronizationConfiguration屬性會變成source並在每個描述項 (包括additionalData子項) 內移動。
現有name欄位會變成 displayName,使其含義更明確。新網路name欄位做為 dedup 金鑰,且登錄檔中的所有記錄都必須是唯一的。如果您recordVersion同時為相同的記錄指定 name和 ,則其組合必須是唯一的。
下列欄位會重新命名:
| Before | After | 備註 |
|---|---|---|
|
|
|
顯示記錄的名稱。也會有一個新 |
|
|
已移除 |
以最上層 |
|
|
|
每個描述項的內容承載。 |
|
|
|
所有描述項類型的統一版本欄位。 |
|
|
|
在每個描述項內移動 (包括 |
之前 (bedrock-agentcore要取代的命名空間):
{ "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" } ] } }, ... }
After (agent-registry 命名空間):
{ "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" } } ... }
以下為目前的限制:
每個記錄可以填入一個主要描述項索引鍵。每個 的有效主要描述項recordType為:
-
代理程式:
a2aAgentCard、mcpServer、custom -
MCP:
mcpServer、custom -
技能:
agentSkillsDefinition、custom -
自訂:
custom
source 是每個描述項,而不是單一頂層區塊。它連接到在結構描述中攜帶source欄位的描述項 - mcpServer和 a2aAgentCard。tools 子項 (在 下mcpServer.additionalData)、agentSkillsDefinition父項和custom描述項不帶 source。
在 agent-registry 命名空間中,僅支援 source.fromUrl 。
自動同步只會針對 mcpServer和a2aAgentCard主要描述項觸發,也就是 MCP 和 AGENT 記錄類型。skillMd 子source系上的 會保留,但不會用來執行同步,且 SKILL 記錄無法自動同步。必須透過data直接提供 手動建立 CUSTOM 記錄。
變更 4:資料平面篩選條件更新
SearchRegistryRecords 會變成 SearchDiscoverableRegistryRecords(POST /discoverable-records-search)。其請求和回應會挑選新的欄位名稱和資料模型:
-
依 篩選
recordType(取代descriptorType)。 -
依 篩選
recordVersion(取代version)。 -
回應會以新格式傳回描述項,不含
credentialProviderConfigurations。
MCP 搜尋工具search_registry_records會變成 search_discoverable_registry_records,傳回新的描述項格式,並使用新的篩選條件名稱。
變更 5:新的瀏覽 APIs
兩個新的資料平面 APIs 支援透過核准的記錄建置瀏覽和目錄體驗。這些 APIs 不需要任何明確的遷移;我們在此處提及它們作為agent-registry命名空間中 AWS 代理登錄 API 模型的補充。
ListDiscoverableRegistryRecords — 傳回已核准登錄記錄的分頁清單。使用此項目透過發佈的內容建置瀏覽介面。
// 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 — 在單一呼叫中擷取一個或多個登錄檔中記錄批次的完整詳細資訊。
// 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" } ] }
回應包含包含完整記錄詳細資訊的registryRecords陣列,以及任何無法擷取之記錄的errors陣列。
啟動時,只接受一個項目 (一個登錄檔、1-100 IDs)。分組形狀與未來版本的跨登錄批次相容。
變更 6:列出 APIs採用結構化篩選條件參數
在bedrock-agentcore命名空間中,列出 APIs會將每個可篩選欄位公開為自己的查詢參數 (例如,--status READY、--recordType MCP)。在 agent-registry 命名空間中,單一結構化filters參數會取代這些離散參數。filters 值是{ "name": "<dotted.path>", "values": ["<value>"] }項目清單,其中 name 是點分隔屬性路徑。新的可篩選欄位,包括巢狀欄位,會變成新的name路徑,而不是新的 API 參數。清單操作也會從 變更為 GET POST。分頁參數 (maxResults、nextToken) 保持不變。
之前 (bedrock-agentcore要取代的命名空間):
GET /registries?status=READY&authorizerType=AWS_IAM GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP
After (agent-registry 命名空間):
// 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" }
資料遷移
您必須將現有的登錄檔和登錄檔記錄從 bedrock-agentcore 命名空間遷移到 agent-registry 命名空間。我們提供遷移工具來協助遷移。此工具會處理現有資料的擷取、從舊結構描述轉換到新結構描述,以及載入至新命名空間中的登錄檔。此工具會在相同帳戶和區域中的agent-registry命名空間中建立新的登錄檔。它會將所有現有的記錄從舊登錄檔遷移到新的登錄檔,並考慮命名空間和 API 結構描述變更。
遷移工具可在 GitHub 網站上的 agentcore-samples 儲存庫
選擇遷移方法
正確的方法取決於一次性完整遷移是否足夠,或者是否需要全自動執行,以及在切換時執行增量負載的能力。
案例 1:簡易遷移
-
設定檔:一次性完整遷移已足夠。您不需要執行增量載入或讓任務在無人看管的情況下執行。
-
方法:直接從終端機或 AWS CloudShell 執行遷移工具。沒有要部署的基礎設施。此工具會連線至
bedrock-agentcore命名空間、擷取您的登錄檔和記錄、將資料轉換為agent-registry結構描述,並在新的命名空間中建立它們。這是最簡單的路徑,不需要部署基礎設施。
案例 2:使用 Glue AWS 進行受管遷移
-
設定檔:您偏好全自動執行,或者您計劃在一段時間內平行執行兩個登錄檔版本,並在切換時需要增量負載來擷取初始完整執行後在
bedrock-agentcore命名空間中建立或更新的任何記錄。 -
方法:使用提供的 CDK AWS 堆疊將遷移部署為 Glue 任務。任務會在您的帳戶中執行,而不取決於開啟的終端機工作階段。
典型的流程是:執行完整遷移以讓
agent-registry命名空間保持最新狀態,然後在驗證和更新整合時平行操作這兩個命名空間。當您準備好切換時,請執行增量載入,以同步在平行期間變更的任何記錄,驗證並將流量切換到agent-registry命名空間。
案例 3:主動-主動遷移
-
設定檔:您已在
bedrock-agentcore命名空間 APIs 上建置平台或自動化管道,並持續在生產環境中撰寫新記錄。 -
方法:使用 受管 AWS Glue 型方法從完整遷移開始,將所有歷史資料帶入
agent-registry命名空間。然後將您的平台或管道指向agent-registry命名空間以及bedrock-agentcore命名空間,您的應用程式會同時寫入兩者。使用此主動-主動期間來驗證您的整合,並建立agent-registry對命名空間的信心。滿足之後,請切換所有讀取和寫入 ,agent-registry並解除委任bedrock-agentcore命名空間整合。
驗證您的遷移
執行遷移後,請確認您的資料已正確遷移:
-
使用 CLI
list-registries命令列出新命名空間中的所有登錄檔,並確認計數與您的來源相符。 -
對於每個登錄檔,使用 比較記錄計數
list-registry-records。 -
Spot 檢查個別記錄,以確認描述項已正確轉換 (欄位重新命名、描述項重組)。
-
更新您的 IAM 政策、端點和 SDK 用戶端,如命名空間和組態變更一節中所述。
-
確認您的應用程式可以使用新的命名空間成功讀取和寫入。
更新同步記錄的 IAM 信任政策
如果您的任何登錄檔記錄使用 Synchronize 與 IAM 角色登入資料類型,您必須先更新角色的信任政策,才能執行即時載入。擔任該角色的服務主體在新命名空間agent-registry.amazonaws.com中從 bedrock-agentcore.amazonaws.com 變更為 。使用 OAuth 登入資料或沒有授權的記錄不受影響。
注意
遷移工具無法偵測到此情況,工具永遠不會擔任同步角色。建立記錄後,登錄服務會以非同步方式假設。如果您略過此步驟,遷移的記錄會抵達指向相同角色的agent-registry命名空間,同步會失敗,直到角色信任新的委託人為止。
更新每個受影響記錄所參考之角色的信任政策。
之前 (bedrock-agentcore要取代的命名空間):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "bedrock-agentcore.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
After (agent-registry 命名空間):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "agent-registry.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
如果記錄因為此原因而失敗,遷移的記錄會處於 CREATE_FAILED 狀態。遷移工具拒絕覆寫失敗狀態的記錄,因此單獨修正信任政策不會解決它。若要復原:
-
更新受影響角色的信任政策。
-
從
agent-registry命名空間刪除CREATE_FAILED記錄。 -
重新執行載入。
常見問答集
AWS 客服人員登錄檔中有哪些變更?
AWS 客服人員登錄檔正在從bedrock-agentcore命名空間移至新的專用agent-registry命名空間。遷移跨越三個領域:命名空間和組態變更 (端點、IAM、SDK、CLI、ARNs、可觀測性)、API 結構描述變更 (登錄和記錄的結構化資料模型),以及資料遷移 (將現有的登錄和記錄移至新的命名空間)。
我可以在bedrock-agentcore命名空間繼續使用登錄檔嗎?
命名bedrock-agentcore空間上現有的登錄檔使用量會繼續運作,而不會在遷移時段中斷。不過,我們建議您在工具可用時立即開始遷移,以確保您有足夠的時間完成資料遷移和程式碼更新。
不過,如果您自 2026 年 8 月 6 日起沒有現有的登錄檔或記錄,則無法從 2026 年 8 月 6 日起存取 AWS 代理程式登錄檔的bedrock-agentcore命名空間。如果您在 2026 年 8 月 6 日有現有的登錄檔或記錄,您可以在遷移時段 (2026 年 8 月 6 日至 2026 年 9 月 17 日) 期間存取 AWS 代理程式登錄檔bedrock-agentcore的命名空間。
我的資料是否會自動遷移?
否。您必須使用我們提供的遷移工具自行啟動遷移。如需根據您的規模可用方法的詳細資訊,請參閱資料遷移一節。
包含哪些 API 結構描述變更?
除了命名空間變更之外,我們也更新了六個領域的 API 資料模型:登錄實體 (在 下分組的授權組態discoveryConfiguration)、登錄記錄新欄位 (name 和 recordType)、登錄記錄重組 (平面化描述項、欄位重新命名)、搜尋 API 篩選條件更新 (recordType、recordVersion)、新的瀏覽 APIs (ListDiscoverableRegistryRecords、BatchGetDiscoverableRegistryRecord),以及清單操作的結構化篩選條件。
資料遷移需要多長時間?
遷移時間取決於您帳戶中的登錄檔和記錄數目。對於記錄少於 100 的帳戶,遷移會在本機執行時於幾分鐘內完成。對於有數千筆記錄的帳戶, 預期在以受管任務身分執行時,遷移會在 15 分鐘內完成。
如果我有具有作用中寫入的大規模部署,該怎麼辦?
如果您正在積極將資料寫入生產環境中的bedrock-agentcore命名空間,請使用主動-主動遷移方法,如案例 3 中所述。從完整遷移開始,讓agent-registry命名空間保持最新狀態,然後同時寫入這兩個命名空間,以驗證您的整合並建立對新命名空間的信心。當您準備好agent-registry時,請切換讀取和寫入 。
哪裡可以取得協助?
如需遷移的問題或協助,請聯絡 AWS Support