使用AWS WAF保護Amazon Bedrock AgentCore運行時

當您將生成式AI代理與Amazon Bedrock AgentCore作為生產API端點部署時，可能需要通過AWS WAF強制實施Web應用防火牆策略、速率限制、防護常見Web威脅或審計控制。

AWS WAF可與Elastic Load Balancing Application Load Balancers（ALB）、Amazon CloudFront分配和Amazon API Gateway REST API集成。Amazon CloudFront專為緩存和內容交付設計，而代理調用是實時動態的，緩存不適用。Amazon API Gateway添加了自身的身份驗證和請求轉換層，可能與AgentCore內置的SigV4和OAuth處理產生雙重身份驗證問題。因此，互聯網-facing的ALB成為集成點：它透明地傳遞標頭，支持VPC內部路由，並可直接附加AWS WAF WebACL。然後，您通過VPC接口端點將流量路由至AgentCore數據平面服務的VPC端點。

挑戰在於：ALB需要健康檢查來驗證後端目標是否響應，但AgentCore運行時要求API調用（包括健康檢查請求）進行SigV4或OAuth身份驗證。標準ALB健康檢查發送未經身份驗證的請求，因此默認會失敗。您需要一種方法，使得健康檢查無需憑據即可工作，同時將經過身份驗證的生產流量傳遞至AgentCore。

本文介紹了兩種解決此問題的架構模式。兩者均使用互聯網-facing的ALB與AWS WAF，並通過VPC接口端點路由流量至AgentCore運行時。模式1在ALB和VPC端點之間放置AWS Lambda代理，提供對請求轉換的完全控制。模式2直接針對VPC端點的ENI IP地址，完全移除Lambda跳轉。您還將學習如何通過資源策略關閉直接訪問後門，確保流量僅通過AWS WAF。兩種模式均已使用SigV4和OAuth（Amazon Cognito JWT）認證進行端到端測試。

架構概述

兩種模式共享共同基礎：客户端應用程序發送經過身份驗證的請求（SigV4簽名或OAuth Bearer令牌）至互聯網-facing的ALB。AWS WAF在ALB將請求轉發至VPC端點ENI（HTTPS端口443）之前進行檢查。AgentCore驗證身份驗證並將請求路由至運行容器的內部端口8080。模式之間的差異在於ALB和VPC端點之間的組件。

架構包含四個組件：

• AWS WAF：附加到ALB，提供速率限制、SQL注入防護、XSS過濾和機器人控制。
• ALB：互聯網-facing，HTTPS監聽器監聽端口443，將流量路由至VPC端點ENI IP目標。
• VPC接口端點：通過PrivateLink提供到AgentCore的私有連接。
• AgentCore運行時：託管代理代碼的容器，監聽內部端口8080，支持SigV4和OAuth身份驗證。

注意：請使用com.amazonaws..bedrock-agentcore（數據平面）進行運行時調用。有三個不同的端點服務：bedrock-agentcore（數據平面，用於運行時、內存、工具）、bedrock-agentcore-control（控制平面）和bedrock-agentcore.gateway（僅網關）。使用錯誤端點將無法路由到您的運行時。

先決條件

• AWS賬户，已啓用Amazon Bedrock AgentCore。
• 已部署AgentCore運行時（公共或VPC模式）。
• 跨至少兩個可用區的VPC，包含公有和私有子網。
• 同一區域的AWS Certificate Manager證書，用於ALB的HTTPS監聽器。
• Amazon Cognito用户池（用於OAuth模式）或AWS憑證（用於SigV4模式）。
• 熟悉ALB、VPC端點和AWS WAF。

以下部分描述兩種將AWS WAF與AgentCore集成的模式。如果需要請求轉換、自定義日誌記錄或ALB與AgentCore之間的身份驗證轉換，請從模式1開始。如果希望架構最簡單且延遲最低，無需額外組件，請跳至模式2。

模式1：ALB與Lambda代理

在此模式中，Lambda函數位於ALB之後，將請求（包括身份驗證標頭）轉發至AgentCore的VPC端點。Lambda函數提供了一個計算層，您可以在其中轉換請求、在身份驗證方法之間進行轉換或在請求到達AgentCore之前添加自定義日誌記錄。

選擇模式1的條件：

• 需要請求轉換、標頭操作、有效負載更改或協議轉換。
• 需要代理層的自定義日誌記錄或審計跟蹤。
• 需要在多種身份驗證方法之間進行轉換。
• 需要在ALB和後端之間有一個顯式計算層（某些安全策略要求）。

創建VPC端點：在私有子網中為AgentCore數據平面服務創建VPC接口端點。

配置VPC端點安全組：允許僅來自ALB安全組的入站HTTPS（端口443）。

創建Lambda代理：Lambda函數接收來自ALB的請求並轉發至AgentCore的VPC端點。對於OAuth，它原樣傳遞Authorization標頭（Bearer令牌）以及原始請求路徑和主體，使JWT按原樣到達AgentCore。對於SigV4，簽名綁定到原始請求主機，在請求轉發至VPC端點後失效，因此代理使用其執行角色憑證重新簽名請求。

配置ALB與Lambda目標組：創建Lambda目標組，註冊代理函數，並在ALB上創建HTTPS監聽器。ALB處理TLS終止並將解密請求轉發至Lambda函數。

附加AWS WAF：將AWS WAF WebACL與ALB關聯。典型的起始配置包括AWSManagedRulesCommonRuleSet（防護常見Web威脅）、基於速率的規則（限制每個源IP的請求數）以及AWSManagedRulesBotControlRuleSet（如果代理暴露給基於瀏覽器的客户端）。

模式1權衡：

• 延遲：每個請求增加50-200毫秒（Lambda冷啓動）。可通過預留併發緩解。
• 成本：每次請求的Lambda調用成本。
• 複雜性：需要部署、監控和維護的額外組件。
• 靈活性：完全控制請求/響應轉換和自定義日誌記錄。

模式2：ALB直接到VPC端點

在此模式中，ALB直接針對VPC端點的ENI IP地址（HTTPS端口443）。沒有Lambda函數或Network Load Balancer。ALB透明地將身份驗證標頭傳遞至AgentCore。此架構組件更少，移除了Lambda代理跳轉。

選擇模式2的條件：

• 希望架構更簡單，組件更少。
• 不需要ALB和AgentCore之間的請求轉換。
• 需要最小延遲，無需額外跳轉。
• 客户端應用程序直接處理SigV4或OAuth簽名。

創建VPC端點：與模式1步驟1相同。

檢索VPC端點ENI IP地址：獲取VPC端點創建的ENI的私有IP地址。這些IP將成為ALB目標組的目標。

創建IP目標組並配置健康檢查：創建IP類型的目標組，HTTPS端口443，健康檢查路徑為"/"，匹配器為200-499。注意：AgentCore在"/"上返回404，但ALB接受200-499範圍內的響應作為健康。因為目標是驗證VPC端點是否響應，狀態碼無關緊要。健康檢查不使用身份驗證。

註冊目標並創建ALB監聽器：將VPC端點ENI IP註冊到目標組。在ALB上創建HTTPS監聽器，將流量路由到該目標組並附加AWS WAF WebACL。

使用資源策略關閉後門：更新VPC端點的資源策略，只允許來自ALB安全組的流量，從而阻止直接訪問。

模式2權衡：

• 延遲：最低，無額外跳轉。
• 成本：僅ALB和VPC端點費用，無Lambda費用。
• 複雜性：較低，組件更少。
• 靈活性：無請求轉換能力。

總結

兩種模式均使您能夠通過AWS WAF保護AgentCore運行時。模式1提供靈活性但增加延遲；模式2提供低延遲但少靈活性。通過資源策略確保流量僅通過AWS WAF，防止直接訪問後門。