使用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，防止直接訪問後門。