迁移到AWS Cloud WAN多区域检查使用服务插入 网络与内容交付

---

AWS Cloud WAN 多区检查的迁移与服务插入

关键要点

文章核心内容

服务插入 AWS Cloud WAN 的一项新功能，允许轻松插入 AWS 和第三方网络与安全服务。迁移方法 提供了从具有集中检查的 Transit Gateway 迁移到 AWS Cloud WAN 的逐步指南，同时支持从不使用服务插入的 AWS Cloud WAN 迁移到使用服务插入的环境。网络功能组 介绍了新的网络功能组 (NFG)，用于管理流量重定向并简化网络服务的插入。

引言

自推出以来，AWS Cloud WAN 引起了大量客户关注，并进行了多项增强。其中最新的功能是服务插入，这一新功能允许用户通过中心策略文档轻松地在 AWS Cloud WAN 上插入 AWS 和第三方网络与安全服务。通过该功能，您可以轻松引导 VPC 到 VPC、VPC 到本地或出口流量流经网络或安全设备，具体可通过定义简单的策略声明或仅通过在 UI 中进行少量操作来实现。关于服务插入的详细介绍，请参考Simplify global security inspection with AWS Cloud WAN Service Insertion

目前，许多客户的实现方案涉及多个地区，每个地区都有集中检查。本文提供了一种逐步迁移的方法，包括：

从使用 Transit Gateway 的集中安全检查迁移到 AWS Cloud WAN 并使用服务插入，同时保持连接性并最小化迁移期间的停机时间。从不使用服务插入的 AWS Cloud WAN 实现迁移到使用服务插入的实现。

AWS Transit Gateway 是 AWS 网络解决方案的重要组成部分，在促进虚拟私有云 (VPC)、虚拟专用网络 (VPN) 和本地网络之间的高效可扩展连接方面发挥着关键作用。本文旨在为希望采用 AWS Cloud WAN 的客户提供特定功能的有用见解，例如基于策略的管理、一次性点击分段和原生自动化。建议读者在决策之前评估其网络需求并探索可用选项。

解决方案概述

AWS Cloud WAN 的服务插入简化了将网络服务例如防火墙插入流量路径的复杂性。它通过简单的基于意图的策略声明或在 UI 中少量操作来实现流量重定向至检查 VPC。

与此相关，AWS Cloud WAN 引入了一个新构造网络功能组 (NFG)，它是您检查 VPC 附加的全局容器。它根据策略中定义的意图管理流量重定向到所需的防火墙。这包括跨区域、VPC 到 VPC、本地到 VPC 和 VPC 或本地到互联网的流量。服务插入消除了配置区域检查分段和管理静态路由以定向流量的复杂性，因为 NFG 和路由传播都将自动为您管理。

使用服务插入不会产生额外费用，只有常规的AWS Cloud WAN 定价。

先决条件

在接下来的部分中，我们假定您熟悉 AWS 上的基本网络构造Amazon VPC、AWS Transit Gateway、AWS Cloud WAN 和 AWS Network Firewall。

我们不会专注于部署初始基础设施和服务的详细步骤，因此我们假设您将在测试环境中部署如下设置。我们的设置需要预先部署以下服务：

方案 1 部署工作负载 VPC、带有 AWS Network Firewall 的检查 VPC、AWS Transit Gateway 及相关路由表、附加约和对等连接。方案 2 部署工作负载 VPC、带有 AWS Network Firewall 的检查 VPC、没有服务插入的 AWS Cloud WAN 及相关分段、附加和路由。

迁移用例

方案 1 从 Transit Gateway 迁移到 AWS Cloud WAN 并使用服务插入

在此方案中，我们涵盖从基于 Transit Gateway 和集中检查的架构迁移到使用服务插入的 AWS Cloud WAN。

当前状态，无 AWS Cloud WAN

在多区域部署中，客户常采用的架构是使用点对点的 Transit Gateway，并在每个区域实施集中检查。这种架构的好处在于它易于理解、可预见，并允许根据需要将流量重定向到检查 VPC。这对于区域间流量尤其重要，在此过程中，防火墙确保通过对等链接的流量只有在符合分段策略时才被授权。然而，这种架构需要管理多个静态路由，并且通常需要实施双重检查，导致额外的成本。

第一阶段 部署 AWS Cloud WAN 和 Transit Gateway 对等连接

第一步是跨两个区域部署 AWS Cloud WAN 核心网络，并创建与每个区域中 Transit Gateway 的对等连接，如图 2 所示。

具体请参考博客文章Deploying hybrid networks using AWS Cloud WAN and AWS Direct Connect和Achieving traffic segmentation in multiAWS Region environments using AWS Transit Gateway and AWS Cloud WAN，这两篇文章覆盖了第一阶段中的配置细节图 2。

您需要应用策略变更以继续。然而，在此阶段，我们尚未配置任何分段、附加或路由，因此对您的路由不会造成任何改变。跨区域的路径仍通过 Transit Gateway 对等连接。

第二阶段 配置分段并创建 Transit Gateway 路由表附件

接下来的步骤是通过 AWS Cloud WAN 扩展在两个区域的 Transit Gateway 上配置的生产和非生产路由表。通过这样做，定义在每个区域内的分段可以通过核心网络扩展。这消除了依赖防火墙维持区域间分段的需要。这样可以提高性能，减少跳数，还可以降低与同一分段内流量的检查和处理相关的费用。

为此，我们需要在 AWS Cloud WAN 中创建这些分段，并在两个区域配置相关的路由表附件。我们将不会覆盖该配置的细节，因为这些已经在第一阶段的博客文章中进行了说明。

魔方网络服务加速器

此时，位于 useast1 的生产路由表现在通过核心网络学习到 euwest2 生产 VPC 的路由，反之亦然。这在图 3 的路由表中以红色显示。非生产路由表同样适用。

这意味着 useast1 的生产 VPC 到 euwest2 生产 VPC 的流量将通过 AWS Cloud WAN 传递，如图 3 中的紫色箭头所示。这是因为 Transit Gateway 的路由表正在学习更具体的路由，这些路由优先于原本配置的用于将所有流量发送到未直接附加的 VPC 通过检查 VPC 的默认路由。

如果用了更具体的静态路由而不是默认路由，则需要将其删除，以便流量能够通过 AWS Cloud WAN。这是因为针对同一前缀，静态路由优先于动态学习到的路由。您需要在两个区域进行协调，以避免不对称路由。有关详细信息，请参考 Transit Gateway 文档中的Route evaluation部分。

然而，在这一阶段，生产和非生产工作负载之间的流量仍将继续匹配默认路由。它将通过与 Transit Gateway 附加的检查 VPC 发送，并通过它们的对等连接进行跨区域交通流动。

以下是用于将生产和非生产 Transit Gateway 路由表及 VPC 附加到各自 AWS Cloud WAN 分段所需的核心网络策略配置示例：

json{ segments [ { name Production Isolated False } { name NonProduction Isolated False } ] attachmentpolicies [ { rulenumber 100 description Production VPCs conditions [ { type tagexists key Segment operator equalto value Production } ] action { addtosegment Production } } { rulenumber 200 description NonProduction VPCs conditions [ { type tagexists key Segment operator equalto value NonProduction } ] action { addtosegment NonProduction } } ]}

Transit Gateway 路由表附件配置

配置生产和非生产路由表的 Transit Gateway 路由表附件。如图 4 所示，确保复制其余路由表的配置。确保附加标签与核心网络策略中定义的附加策略匹配。

您需要先应用策略更改，才能配置附件。这不会改变您的路由。但是，配置附件将传播新的路由并修改如上所述的路由。

第三阶段 配置 NFG 并附加检查 VPC

在此步骤中，我们在 AWS Cloud WAN 中配置 NFG，并使用附加政策将两个新的检查 VPC 附加到其中图 5。防火墙设备的配置如 AWS Network Firewall 所示超出了本文的范围。请参考 Getting started with AWS Network Firewall 文档以了解更多信息。

我们部署两个新的检查 VPC 的原因是为了在将跨区域检查从 Transit Gateway 迁移到 AWS Cloud WAN 的过渡过程中，尽量减少潜在的停机时间。这还允许我们在过渡阶段保持现有的部署，以便于需要回滚的情况。成功将所有 VPC 迁移至 AWS Cloud WAN 后，我们将只保留 AWS Cloud WAN 中的检查 VPC。

以下是创建 NFG 和附加检查 VPC 的配置示例：

json{ networkfunctionsgroup [ { name InspectionVpcs requireattachmentacceptance false } ] attachmentpolicies [ { rulenumber 500 description Service Insertion Inspection VPCs conditions [ { type tagexists key NetworkFunctionGroup operator equalto value InspectionVpcs } ] action { addtonetworkfunctionsgroup InspectionVpcs } } ]}

检查 VPC 附件配置

配置两个检查 VPC 到 NFG 的附加，如图 6 所示，确保附件标签与在核心网络策略中定义的附加策略匹配，并选择Appliance mode support。

您需要先应用策略更改，才能配置附件。到此阶段，即使配置了附件，路由也不会被改变。

第四阶段 将区域间检查转移到 AWS Cloud WAN

在此阶段，我们将区域间的跨段流量重定向到 AWS Cloud WAN 的 NFG。服务插入将流量发送至新的检查 VPC，如图 7 中的路由表和紫色箭头所示。

默认情况下，服务插入将为所有区域对之间的流量选择一个检查点。在此情况下，默认选择的检查 VPC 是 useast1您也可以为每对区域指定检查 VPC，另一个用于备份。使用单一检查点提高了性能，并进一步减少了与检查和 AWS Cloud WAN 处理费用相关的成本，消除了双重检查的需求，这在传统部署中通常是实现的。

如图 7 所示，将以上过程概括为通过 NFG 使用服务插入将流量发送至检查。为了实现这一目标，我们使用服务插入在生产和非生产分段之间的流量路径中插入检查点。这可以通过在策略中添加 sendvia 声明来实现，下面是示例代码。要了解有关发送段操作的更多信息，请查看AWS Cloud WAN 文档。

json{ segmentactions { sendvia { segment Production whensentto { segments [NonProduction] } via { networkfunctiongroup [InspectionVpcs] } } }}

注意事项

注意，单个发送段动作足以在生产和非生产分段之间的双向流量中进行检查。无需对从非生产分段发起到生产的流量声明单独的语句。

如果我们检查图 7 中 Transit Gateway 路由表的路由，可以看到生产路由表现在通过核心网络学习到来自另一地区的非生产 VPC 的路由。同样，非生产路由表也在学习到来自另一地区的生产 VPC 的路由。这是因为服务插入和管理 NFG 分段动态传播这些路由，基于之前定义的分段动作和发送 via 策略。

这些路由将覆盖原本配置用于将跨区域流量发送到附加在 Transit Gateway 上的检查 VPC 的静态默认路由，而是将其发送到附加于 NFG 的检查 VPC。然而，在同一区域内，生产和非生产 VPC 之间的流量仍将继续通过附加在 Transit Gateway 的检查 VPC 流动。该情况将持续至一个或两个工作负载 VPC 按照下一阶段的说明迁移至 AWS Cloud WAN。

您需要在此阶段应用策略更改。一旦更改应用，路由将需要重新聚合并传播新路由，可能导致某些流量的短暂中断。因此，建议在计划的维护窗口时间内应用这些配置，以确保平滑过渡并将干扰降到最低。

第五阶段 从 Transit Gateway 迁移 VPC 到 AWS Cloud WAN

此时，所有区域间流量都经过 AWS Cloud WAN。如果该流量是跨段流量，则将通过附加至 NFG 的检查 VPC 进行路由。我们现在可以开始将生产和非生产 VPC 从 Transit Gateway 迁移到其在 AWS Cloud WAN 的相应分段。最好分阶段进行，以最小化潜在配置错误对大量 VPC 的影响。

有关从 Transit Gateway 迁移 VPC 到 AWS Cloud WAN 的方法，请参阅AWS Cloud WAN 和 AWS Transit Gateway 迁移与互操作模式。

图 8 显示了将非生产 VPC 从 Transit Gateway 迁移到 AWS Cloud WAN、更新的路由表和流量流向。

随着非生产 VPC 从 Transit Gateway 移动到 AWS Cloud WAN，非生产分段将学习其 Classless InterDomain Routings (CIDRs)。它还会动态传播至 Transit Gateway 上的非生产路由表，基于在第二阶段配置的附加。这允许通过保持已迁移 VPC 与仍在 Transit Gateway 上的 VPC 之间的可达性来实现逐步迁移。

同样，这些路由也会动态传播至 AWS Cloud WAN 上的生产分段和 Transit Gateway 上的生产路由表，但这次是通过服务插入和 NFG。因为 Transit Gateway 上生产路由表现在通过 AWS Cloud WAN 学习到的对非生产 VPC 的更具体路由，同时会优先选择该路由而不是指向 Transit Gateway 附加的检查 VPC 的默认路由。因此，流量将通过 NFG 和与之附加的检查 VPC，路由到 AWS Cloud WAN 并最终传递至非生产 VPC。图 8 中的蓝色箭头表示此流量，而紫色箭头则表示跨区域分段之间的流量。

将 VPC 从 Transit Gateway 移动到 AWS Cloud WAN 将需要重新聚合路由并传播新路由，这可能会导致某些流量的短暂中断。因此，在计划的维护窗口中进行这些配置的应用是最佳实践，以确保平滑过渡，最小化干扰。

第六阶段 完成迁移

在所有工作负载 VPC 已成功迁移并完成所有测试之后，我们现在可以安全删除旧的检查 VPC 和 Transit Gateway，如图 9 的最终架构所示。请注意，NFG 路由表是受管控的，并基于服务插入政策进行填充。尽管您可以完全查看这些路由，但无法在 NFG 内添加、删除或共享路由。

方案 2 从 AWS Cloud WAN 区域检查迁移到服务插入

在此方案中图 10，我们查看一个用例，其中 AWS Cloud WAN 已通过区域检查段实现，并使用静态路由将流量重定向至相应的检查 VPC。我们解释如何过

---