跨帳號連結 Amazon Bedrock 代理至 Redshift Serverless 知識庫的完整指南
在大型企業的多帳號 AWS 架構中，AI 代理（Amazon Bedrock AgentCore）常需要從位於其他帳號的結構化資料庫取得答案。本文說明如何讓一個帳號的 AgentCore 代理，直接對另一帳號以 Amazon Redshift Serverless 為底層的 Amazon Bedrock 知識庫（Retrieval‑Augmented Generation，簡稱 RAG）執行 RetrieveAndGenerate，且不必搬移原始資料。
背景與挑戰
- 跨帳號資料分隔：將 AI 代理與資料庫放在不同帳號，可維持工作負載的清晰邊界，但會產生 IAM 權限與資源政策的衝突。
- Bedrock 知識庫資源政策：支援
Retrieve與GetDocumentContent的跨帳號操作，卻不包含RetrieveAndGenerate（即同時檢索並產生答案）。因此必須在知識庫帳號內部以受限的 IAM 角色 先取得 STS 臨時憑證，再呼叫RetrieveAndGenerate。
兩種可用的 Orchestration 模式
| 變體 | 部署方式 | 代理迴圈擁有者 | 主要差異 |
|------|----------|----------------|----------|
| Variant 1 | 以 Strands 程式碼代理部署至 AgentCore 執行階段 | 代理本身（程式碼） | 代理直接在執行環境內部呼叫 STS、取得角色、執行 RetrieveAndGenerate，然後回傳答案與引用。 |
| Variant 2 | 使用 宣告式 AgentCore harness（受管服務） | Harness（受管層） | 代理的迴圈由受管服務管理，工具同樣以 STS 取得角色，但部署方式更簡化，適合不想自行管理容器的團隊。 |
兩個變體共享相同的 跨帳號資料存取邊界：
-
代理在來源帳號發起請求。
-
透過 AWS STS 取得目標帳號的 IAM 角色臨時憑證。
-
以該角色呼叫
RetrieveAndGenerate，取得生成的答案與文件引用。 -
代理將結果回傳給使用者或上層應用。
請求流程概覽
- 圖 2（程式碼版 Strands 代理）：展示代理在本地程式碼層面完成 STS 換票、API 呼叫與結果回傳的完整路徑。
- 圖 3（宣告式 Harness）：說明受管服務自動處理角色取得與 API 呼叫，開發者僅需定義資料來源與輸出格式。
未來展望與讀者啟示
此解決方案證明，即使在嚴格的多帳號環境下，也能安全且即時地將 Amazon Bedrock 與 Redshift Serverless 結合，為企業提供高效的 RAG 能力。未來，隨著 Bedrock 知識庫資源政策支援更多操作（如直接允許 RetrieveAndGenerate），跨帳號整合的實作將更為簡化。建議讀者在規劃 AI 代理時，先評估 Variant 1 與 Variant 2 的部署成本與維運需求，選擇最符合組織安全與開發速度的路徑。