共享基礎設施,隔離租戶:使用 Amazon Bedrock AgentCore 實現池模型多租戶
本文介紹瞭如何使用 Amazon Bedrock AgentCore 構建生產級多租戶 AI 系統的模式,透過醫療 AI 助手示例展示了租戶隔離、服務層級差異化、成本追蹤和可觀測性等關鍵能力。
構建多租戶 AI 應用面臨新的架構挑戰。您需要在客戶之間實現完全的租戶隔離,提供不同功能的服務層級,進行細粒度的成本追蹤,並確保每個租戶的可觀測性。缺少這些,可能會暴露客戶資料、無法提供適當的服務質量或產生不可預見的成本。
在本文中,您將學習使用 Amazon Bedrock AgentCore 實現生產級多租戶系統的模式。這些模式將透過服務多個診所和醫院的醫療 AI 助手來展示。雖然本文以醫療領域為例,但架構模式和實施技術廣泛適用於各種多租戶 AI 應用。無論您是在構建 SaaS 平臺、服務多個業務部門的企業解決方案,還是為不同客戶組織提供託管服務,都可以使用這些架構模式來構建您的解決方案。
您將學習的內容包括:如何利用原生 AWS 能力在智慧體應用中實現完整的租戶隔離;如何透過最小化自定義程式碼實現服務層級差異化;每個租戶的精細成本歸屬技術;以及可擴充套件多租戶 AI 架構的最佳實踐。
本文是系列文章“使用 Amazon Bedrock AgentCore 構建多租戶智慧體”的第二部分。第一部分探討了架構多租戶智慧體應用的設計考慮因素,以及應對 Amazon Bedrock AgentCore 的 SaaS 架構挑戰所需的框架。
示例程式碼可在 GitHub 倉庫獲取:https://github.com/aws-samples/sample-agentcore-and-multitenancy-blog
解決方案概述
該解決方案演示瞭如何利用 Amazon Bedrock AgentCore 的原生能力,透過 AWS 託管服務實現完整的租戶隔離。架構實現了三級層次結構:層級 → 租戶 → 使用者,並透過知識庫中的文件、記憶、模型訪問和成本追蹤在每個層級實施隔離。層級策略是 SaaS 應用中的常見模式,租戶根據其需求(如基礎版和高階版)、使用模式或定價計劃被分組到不同的服務層級。每個層級定義了一組功能和可用服務質量,使 SaaS 提供商能夠以差異化的體驗服務多樣化的客戶群,同時保持運營效率。
醫療 AI 助手示例
為了展示實際應用,示例解決方案實現了兩個服務層級:
基礎版:面向小型診所,主要需要簡單的文件搜尋和檢索。由於這些任務適合較小且成本效益高的模型,該層級使用 Mistral Ministral 3 8B Instruct,在保持低成本的同時為簡單查詢提供準確結果。
高階版:面向需要複雜臨床分析的醫院和專科中心。該層級使用 OpenAI GPT OSS 120B,具有高階推理能力以實現準確的工具選擇,包括僅對高階版客戶可用的網路搜尋工具。
在每個層級內,解決方案使用池隔離模型,即租戶共享相同的基礎設施和計算資源,而不是每個租戶擁有專用的隔離資源。池模型最大化資源利用並簡化操作,同時透過邏輯分離機制(如作用域識別符號、訪問策略和資料分割槽)實施租戶隔離。將層級策略與池模型相結合,可以在成本效率和提供差異化服務級別之間取得平衡。
架構
以下是如何利用 AgentCore 的原生能力解決這些多租戶挑戰。架構圖展示了請求如何從經過身份驗證的使用者流經特定層級的智慧體到達隔離的文件儲存。
該解決方案包括以下關鍵元件:
- Amazon Cognito:管理使用者身份驗證,並將租戶後設資料(層級、診所 ID、角色)儲存在 JWT 宣告中。這些宣告被提取並作為租戶上下文透過請求負載傳播,使每個下游元件能夠將其操作範圍限定到正確的租戶。
- Amazon API Gateway:路由請求並透過使用計劃實施基於層級的速率限制。
- AWS Lambda:提取租戶上下文並呼叫對應的 Amazon Bedrock AgentCore 智慧體。
- AgentCore 元件:執行時(智慧體執行)、記憶(對話狀態)、身份(智慧體身份管理)、閘道器(工具伺服器)和策略(智慧體操作邊界)。
- Amazon S3:在按層級分隔的儲存桶中儲存臨床文件,並使用分層字首結構實現租戶隔離。
- Amazon Bedrock Knowledge Bases:提供語義搜尋,並透過後設資料過濾將查詢範圍限定到請求租戶的文件。
- Amazon Bedrock project:透過成本分配標籤實現每個層級的成本追蹤。
解決方案詳解
本節描述解決方案的關鍵方面。您需要執行部署指令碼來設定基礎設施和應用程式。本文中的程式碼片段僅用於描述架構關鍵方面如何被解決方案元件處理,無需執行任何命令。
Amazon Bedrock AgentCore 元件
架構利用六個核心 Bedrock AgentCore 能力實現多租戶:
AgentCore Runtime:為解決方案中的智慧體提供計算,每個智慧體會話在隔離的微虛擬機器中執行,實現租戶級計算隔離。每個層級託管獨立的智慧體例項,配置適合該層級的模型和能力。
AgentCore Identity:透過統一的基於 JWT 的身份驗證模型保護多租戶架構。Cognito ID 令牌在執行時和閘道器邊界驗證使用者,而工具 Lambda 為下游資料訪問生成自己的作用域憑證。
AgentCore Memory:會話歷史不能在租戶之間或同一租戶的不同使用者之間洩露。解決方案在應用層和基於 IAM 的屬性訪問控制(ABAC)層實施記憶隔離。應用層使用複合 actor_id 的分層名稱空間結構組織每個租戶的對話資料。
AgentCore Gateway:透過模型上下文協議(MCP)將靜態 Lambda 函式轉換為動態、上下文感知的智慧體工具。MCP 是連線 AI 智慧體到外部工具的開源標準。
每個執行時配置了入站 JWT 授權器,在智慧體程式碼執行前驗證 Cognito ID 令牌。ID 令牌攜帶租戶後設資料作為自定義宣告,例如 sub(使用者唯一識別符號)、iss(令牌頒發者)、aud(Web 客戶端 ID)、token_use(令牌型別)、cognito:username(登入使用者名稱,用於記憶隔離)、custom:tier(層級)、custom:clinic_id(租戶 ID)和 custom:role(角色)。
閘道器也配置了 JWT 授權,使用相同的 Cognito 發現 URL 和受眾。當智慧體呼叫閘道器時,它將使用者的原始 JWT 作為 Bearer 令牌轉發,並附上租戶上下文頭。閘道器驗證令牌後,將租戶頭傳播到目標 Lambda。
目標 Lambda 從不直接接收或處理使用者的 JWT。相反,它讀取受信任的租戶頭,並假設一個 TVM(令牌自動售貨機)角色,其會話標籤源自這些頭。TVM 角色的 ABAC 策略使用 dynamodb:LeadingKeys 條件限制 DynamoDB 訪問,確保每個租戶只能在 IAM 級別查詢自己的診所資料,而不僅僅是應用層過濾。
電視機制:執行時,智慧體假設一個 TVM 角色,其 Tier、ClinicId 和 UserId 作為會話標籤,接收限定到該租戶名稱空間的臨時憑證。TVM 角色的信任策略確保只有智慧體執行角色可以假設它,並且所有三個會話標籤都存在。
透過這種組合,解決方案在不犧牲安全性的前提下實現了池模型多租戶的靈活性和效率。