用电商场景打个比方：你把门店安保升级成双重门禁，结果快递员送货时因为没有门禁卡，连门都敲不开。用AWS WAF保护Amazon Bedrock AgentCore的API端点时，你大概率会撞上完全相同的尴尬——Application Load Balancer（ALB）的健康检查请求不带任何认证信息，而AgentCore Runtime偏偏要求每个请求都必须带着SigV4签名或OAuth令牌。默认情况下，健康检查请求直接返回失败，整个端点被标记为不可用。

正是这个看似不起眼的机制冲突，让很多人第一次配WAF就翻车。好在，有两条已经被验证过的路可以走通。两类方案都基于“互联网入口→ALB→VPC Interface Endpoint→AgentCore”这条链路，区别只在于中间要不要塞一个Lambda函数做请求改造。

打开网易新闻 查看精彩图片

先说AWS WAF集成点选择的门道。AgentCore既然已经内置SigV4和OAuth处理，再叠一层API Gateway就等于搞出“双重认证”，平添一次请求改造。CloudFront缓存能力在实时Agent调用场景里完全用不上。于是，**互联网入口的ALB顺势成了最干净的中间件**——它能把请求头原样透传，支持VPC内部路由，又能直接挂载WAF的WebACL。

但ALB的体检机制天生与认证系统八字不合。标准健康检查只发起一个普通的HTTPS请求，不附加任何签名或令牌，在AgentCore的视角里就是一个未授权的闯入，当场拒绝。想要让健康检查正常跑通，同时又不干扰受保护的生产流量，目前有两条务实拆解路径：

模式一：Lambda代理，请求自己改。在ALB和VPC Endpoint之间插一个Lambda函数。它等于是个智能接线员，看到健康检查来了，就构造一个不带业务含义但符合格式的响应直接返回；看到正常业务请求，就做一遍头改造或透传，再发给AgentCore。优点是把认证黑盒完全黑进Lambda里，ALB无需感知任何认证细节，策略灵活度极高。

模式二：直连ENI IP，省掉中间商。ALB直接向VPC Endpoint的弹性网卡IP地址发起流量，把Lambda这一跳砍掉。这需要你在目标组里手动铺好这些动态IP，同时用AgentCore的资源策略做一把锁——只允许来自ALB所在VPC端点的流量进场，直接访问后门彻底堵死，确保所有请求都必须先过WAF这一关。省链路、延迟更低，但对IP管理有额外要求。

两套方案都已经用SigV4和OAuth（基于Amazon Cognito的JWT）跑通端到端验证。无论选哪种，最终效果都一样：互联网侧的攻击面被WAF的SQL注入防护、XSS过滤、速率限制和机器人管理规则死死挡住，而ALB的健康检查也终于学会“敲门”了。