背景与需求

实时应用如聊天系统、直播仪表盘、协同工具等依赖 WebSocket 持久、低延迟、双向连接。当需跨多个 Amazon VPC 与账户安全路由此类连接时，服务发现、一致安全策略与跨账户连通变得复杂。Amazon VPC Lattice 作为全托管应用网络服务，虽未原生支持 WebSocket 协议，但可借助 TLS 监听器协议透传或资源网关路由实现承载。

两种技术路径对比

基于 TLS 监听器的服务

该方式将 VPC Lattice 服务配置为 TLS 透传监听器，加密流量转发至目标组中的健康实例（EC2、ECS 任务、EKS Pod 或由 IP 注册的 ALB），TLS 在消费者与应用间直接协商。Lambda 目标暂不支持。

  • 连接时长：最大 10 分钟，空闲超时可配置 60-600 秒。
  • 吞吐量：受服务配额限制，默认每可用区 10 Gbps 带宽、10,000 请求/秒。
  • 负载均衡：提供四层负载均衡，分发连接至健康目标。
  • 鉴权策略：服务网络级 auth policies 可用，但 TLS 监听器当前仅限匿名主体。

基于资源网关的配置

资源模式通过 resource gateway 将连接路由至单一目标（DNS 名称、IP 或 ARN），VPC Lattice 转发原始 TCP，TLS 由消费者与应用直接协商。

  • 连接时长：无强制上限（由应用控制），空闲超时 350 秒。
  • 吞吐量：无 VPC Lattice 层面限速。
  • 负载均衡：本身路由到单一目的地，需在应用前放置 ALB 或 NLB 实现负载均衡。
  • 鉴权策略：暂不支持 auth policies。

两种模式当前均不可调整上述连接时长与空闲超时数值。建议配置应用层 WebSocket Ping/Pong 帧维持空闲连接。

典型部署组件

无论东西向（AWS 内部 VPC 间）还是南北向（公网经入口 VPC 入 AWS）模式，基础组件包括：

  • 消费/入口 VPC：托管客户端或作为互联网入口，关联服务网络。
  • 提供方 VPC：部署 WebSocket 应用。
  • VPC Lattice 服务网络：定义服务集合与授权、可观测性边界。
  • 服务实例：TLS 终止于 443 端口，作为监听器目标。
  • Route 53 私有托管区：将自定义域名（如 app1.example.com）映射到 VPC Lattice 服务 FQDN。

文章建议采用多账户、多 VPC 架构以契合 AWS Well-Architected 框架，可通过资源共享实现。

流量模式简述

东西向指消费者 VPC 内客户端与提供方 VPC 内应用通信；南北向指公网客户端经集中入口 VPC 与互联网网关访问提供方 VPC 应用。两者均可使用 TLS 透传监听器，目标为终止 TLS 的实例。

对读者的意义 / 技术解读

对于运维与 SRE，VPC Lattice 降低了跨账户服务发现与网络策略统一管理难度，但引入了新的超时与配额约束。若业务需超过 10 分钟的长连接（如后台协作心跳），应优先选用资源网关模式，并自购 ALB/NLB 弥补负载均衡缺失。TLS 透传模式保留端到端加密，但须依赖应用层 keepalive 防止连接被中断。

结合 Route 53 私有托管区可实现内网域名无缝解析，便于迁移。监控应聚焦监听器空闲超时触发、目标组健康与跨 AZ 带宽，保障实时应用 SLA。南北向集中入口利于统一安全，但需评估入口带宽与 TLS 终止性能。综上，理解这两类架构的权衡，有助于在云上设计高可用实时网络。