[解决方案] Silverflow 如何结合 AWS Cloud WAN 与 DevOps 实现网络运营现代化

**发布时间:** 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全文翻译 -->