ZS 使用 Network Orchestration for AWS Transit Gateway 优化成本和扩展案例分析

原文：How ZS Used Network Orchestration for AWS Transit Gateway to Optimize Costs and Scale Up 链接：https://aws.amazon.com/blogs/networking-and-content-delivery/how-zs-used-network-orchestration-for-aws-transit-gateway-to-optimize-costs-and-scale-up/ 发布日期：2024-01-23

一、公司背景

ZS 是一家专注于全球医疗保健领域的管理咨询和技术公司，在 AWS 上托管多个客户应用。随着业务增长，其网络架构变得复杂，横跨多个 AWS 区域和账户。

二、原有架构与痛点

2.1 原有架构

ZS 原本依赖第三方工具（基于 Amazon EC2 实例）来管理内部网络，该工具负责：

核心组件： - Spoke 账户 A：VPC 通过 Transit Gateway VPC 附件连接到网络账户的 Transit Gateway - Spoke 账户 B：需要 FQDN 过滤的 VPC 流量经过第三方 NAT 实例 - 安全账户：托管第三方 EC2 实例（用于负载均衡和防火墙） - 网络账户：包含 Transit Gateway，并通过 RAM 共享给组织内其他账户

流量路径：

Spoke VPC → Transit Gateway → 安全账户第三方实例 → 互联网/其他VPC/IPsec隧道

2.2 痛点

1. 成本高：EC2 实例和第三方许可费用
2. 运维复杂：需要持续补丁、升级和维护
3. 与 AWS 服务集成度低：缺乏自动化能力
4. 扩展困难：手动配置路由，难以快速扩展

三、解决方案：AWS 原生服务替换

ZS 采用 AWS 原生服务替换第三方工具：

四、Network Orchestration for AWS Transit Gateway

4.1 核心组件

Network Orchestration 基于以下 AWS 服务构建：

• CloudFormation：基础设施即代码
• EventBridge：事件驱动自动化
• Lambda：无服务器计算
• Step Functions：工作流编排

4.2 部署架构

4.3 自动化路由管理

通过 VPC 标签 触发自动化路由变更： - 自动关联路由表 - 自动传播路由 - 支持变更审批流程

4.4 静态路由补充

通过 CloudFormation 自定义资源（Lambda 函数）添加静态路由。

五、Gateway Load Balancer (GWLB) 配置

5.1 部署架构

• 在安全账户部署 GWLB 和防火墙实例
• 使用 GWLB 端点（VPC 端点）接收 Transit Gateway 流量
• 通过 GENEVE 协议将流量封装后发送至防火墙

5.2 流量路径优化

六、实施成果

6.1 成本优化

• 消除第三方 EC2 实例费用
• 消除第三方许可费用
• 利用 Serverless 架构降低运维成本

6.2 运维简化

• 基于 Serverless 架构（Lambda、EventBridge 等）
• 减少补丁和升级工作
• 自动化路由管理

6.3 可靠性提升

• 利用 GWLB 的高可用性
• 利用 Transit Gateway 的高可用性
• 消除单点故障

6.4 扩展性增强

• 自动化路由编排支持快速扩展新 VPC
• 支持多区域部署
• 标签驱动的自动化

6.5 可视化改进

• Network Orchestration 仪表盘集中管理
• AWS Global Network View 全局视图

七、关键技术要点

1. Network Orchestration for AWS Transit Gateway：AWS 提供的开源解决方案，用于自动化 TGW 路由管理
2. Gateway Load Balancer：第三层负载均衡器，支持透明网络网关（防火墙、IDS/IPS）
3. GENEVE 协议：GWLB 使用的封装协议，保留原始流量信息
4. 标签驱动自动化：通过 VPC 标签触发路由变更，实现 GitOps 风格管理

八、适用场景

• 多账户、多区域的企业级 AWS 网络架构
• 需要集中化防火墙检查的场景
• 希望从第三方网络工具迁移到 AWS 原生服务
• 需要自动化路由管理和变更审批

九、参考资源

分析日期：2025-12-23