OpenClaw 部署安全第一步：用 VPC Endpoint 让 AI Agent 调用 Bedrock 全走内网
上周排查一个延迟问题时发现了一个让我不太舒服的事：我的 OpenClaw（龙虾）Agent 调用 Amazon Bedrock 的请求，全部走的公网。OpenClaw 的 Skills 每次执行都会调大模型，这些流量全经过公网，安全隐患不小。
虽然请求是 HTTPS 加密的，但流量从 EC2 出去走公网、到 Bedrock 的 endpoint、再回来——中间经过了公共互联网。在企业安全审计的视角，这是个风险点：流量路径不可控，而且如果有人做中间人攻击（虽然概率很低），数据有暴露的可能。
更关键的是，如果你的 OpenClaw AI Agent 处理的是公司内部数据（比如用 Skills 对接 RAG 做知识库问答），大模型调用数据出公网这件事本身在合规上就可能过不去。
好消息是，亚马逊云科技的 VPC Endpoint（PrivateLink）可以完美解决这个云安全问题——让 EC2 到 Bedrock 的所有流量走 VPC 内网，完全不经过公网。
折腾了一下午配好了，记录完整过程。
先理解问题：默认流量怎么走的
默认情况下，EC2 调用 Bedrock API 的流量路径是这样的：
EC2 → NAT Gateway → Internet Gateway → 公网 → Bedrock Endpoint或者如果你的 EC2 有公网 IP：
EC2 → Internet Gateway → 公网 → Bedrock Endpoint问题出在"公网"这一段。流量离开了你的 VPC，经过了亚马逊的公共网络骨干。虽然 TLS 加密保护了数据内容，但：
- 流量路径不可控
- 多了 NAT Gateway 的费用（数据处理费 $0.045/GB）
- 延迟多了几毫秒（不多但有感知）
- 合规审计时是个减分项
VPC Endpoint 怎么解决
配了 VPC Endpoint 之后，流量路径变成：
EC2 → VPC Endpoint（ENI）→ PrivateLink → Bedrock全程在亚马逊云科技的内部网络里走，不经过公网。VPC Endpoint 在你的子网里创建一个 ENI（弹性网络接口），流量直接从这个 ENI 走 PrivateLink 到 Bedrock。
动手配置
Step 1：创建 Bedrock VPC Endpoint
Amazon Bedrock 有 5 个 endpoint 后缀，按需创建：
| 服务 | Endpoint 后缀 | 用途 |
|---|---|---|
| 控制面 API | bedrock | 管理模型、Guardrails 等 |
| 运行时 API | bedrock-runtime | InvokeModel、Converse 调用 |
| Mantle API | bedrock-mantle | 推理相关 |
| Agents 构建 | bedrock-agent | Agent 定义、Knowledge Base 配置 |
| Agents 运行时 | bedrock-agent-runtime | Agent 运行时调用 |
日常跑 OpenClaw 龙虾只需要bedrock-runtime（Skills 调大模型），如果用了 Knowledge Base 还需要bedrock-agent-runtime。
用 AWS CLI 创建：
# 创建 Bedrock Runtime VPC Endpointaws ec2 create-vpc-endpoint\--vpc-id vpc-xxxxxxxx\--service-name com.amazonaws.us-west-2.bedrock-runtime\--vpc-endpoint-type Interface\--subnet-ids subnet-aaaa subnet-bbbb\--security-group-ids sg-xxxxxxxx\--private-dns-enabled关键参数：
--vpc-endpoint-type Interface：接口类型端点（PrivateLink）--subnet-ids：选你 EC2 所在的子网--private-dns-enabled：开启私有 DNS，这样bedrock-runtime.us-west-2.amazonaws.com会自动解析到内网地址
Step 2：安全组配置
VPC Endpoint 的安全组需要允许 EC2 的入站流量：
# 创建专用安全组aws ec2 create-security-group\--group-name bedrock-vpce-sg\--description"Security group for Bedrock VPC Endpoint"\--vpc-id vpc-xxxxxxxx# 允许 VPC 内部 HTTPS 流量aws ec2 authorize-security-group-ingress\--group-id sg-vpce-xxxxx\--protocoltcp\--port443\--cidr10.0.0.0/16这里10.0.0.0/16是你 VPC 的 CIDR，意思是 VPC 内所有实例都能访问这个 Endpoint。生产环境可以收紧到 EC2 所在子网的 CIDR。
Step 3：Endpoint Policy（可选但推荐）
默认的 Endpoint Policy 允许所有操作。生产环境建议收紧：
{"Version":"2012-10-17","Statement":[{"Principal":{"AWS":"arn:aws:iam::123456789012:role/openclaw-instance-role"},"Effect":"Allow","Action":["bedrock:InvokeModel","bedrock:InvokeModelWithResponseStream"],"Resource":"arn:aws:bedrock:us-west-2::foundation-model/*"}]}这样只有指定的 IAM Role 能通过这个 Endpoint 调用 Bedrock，而且只允许 InvokeModel 操作。双重保险。
Step 4：验证流量走内网
开了--private-dns-enabled之后，不需要改任何代码。验证：
# 检查 DNS 解析nslookupbedrock-runtime.us-west-2.amazonaws.com# 应该返回 VPC 内网 IP（10.x.x.x），不是公网 IP如果返回的是 10.x.x.x 的内网地址，说明流量已经走 VPC Endpoint 了。
VPC 网络架构
配 VPC Endpoint 的同时，顺带说一下 AI Agent 服务器的网络架构。
推荐的架构：
VPC (10.0.0.0/16) ├── 公有子网 (10.0.1.0/24) │ └── NAT Gateway（给私有子网提供出网能力） ├── 私有子网 (10.0.2.0/24) │ ├── EC2（OpenClaw）— 无公网 IP │ └── VPC Endpoint ENI（Bedrock Runtime） └── 安全组 ├── EC2 SG：入站仅允许你的 IP SSH（22） └── VPCE SG：入站允许 VPC CIDR 的 443EC2 放在私有子网，没有公网 IP，SSH 通过 EC2 Instance Connect Endpoint（EICE）或 Systems Manager Session Manager 连接。Bedrock 调用走 VPC Endpoint。如果 Agent 需要访问外部网站（比如爬网页、调第三方 API），通过 NAT Gateway 出去。
还需要哪些 VPC Endpoint？
除了 Bedrock，OpenClaw 龙虾的 Skills 运行时可能还需要这些 Endpoint：
| 服务 | Endpoint 后缀 | 什么时候需要 |
|---|---|---|
| S3 | s3（Gateway 类型，免费） | 用了 S3 存储/知识库 |
| CloudWatch Logs | logs | 推日志到 CloudWatch |
| Secrets Manager | secretsmanager | OpenClaw SecretRef 读密钥 |
| STS | sts | IAM Role 认证 |
| EC2 Messages | ec2messages | Systems Manager 连接 |
| SSM | ssm | Systems Manager |
S3 的 Gateway Endpoint 是免费的，建议无脑开。其他的 Interface Endpoint 按需开，每个约 $0.01/小时/AZ。
成本对比
| 项目 | 走公网（NAT） | 走 VPC Endpoint |
|---|---|---|
| 数据处理费 | $0.045/GB（NAT） | $0.01/GB（Endpoint） |
| 固定费 | $0.045/小时（NAT） | $0.01/小时/AZ（Endpoint） |
| 延迟 | 多几ms | 内网直连 |
| 安全性 | 流量过公网 | 全程内网 |
如果你的 OpenClaw AI Agent 每天通过 Skills 调几百次 Bedrock 大模型，流量不大，成本差异不明显。但如果是 RAG 场景大量读写 S3 + 频繁调用大模型，VPC Endpoint 省的钱会很可观——特别是 S3 Gateway Endpoint 完全免费。
踩坑记录
坑 1：Private DNS 需要 VPC 开启 DNS 支持
--private-dns-enabled生效的前提是 VPC 的enableDnsSupport和enableDnsHostnames都是 true。如果你的 VPC 是手动创建的，可能默认没开：
aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-support'{"Value": true}'aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-hostnames'{"Value": true}'坑 2：安全组忘了开 443
VPC Endpoint 的安全组入站如果没开 443，请求会超时。报错信息不明显，看起来像 DNS 问题，实际是安全组拦了。
坑 3：多 AZ 建议都配上
Endpoint 只在你选的子网/AZ 里有 ENI。如果 EC2 和 Endpoint 不在同一个 AZ，流量会跨 AZ（多一点延迟和费用）。建议在 EC2 所在的 AZ 都配上。
总结
VPC Endpoint 不复杂但很重要，特别是跑 OpenClaw 龙虾这种 AI Agent 场景：
- 云安全：大模型 Bedrock 调用全走内网，合规审计放心
- 省钱：避免 NAT Gateway 的数据处理费
- 快：内网直连，Skills 执行延迟更低
对于跑 OpenClaw AI Agent 的 EC2，我的建议是至少配bedrock-runtime和s3两个 Endpoint。S3 是免费的，Bedrock Runtime 每月不到 $8（单 AZ）。
如果你的 OpenClaw Agent 处理的是内部数据，VPC Endpoint 不是"建议配"，是"必须配"。
下一篇聊聊怎么用 Secrets Manager 管理 OpenClaw AI Agent 的密钥——加密存储、自动轮转、审计日志一步到位。
以上配置在亚马逊云科技 EC2（us-west-2）上验证通过。
