用 AWS WAF 守住 Amazon Bedrock AgentCore Runtime 的入口

2026-07-08 34 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：9 分钟

Amazon Bedrock AgentCore Runtime 作为托管运行时，真正上线时绕不开一个问题：公网请求怎样进来，安全控制又怎样不被绕过？这篇方案的核心变化很明确：把入口收束到 internet-facing ALB，并在 ALB 前挂 AWS WAF，再通过 VPC Interface Endpoint 把流量送到 AgentCore Runtime。这样 WAF 负责公网防护，VPC Endpoint 负责私有连通，资源策略负责堵住直连后门。

两条路径：Lambda 代理，或者直接打到 Endpoint ENI

第一种架构是在 ALB 和 VPC Interface Endpoint 之间放一个 AWS Lambda proxy。ALB 接收公网请求，AWS WAF 做规则检查，Lambda 再把请求转换、签名或补齐运行时需要的格式，然后转发到 AgentCore Runtime 的 VPC Endpoint。

这条路的优势是控制力强。你可以在 Lambda 里统一做 header 归一化、body 改写、租户字段注入、审计日志、错误响应包装，甚至根据业务规则决定是否转发。代价也清楚：多一次 Lambda 调用，多一个运行时组件，也多了冷启动、超时、并发和可观测性的维护成本。

第二种架构更短：ALB 的 target group 直接指向 VPC Endpoint 的 ENI 私有 IP。请求经过 WAF 和 ALB 后，不再进入 Lambda，而是直接转到接口端点。

这条路少了 Lambda hop，延迟和运维面都更小。但它要求你接受较少的请求变形能力，并且要处理 VPC Endpoint ENI IP 可能变化的问题。实际落地时，通常需要脚本或自动化任务刷新 ALB target group 中的 IP target。

真正的安全边界：不要只相信网络路径

仅仅把 WAF 放在 ALB 前面还不够。关键风险是“直连后门”：如果调用方能绕过 ALB，直接访问 AgentCore Runtime 或它的端点，那么 WAF 规则就形同虚设。

所以方案里还有一个重要动作：用资源策略限制 AgentCore Runtime 的访问来源，让有效流量只能从预期路径进入。来源摘要明确提到，两种模式都通过 resource policy 关闭 direct-access backdoor，使流量只能经过 AWS WAF。

认证层也不是二选一。方案已经用 SigV4 和 OAuth，也就是 Amazon Cognito JWT，做过端到端测试。实践上可以这样分工：

  • SigV4 更适合 AWS 内部工作负载、后端服务和需要 IAM 细粒度授权的调用方。
  • Cognito JWT 更适合用户态、Web/API 客户端、移动端或已有 OAuth 登录链路的系统。
  • WAF 不替代身份认证，它负责过滤明显恶意或不合规的公网请求；身份系统负责证明“你是谁、能做什么”。

可以这样实践：把 VPC Endpoint ENI 注册到 ALB Target Group

下面示例演示第二种模式的一个常见自动化动作：查询 Interface Endpoint 关联的 ENI 私有 IP，并注册到 ALB target group。运行前需要替换 VPCE_ID、TARGET_GROUP_ARN 和 REGION。

#!/usr/bin/env bash
set -euo pipefail

REGION=us-east-1
VPCE_ID=vpce-0123456789abcdef0
TARGET_GROUP_ARN=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/agentcore-vpce-tg/abc123
PORT=443

ENI_IDS=$(aws ec2 describe-vpc-endpoints \
  --region "$REGION" \
  --vpc-endpoint-ids "$VPCE_ID" \
  --query 'VpcEndpoints[0].NetworkInterfaceIds[]' \
  --output text)

IPS=$(aws ec2 describe-network-interfaces \
  --region "$REGION" \
  --network-interface-ids $ENI_IDS \
  --query 'NetworkInterfaces[].PrivateIpAddress' \
  --output text)

for ip in $IPS; do
  echo "Registering $ip:$PORT"
  aws elbv2 register-targets \
    --region "$REGION" \
    --target-group-arn "$TARGET_GROUP_ARN" \
    --targets Id="$ip",Port="$PORT"
done

这个脚本可以放进部署流水线，也可以由 EventBridge 定时触发的 Lambda 执行。生产环境还需要处理“旧 IP 下线”的情况：先读取当前 target group 里的 IP，再和最新 ENI IP 做 diff，注册新增目标并注销不存在的目标。

可以这样实践：给 WAF 加一层基础规则

WAF 规则应当贴近你的流量模型。下面是一个可改造的 AWS CloudFormation 片段，表达的是最基础的思路：启用 AWS Managed Rules，并额外限制请求体大小。部署前需要把 ResourceArn 替换成你的 ALB ARN。

AWSTemplateFormatVersion: '2010-09-09'
Description: WAF WebACL for an internet-facing ALB in front of AgentCore Runtime

Resources:
  AgentCoreWebAcl:
    Type: AWS::WAFv2::WebACL
    Properties:
      Name: agentcore-runtime-web-acl
      Scope: REGIONAL
      DefaultAction:
        Allow: {}
      VisibilityConfig:
        CloudWatchMetricsEnabled: true
        MetricName: agentcore-runtime-web-acl
        SampledRequestsEnabled: true
      Rules:
        - Name: AWSManagedCommonRuleSet
          Priority: 10
          OverrideAction:
            None: {}
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesCommonRuleSet
          VisibilityConfig:
            CloudWatchMetricsEnabled: true
            MetricName: common-rule-set
            SampledRequestsEnabled: true
        - Name: BlockLargeBodies
          Priority: 20
          Action:
            Block: {}
          Statement:
            SizeConstraintStatement:
              FieldToMatch:
                Body: {}
              ComparisonOperator: GT
              Size: 1048576
              TextTransformations:
                - Priority: 0
                  Type: NONE
          VisibilityConfig:
            CloudWatchMetricsEnabled: true
            MetricName: block-large-bodies
            SampledRequestsEnabled: true

  WebAclAssociation:
    Type: AWS::WAFv2::WebACLAssociation
    Properties:
      ResourceArn: arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/agentcore-alb/abc123
      WebACLArn: !GetAtt AgentCoreWebAcl.Arn

这不是完整安全基线，只是入口层的起点。上线前应继续加入 IP reputation、速率限制、路径白名单、Bot Control 或业务特定规则，并观察 sampled requests，避免误伤正常 agent 调用。

可以这样实践：用资源策略堵住绕行路径

资源策略的具体字段应以 AgentCore Runtime 支持的策略模型为准。下面是一个“伪项目级”示例，用来表达部署时应坚持的约束：只允许来自指定 VPC Endpoint 或指定 AWS 账号/角色的调用。请按你的服务实际 ARN、条件键和主体改写。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyExpectedPrivatePath",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/agentcore-alb-or-proxy-role"
      },
      "Action": "bedrock-agentcore:InvokeRuntime",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/example-runtime",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

重点不是照抄这段 JSON，而是建立一个验收条件：从公网直接调用运行时应失败；从 WAF、ALB、VPC Endpoint 这条路径调用才成功。这个验收测试要写进发布检查，而不是只靠架构图说明。

选型建议：什么时候保留 Lambda

如果你的请求需要明显的协议转换、复杂签名、body 改写、多租户路由或自定义审计，Lambda proxy 更稳。它把“边界适配层”显式放在代码里，问题容易定位。

如果你的请求格式已经稳定，目标是降低延迟、减少组件、简化故障面，ALB 直连 VPC Endpoint ENI 更干净。代价是要补上 IP target 同步、健康检查、证书和目标端口等运维细节。

上线前可以按这份清单过一遍：

  • ALB 是唯一公网入口，并已关联 AWS WAF。
  • VPC Interface Endpoint 能私有访问 AgentCore Runtime。
  • 资源策略已阻止绕过 WAF 的直接访问。
  • SigV4 或 Cognito JWT 的认证链路已做端到端验证。
  • WAF sampled requests、ALB access logs、Lambda logs 或 target health 都能被运维团队看到。
  • 已压测 Lambda proxy 或 ENI 直连路径的延迟、超时和错误码。

安全入口不是多放一个防火墙就结束了。更可靠的做法是把公网入口、私有网络路径、身份认证和资源策略拼成一条不可绕开的链路，然后用自动化测试证明这条链路确实生效。

# AI # AWS # LLM # 云平台 # 机器学习 # 架构设计

相关推荐