**发布时间:** 2025-10-13
**厂商:** AWS
**类型:** BLOG
**原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/how-silverflow-modernized-network-operations-by-combining-aws-cloud-wan-and-devops/
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] Silverflow 如何结合 AWS Cloud WAN 与 DevOps 实现网络运营现代化
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该方案详细阐述了金融科技公司 **Silverflow** 如何利用 **AWS Cloud WAN** 结合 **DevOps** 实践,对其全球支付网络进行现代化改造。核心目标是构建一个快速、安全、合规且易于扩展的全球网络,以满足银行、支付服务提供商等客户对低延迟、高可用性和严格数据驻留的要求,同时默认满足 **PCI DSS** 和 **3DS** 等行业合规标准。
在业务扩展至多区域时,Silverflow 原有的基于 **AWS Transit Gateway** 和 **AWS PrivateLink** 的单区域架构面临着路由管理复杂、手动配置易出错、难以实施网络分段等挑战。为解决这些问题,Silverflow 采用 AWS Cloud WAN 作为网络核心,其技术原理是利用 Cloud WAN **基于策略的集中式管理模型**和**原生网络分段**能力,通过动态路由协议(BGP)自动化管理全球网络连接。同时,将所有网络配置(包括核心网络策略、路由、附件等)通过**基础设施即代码 (IaC)** 的方式进行管理,并集成到 **CI/CD** 流程中,实现了网络变更的自动化、版本化和可审计化。
## 实施步骤
Silverflow 建立了一套标准化的网络变更自动化部署流程,确保所有变更都经过规划、控制、合规且自动执行。
1. **需求与代码化**
- 所有网络变更始于一个 **Jira** 任务,确保工作经过规划和共识。
- 网络工程师使用 **AWS CloudFormation** 将网络配置(如 Cloud WAN 策略、VPC 附件、路由规则)定义为代码,并提交到统一的 **GitLab** 代码仓库中。
2. **代码审查与审批**
- 工程师创建合并请求 (Merge Request),该请求必须由平台团队的另一名成员进行审查和批准。
- 通过 GitLab 的 `CODEOWNERS` 机制强制执行审批流程,确保变更的双人复核原则。
3. **自动化测试流水线**
- 合并请求一旦创建,会自动触发 CI/CD 流水线中的构建和测试阶段。
- 流水线会执行一系列自动化检查,包括 `cfn-lint` 语法检查,以及一个**自定义开发的策略合规性检查器**(因缺少官方 CloudFormation Guard 规则),用于捕获潜在的逻辑错误。
4. **手动触发部署**
- 只有当测试流水线成功通过后,工程师才能手动触发部署流水线。
- 这一步骤保留了人工控制,确保工程师可以在合适的时机执行变更,对生产环境的影响进行最终把控。
5. **自动化部署**
- 部署流水线自动执行 IaC 脚本,将变更应用到 AWS 环境中。
- 整个过程无需登录 AWS 管理控制台进行任何手动操作,实现了端到端的自动化。
## 方案客户价值
- **全球网络敏捷性与可扩展性**
- 结合 IaC 和 Cloud WAN,新区域的部署时间缩短至**一天之内**。当新的 VPC 附加到 Cloud WAN 后,动态路由会自动更新,无需手动干预,极大地提升了业务扩展速度。
- **强化的合规性与可审计性**
- 所有网络变更都记录在 Git 中,具备完整的版本历史、审批记录和部署日志。这种端到端的追踪能力为满足 **PCI DSS** 和 **3DS** 等严格的合规审计要求提供了坚实的基础。
- **显著降低运营开销与风险**
- 通过高度自动化,一个平台团队即可管理复杂的全球网络,而无需设立专门的网络团队。
- 严谨的 CI/CD 流程和自动化检查,最大限度地减少了因人为错误导致的配置问题和网络中断风险。
- **统一的 IP 地址管理**
- 方案集成了 **Amazon VPC IPAM**,实现了对全球网络 CIDR 地址块的集中自动化管理,有效避免了 IP 地址冲突,简化了网络规划和扩展。
## 涉及的相关产品
- **AWS Cloud WAN**: 解决方案的核心,用于构建和管理统一的全球广域网。
- **AWS CloudFormation**: 作为基础设施即代码 (IaC) 工具,用于声明式地定义和管理所有网络资源。
- **Amazon VPC IPAM**: 用于集中规划、跟踪和监控 AWS 工作负载的 IP 地址。
- **AWS Organizations**: 用于管理多账户环境,实现策略的统一应用。
- **AWS Site-to-Site VPN & AWS Direct Connect**: 用于将本地网络或合作伙伴网络安全地连接到 AWS Cloud WAN。
- **GitLab**: 作为 CI/CD 平台,承载代码仓库、审批流程、自动化测试和部署流水线。
- **FortiGate**: 第三方 SDN 设备,通过 **Connect attachments** 与 Cloud WAN 集成,扩展网络功能。
## 技术评估
- **优势**
- **架构先进性**: 该方案将现代 DevOps 理念(IaC、CI/CD)与先进的云原生网络服务(Cloud WAN)深度融合,实现了“策略即代码”,是云上全球网络运维的典范实践。
- **高可扩展性**: Cloud WAN 原生的多区域支持、基于策略的自动化以及与 VPC IPAM 的集成,为业务的全球化扩展提供了强大的技术基础,避免了传统网络扩展的复杂性。
- **强安全性与管控力**: 通过严格的 CI/CD 流程和 Cloud WAN 的原生分段能力,实现了网络变更的强管控、隔离和可追溯性,天然满足金融支付行业对安全与合规的最高要求。
- **可能的限制**
- **技术门槛较高**: 方案的成功实施要求团队同时具备深厚的 DevOps 工程能力(如 CloudFormation、CI/CD 流水线构建)和对 Cloud WAN 等高级网络服务的深刻理解。
- **依赖完整的工具链**: 方案的有效性高度依赖于 Git、CI/CD 平台、IaC 工具等组成的完整工具链。任何环节的缺失都可能影响其自动化和管控效果。
- **自定义验证成本**: 文中提到,由于缺少官方的 CloudFormation Guard 规则,团队需要自行开发策略检查器,这会带来额外的开发和长期维护成本。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# Silverflow 如何结合 AWS Cloud WAN 与 DevOps 实现网络运营现代化
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/how-silverflow-modernized-network-operations-by-combining-aws-cloud-wan-and-devops/](https://aws.amazon.com/blogs/networking-and-content-delivery/how-silverflow-modernized-network-operations-by-combining-aws-cloud-wan-and-devops/)
**发布时间:** 2025-10-13
**厂商:** AWS
**类型:** BLOG
---
在本文中,我们将深入探讨 [Silverflow](https://www.silverflow.com/) 公司如何采用 [AWS Cloud WAN](https://aws.amazon.com/cloud-wan/) ,并利用标准的 DevOps 实践,以合规且安全的方式管理其全球网络。
在 Silverflow,我们的使命是推动支付行业迈入现代化,这也要求我们从头开始重新思考我们的网络架构。我们处理的每一笔交易都必须快速、安全且合规。我们的客户,包括银行、支付服务提供商和大型商户,都期望获得低延迟、高可用性和严格的数据驻留。要在全球多个大洲满足这些需求,就需要一个生而全球化且默认可审计的基础设施,并将[支付卡行业](https://www.pcisecuritystandards.org/) [数据安全标准](https://www.pcisecuritystandards.org/standards/pci-dss/) (PCI DSS) 和 [3D 安全认证](https://www.pcisecuritystandards.org/standards/pci-3ds-core/) (3DS) 合规性作为默认要求。
## 挑战:不断增长的复杂网络
我们最初的重点是欧洲市场,业务部署在爱尔兰 [AWS 区域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) (eu-west-1)。2021 年,我们部署了一套标准的多账户 (multi-account) 架构,该架构构建在 [AWS Organizations](https://aws.amazon.com/organizations/) 之下,并通过[组织单元](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (OUs) 进行划分。我们将所有银行卡网络的连接都集中在一个 AWS 账户中,通过 [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/) 和 [AWS Direct Connect](https://aws.amazon.com/directconnect/) 接入单个 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) (TGW)。而与其他账户/服务的通信则通过大量的 [AWS PrivateLink](https://aws.amazon.com/privatelink/) 终端节点进行。
在我们最初的单区域 (single-Region) 部署中,使用 PrivateLink 保证了流量的私密性,同时也让连接管理变得相对简单。此外,我们还使用[安全组](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) (security group) 引用来控制哪些应用程序可以使用特定的 PrivateLink 终端节点,从而避免了复杂的路由规则或 IP 白名单。然而,当我们在 2022 年探索增加其他 AWS 区域的可能性时,我们开始遇到一些挑战。我们面临着几个问题:不确定应该对等连接 [Amazon Virtual Private Clouds](https://aws.amazon.com/vpc/) (Amazon VPCs) 还是 TGW,并且需要找出管理路由的最佳方法——静态还是动态。此外,我们还必须仔细考虑这会给现有架构带来多大的复杂性。
图 1 展示了我们曾考虑过的一个目标架构。

图 1. 用于多区域通信的 Transit Gateway 对等连接架构。
自动化是我们的核心原则之一,因此我们倾向于采用一种能够支持某种形式动态路由的解决方案。手动管理静态路由容易引入人为错误,对我们来说并不可取。然而,我们发现这种自动化方案也同样容易出错,导致难以理解或验证当前的网络状态。此外,要强制执行像分段 (segmentation) 这样的标准网络概念也很有挑战性,而这对于我们的合规性至关重要。
无论是静态 TGW 部署还是自动化动态路由方案,其中涉及的运营风险,特别是配置错误方面的风险,都超出了我们的风险承受能力。然而,我们仍然需要解决多区域连接的需求。
## 解决方案:AWS Cloud WAN 与 DevOps
我们在 re:Invent 2022 大会上首次接触到 AWS Cloud WAN,在与 AWS 工程师深入探讨了我们的架构后,发现它完全符合我们的网络目标。AWS Cloud WAN 让我们能够像网络工程师一样,按照我们期望的方式来思考网络。
- 提供基于策略的模型和原生分段。这与隔离和路由域等常见的网络概念相一致。
- 使用动态路由在核心网络边缘 (Core Network Edges, CNEs) 之间以及与本地环境之间通告路由。
- 通过 [Connect 连接](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-connect-attachment.html) (Connect attachments) 与外部 SDN 设备 (如我们的 Fortigate) 集成。
- 支持多区域和多账户,使全球扩展变得易于管理。
AWS Cloud WAN 还使我们能够利用标准的基础设施即代码 (Infrastructure as Code, IaC) 和持续集成与持续交付 (Continuous Integration and Continuous Delivery, CI/CD) 管道,通过其策略即代码 (policy-as-code) 原则来管理网络。我们由此拥有了一个可进行版本控制、同行评审和审计的网络。
这促使我们将 AWS Cloud WAN 作为网络的核心,并将其提升为我们的核心产品特性之一,从而显著改变了我们处理工作负载和网络连接的方式,如图 2 所示。我们重构了平台,最终确定了以下概念,这些概念至今仍是我们平台的基础:
- **平台分区 (Platform Partitions)**:自包含的单元,靠近我们的客户 (以满足延迟/数据驻留要求),用于处理和存储数据。
- **连接中心 (Connectivity Hubs)**:提供到银行卡网络的双区域连接。
使用我们的 IaC 配置,新的分区可以在一天内快速创建。一个分区可以使用任何现有的连接中心,一旦就绪便可立即处理交易。现在,当路由更新时,我们无需再担心手动更改。当新的 AWS 区域和 VPC 连接到 AWS Cloud WAN 后,它们就准备就绪了。所有这些操作都在保持 PCI DSS 和 3DS 合规性的前提下完成,并且每一次核心网络变更都是可追溯、可审计且需要经过评审的。

图 2. AWS Cloud WAN 高层级设计
## 使用 AWS CloudFormation 实现 IaC
Silverflow DevOps 战略的核心部分是早期就采用了 IaC。所有的 AWS Cloud WAN 配置,包括核心网络策略、连接和路由,都使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板进行定义。这确保了版本控制、可重复性和一致性。
### 代码仓库结构
我们整个连接基础设施都通过一个单一代码仓库进行管理。这包括 AWS Cloud WAN、VPN、Direct Connect、FortiGate 集成、[Amazon VPC IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 以及防火墙策略。该仓库按逻辑划分为以下几个文件夹:
- **全局定义**:包含共享资源,如 AWS Cloud WAN 策略、VPC IPAM CIDR 块以及其他非区域性 (全局) 资源。
- **连接/区域特定配置**:同样按区域子文件夹组织,涵盖 [Direct Connect 网关](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html) (Direct Connect gateways)、VPN 定义、SDN/Fortigate 配置、[Amazon Route 53 托管区域](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) (Amazon Route 53 hosted zones) 和告警规则。
- **防护与策略检查**:我们在这里编写了一个基于 TypeScript 的自定义策略检查器,用于在部署前验证 AWS Cloud WAN 定义。
这种结构使所有网络配置都保持隔离、版本化和可审计。功能团队不直接接触任何这些资源。只有平台团队才能通过 GitLab 管道批准和部署变更,并通过 `CODEOWNERS` 文件强制执行。
### Silverflow 核心网络策略文档的 CloudFormation 代码片段示例
在下面的代码片段中,您可以看到我们 AWS Cloud WAN 策略的修改版本。尽管这可能是一个标准配置,但我们想重点介绍一些配置项:
- 在 CloudFormation 中,将 [DeletionPolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-attribute-deletionpolicy.html) 和 [UpdateReplacePolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-attribute-updatereplacepolicy.html) 属性设置为 `Retain`,有助于确保即使代码中的某些更改被视为删除核心网络,该资源也不会被真正删除。可以把它看作一种双重保护机制。
- 我们使用基于标签的[连接策略](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policy-attachments.html) (attachment policies) 来简化管理。
- 我们使用 VPC IPAM 来管理所有 CIDR,包括用于 CNE 的 `inside-cidr-blocks`。VPC IPAM 与 AWS Cloud WAN 是我们自动化方案的关键组成部分,因为它允许我们在全球范围内控制 IP 地址分配。这确保了新的 AWS 区域可以与网络的其余部分集成,而不会出现 CIDR 块重叠。我们采用了三个 [RFC 1918](https://www.rfc-editor.org/rfc/rfc1918.html) 地址范围,并将其用于:
- 工作负载 (Workloads)——10/8,最大的地址块。
- 连接 (Connectivity)——172.16/12。
- “合作伙伴 (Partners)”——192.168/16。
```
CoreNetwork:
Type: AWS::NetworkManager::CoreNetwork
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
Properties:
Description: Silverflow Core Network
GlobalNetworkId: !Ref GlobalNetwork
PolicyDocument:
version: "2021.12"
core-network-configuration:
vpn-ecmp-support: true
asn-ranges:
- 64600-64700
edge-locations:
- location: eu-west-1
inside-cidr-blocks:
- !Select [2, !Split ["|", !Ref CoreNetworkIpamAllocEuWest1]]
- location: eu-central-1
inside-cidr-blocks:
- !Select [2, !Split ["|", !Ref CoreNetworkIpamAllocEuCentral1]]
- location: us-east-2
inside-cidr-blocks:
- !Select [2, !Split ["|", !Ref CoreNetworkIpamAllocUsEast2]]
- location: us-west-2
inside-cidr-blocks:
- !Select [2, !Split ["|", !Ref CoreNetworkIpamAllocUsWest2]]
- location: us-east-1
inside-cidr-blocks:
- !Select [2, !Split ["|", !Ref CoreNetworkIpamAllocUsEast1]]
segments:
- name: prd
description: Workloads in PRD that do not require partner network access
edge-locations:
- eu-west-1
- eu-central-1
- us-east-2
- us-west-2
- us-east-1
require-attachment-acceptance: !Ref requireAttachAcceptancePrd
deny-filter:
- con
- condev
- cnwdev
- dev
- name: dev
description: Workloads in DEV that do not require partner network access
edge-locations:
- eu-west-1
- eu-central-1
- us-east-2
- us-east-1
require-attachment-acceptance: !Ref requireAttachAcceptanceDev
deny-filter:
- con
- conprd
- cnwprd
- prd
- name: egr
description: VPCs that allows filtered traffic to the internet
edge-locations:
- eu-central-1
- us-east-2
require-attachment-acceptance: !Ref requireAttachAcceptancePrd
attachment-policies:
- rule-number: 100
conditions:
- type: tag-exists
key: segment
action:
association-method: tag
tag-value-of-key: segment
Tags:
- Key: Name
Value: !Sub "${domainAlias}-core-net"
- Key: team
Value: Platform
- Key: env
Value: !Ref env
```
## CI/CD 管道
我们使用标准的 GitLab IaC 管道来部署网络相关的 IaC,这与我们的开发人员用来部署生产应用代码的管道基本相同。网络相关的 IaC 保存在一个安全的仓库中,并通过 `CODEOWNERS` 确保只有平台团队才能批准合并请求 (merge requests)。

图 3. 合并请求示例
图 3 展示了一个标准的合并请求,它关联到一个 Jira 故事,并由平台团队的一名成员批准。该合并请求会触发一次管道运行,其中包含多个作业,如图 4 所示。

图 4. 构建和测试管道
这个管道中有几个默认作业,而针对这个仓库,还有一个特别的 “check_policy_compliance” 作业。由于目前没有针对 AWS Cloud WAN 的 [CloudFormation 防护规则](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) (CloudFormation guard rules),我们决定自己编写一些规则。这些自定义规则旨在捕获逻辑错误,我们正在努力扩展这些功能。
最后,当这个管道成功运行后,分支就可以合并到主干,这会触发最后一个管道,在我们的 AWS 环境中运行 IaC,如图 5 所示。我们需要在每一步都进行人工干预,以确保控制和验证。当管道成功后,网络变更就会生效,整个过程无需在 [AWS 管理控制台](https://aws.amazon.com/console/) (AWS Management Console) 中进行任何手动操作。

图 5. 部署管道
## 总结
当前的自动化流程确保了我们进行的是有计划、受控制、合规且自动化的网络变更。没有任何单一个人可以对我们的网络 (或生产账户/代码) 进行更改,如图 6 所示。

图 6. 自动化部署流程
1. Jira 故事:经过计划并达成一致的工作。
2. 合并请求 (MR) 批准:平台团队成员批准 (不能是同一个人)。
3. 基于管道的测试:确保质量。
4. 由工程师自行决定部署:确保他们保持控制权。
## 结论
AWS Cloud WAN 为我们提供了基于策略的模型、原生分段和恰当的路由控制。它支持 BGP 协议。我们可以用它像网络工程师一样思考网络问题。它还能与第三方 SDN 设备集成,以便我们扩展其功能。
结合 VPC IPAM 和 IaC,推出新的 AWS 区域变得流程化。没有电子表格,没有手动对等连接,只有代码。CI/CD 为我们提供了所需的控制和可见性。每一次变更都经过审查、跟踪,并通过自动化进行部署。所有操作都在 Git 中完成。

表 1. Silverflow 实现的解决方案和能力总结
我们最初的目标是增加对第二个区域的支持。但 AWS Cloud WAN 结合我们的 IaC 和 CI/CD 实践,带来了一次全面的网络重构。我们利用它将网络提升到了我们所设想的水平:一个完全自动化、合规、受控、可审计且运营开销极低的网络。通常,任何拥有全球网络的企业都会有一个专门的网络团队。而我们则由平台团队统一管理我们的全球网络以及基础 AWS 平台。高水平的自动化、稳定性以及我们自己的 DevOps 实践使这一切成为可能。
要了解更多关于为您的组织实施 AWS Cloud WAN 的信息,请访问 [AWS Cloud WAN 文档](https://docs.aws.amazon.com/network-manager/latest/cloudwan/what-is-cloudwan.html) 。
## 关于作者

### Kris Gillespie (特邀作者)
Kris 是 Silverflow 的平台与安全主管,负责领导平台和安全两个团队。Kris 在系统工程和运维领域拥有三十多年的经验,专注于构建能够扩展的实用平台。工作之余,他喜欢环游世界,享受在乡间驾车的乐趣,并尽可能多地参加每年的各种节日活动。

### Pablo Sánchez Carmona
Pablo 是 AWS 的一名高级网络专家解决方案架构师,他帮助客户设计安全、有弹性且经济高效的网络。不谈论网络时,Pablo 喜欢打篮球或玩电子游戏。他拥有瑞典皇家理工学院 (KTH) 的电气工程理学硕士学位,以及加泰罗尼亚理工大学 (UPC) 的电信工程硕士学位。
<!-- AI_TASK_END: AI全文翻译 -->