背景：隔离数据与 AI 代理的连通困境

许多敏感数据（如医疗记录、金融数据）存放在无互联网连接的私有 Amazon VPC 中。传统网络互联方案在连接 AI 代理与这些隔离数据时，往往需要在连通性与隔离性之间妥协。

传统方案的局限

  • VPC Peering：使对等网络整体互通，违背最小权限原则。
  • Transit Gateway：需复杂路由配置，缺乏应用层身份认证。
  • PrivateLink：一对一模型，每个消费 VPC 需独立端点，数据源增多后难以管理。

VPC Lattice 的零信任连接模型

Amazon VPC Lattice 支持一对多、多对多服务网络，无需按消费者配置。默认配额每服务网络可关联 500 个 VPC（可通过 Service Quotas 调整）。它不依赖 IP 路由，而是定义逻辑服务，由 Lattice 处理连通、认证与加密。

典型医疗场景架构

示例中，账户 A 托管临床 AI 代理（基于 Amazon EKS、Strands Agents 与 Bedrock），账户 B 托管无互联网网关的 EHR FHIR API（后端为 Aurora PostgreSQL）。流程如下：

  1. 医生提问，代理调用 Bedrock 推理（经 PrivateLink 的 VPC 端点）。
  2. 代理调用同集群的 MCP 服务器，该服务使用 Pod IAM 角色对请求进行 SigV4 签名。
  3. 签名请求发送至 VPC Lattice 服务端点，Lattice 校验签名与鉴权策略，TLS 加密后路由至账户 B 的 FHIR API 目标。
  4. 访问日志（含主体、时间戳、HTTP 状态、字节数）投递至 CloudWatch 或 S3 满足审计留存。

核心安全能力

零信任 IAM 认证

每个到 FHIR API 的请求必须携带有效 IAM 凭证，鉴权策略精确限定主体（如 MCP 服务器的 EKS Pod 角色）。即使网络可达，无匹配 Allow 语句也会被阻断。未签名的请求无论网络策略均返回 403。

网络层 HTTP 方法限制

VPC Lattice 可在网络层强制限制代理可使用的 HTTP 方法，例如将只读代理限制为 GET，阻断 POST/PUT/DELETE 到达后端。

自动 TLS 与跨账户共享

使用 Lattice 生成域名时自动配置 TLS 证书；自定义域名可通过 ACM 提供。借助 AWS RAM 将账户 B 的服务共享至账户 A，后者 VPC 关联服务网络后即通过 DNS 名称发现调用，无需对等连接。

与 PrivateLink 的分工

PrivateLink 解决 VPC 到服务端点（如 Bedrock）的私有连接；VPC Lattice 解决跨 VPC/账户的服务到服务连接，提供 IAM 认证、服务发现与集中策略，且无需每数据源部署 NLB。

对读者的意义与技术解读

对于运维与 SRE 团队，该模式降低了合规环境下 AI 数据管线的网络攻击面。传统打通隔离 VPC 的方式易产生横向移动风险，而 VPC Lattice 以应用层身份为中心，使“零信任”在云内网络落地。结合 SigV4 与访问日志，可实现基于身份的细粒度审计，契合 HIPAA 等要求。在混合多云或跨账户 AI 平台中，此架构可复用于金融、政府等受监管行业，但生产部署前仍需独立安全验证。