使用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，防止直接访问后门。