用 AWS WAF 为 Amazon Bedrock AgentCore Runtime 加上生产级防护

在生产环境部署基于 Amazon Bedrock AgentCore 的生成式 AI 代理时，企业通常希望叠加 AWS WAF 的 Web 防护、速率限制和审计能力。CloudFront 适合静态内容缓存，无法应对实时动态的代理调用；API Gateway 会引入自有认证层，与 AgentCore 内置的 SigV4、OAuth 处理形成双重认证，因此最终选定面向公网的 ALB 作为 WAF 接入点，再经 VPC 接口端点 PrivateLink 进入 AgentCore 数据面。

整个链路的核心矛盾在于健康检查：ALB 必须对后端做无凭证探测，而 AgentCore Runtime 在包括健康检查在内的所有 API 调用上都强制要求 SigV4 或 OAuth 认证。标准 ALB 健康检查会因缺少凭证而失败，文章围绕如何在不影响认证的前提下让健康检查通过，给出两种工程化方案。

方案一在 ALB 与 VPC 接口端点之间插入 Lambda 代理。ALB 接收经过 WAF 过滤的请求后，把流量交给 Lambda，由 Lambda 转发到 VPC 端点的 ENI。该层可承担请求改写、协议转换、多认证翻译和自定义审计日志等职责。对于 OAuth 场景，Lambda 原样透传 Bearer 令牌；对于 SigV4 场景，由于签名绑定原始主机头，Lambda 会用自身执行角色重新签名后再转发。

方案二追求最低延迟与最少组件，直接让 ALB 把目标指向 VPC 接口端点的 ENI IP 地址，从而完全省掉 Lambda 中转。两套方案共享同一套前置条件：启用 AgentCore 的 AWS 账户、已部署的 Runtime、跨多可用区的 VPC、ACM 证书，以及 Cognito 用户池或 IAM 凭据。文章还详细列出 VPC 端点创建命令与安全组规则，要求只允许来自 ALB 安全组的 443 入站流量。

为防止调用方绕过 ALB 直连 VPC 端点形成后门，文章强调要在 AgentCore Runtime 上配置资源策略，仅放行来自该 VPC 端点的流量，确保所有请求都必须经过 WAF 检查。整个架构经过 SigV4 与 Amazon Cognito JWT 两种认证方式的端到端验证，文章最后提醒开发者注意三类端点服务——bedrock-agentcore 数据面、bedrock-agentcore-control 控制面以及 bedrock-agentcore.gateway——不要错配服务名，否则请求无法路由到 Runtime。

要点

• 面向公网的 ALB 是把 AWS WAF 接入 AgentCore Runtime 的首选位置，可避开 CloudFront 缓存与 API Gateway 双重认证的限制。
• ALB 的无凭证健康检查与 AgentCore 强制认证之间存在天然冲突，必须通过架构设计或资源策略加以解决。
• 方案一借助 Lambda 代理支持请求转换、日志审计和认证翻译，适合需要定制处理的安全合规场景。
• 方案二让 ALB 直接打到 VPC 端点 ENI IP，结构最简单、延迟最低，适合追求轻量部署的团队。
• 必须在 AgentCore Runtime 上配置资源策略，仅放行来自指定 VPC 端点的流量，避免绕过 WAF 的直连后门。