使用 AWS WAF 保护 Amazon Bedrock AgentCore Runtime 的两种架构模式
问题背景
当您将生成式 AI 代理通过 Amazon Bedrock AgentCore 部署为生产级 API 端点时，通常需要借助 AWS WAF 实施 Web 应用防火墙策略、速率限制、常见 Web 威胁防护或审计控制。然而，AWS WAF 原生集成的服务（如 ALB、CloudFront、API Gateway）均存在各自的局限性：
- CloudFront 适用于缓存和内容分发，但代理调用是实时动态的，缓存不适用。
- API Gateway 会引入额外的认证和请求转换层，与 AgentCore 内置的 SigV4 和 OAuth 处理形成“双重认证”问题。
因此，面向公网的 ALB 成为最佳集成点：它透明传递请求头、支持 VPC 内部路由，并能直接挂载 AWS WAF WebACL。
核心挑战
ALB 需要对后端目标执行健康检查，但 AgentCore Runtime 要求所有 API 调用（包括健康检查请求）都必须通过 SigV4 或 OAuth 认证。标准 ALB 健康检查发送的是未认证请求，因此会直接失败。
两种架构模式
该文章提出了两种经过端到端测试的架构模式，均使用面向公网的 ALB + AWS WAF，并通过 VPC Interface Endpoint 将流量路由至 AgentCore Runtime。两种模式均支持 SigV4 和 OAuth（Amazon Cognito JWT）认证。
模式 1：Lambda 代理模式
在 ALB 与 VPC Endpoint 之间插入 AWS Lambda 代理。Lambda 函数可以完全控制请求转换，包括处理健康检查逻辑——例如对健康检查路径返回固定响应，或对生产请求进行签名转发。这种模式赋予您最大的灵活性，但会引入额外的延迟和运维复杂度。
模式 2：直接路由模式
ALB 直接指向 VPC Endpoint 的 ENI IP 地址，完全移除 Lambda 跳转。该模式更简单、延迟更低，但需要确保健康检查能够绕过认证。文章通过资源策略关闭直接访问后门，强制所有流量必须经过 AWS WAF 检查。
安全加固要点
两种模式都需要配置 VPC Endpoint 资源策略，拒绝来自非 ALB 来源的流量，从而防止客户端绕过 WAF 直接访问 AgentCore。这确保了 WAF 策略的强制实施。
总结
对于希望在生产环境中安全暴露 Bedrock AgentCore API 的用户，这两种模式提供了明确的路径：
- 模式 1 适合需要自定义请求转换或复杂健康检查逻辑的场景。
- 模式 2 适合追求低延迟、简单架构的场景。
无论选择哪种模式，都能在保持 AgentCore 原生认证能力的同时，叠加 AWS WAF 的安全层。