[解决方案] 使用 AWS Cloud WAN 服务插入解决私有 IPv4 耗尽问题

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 AWS Cloud WAN 服务插入解决私有 IPv4 耗尽问题 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该解决方案核心内容是通过AWS Cloud WAN结合服务插入（service insertion）技术，中央化部署私有NAT网关和PrivateLink，解决私有IPv4地址耗尽问题。**关键术语**包括AWS Cloud WAN、PrivateLink和NAT网关。背景是企业网络在增长中面临私有IPv4地址（RFC 1918和RFC 6598定义）分配困难，原因包括规划不足、设计变化和新技术（如容器）需求。该方案适用于云迁移和扩展场景，针对行业需求如AWS环境规模化，提供可扩展的IP空间利用。技术原理基于在AWS环境中分配仅限内部路由的私有IPv4范围（如100.64.0.0/10），并通过中央化NAT和PrivateLink处理流量，实现内部路由优化和外部流量转换，避免VPC级NAT。 ## 实施步骤 1. **配置AWS Cloud WAN段和VPC关联** - 创建四个段：Production段（关联工作负载VPC）、Hybrid段（关联Direct Connect）、Inbound段（关联中央化入站VPC）和Outbound NFG（用于NAT网关插入）。 - 关联工作负载VPC到Production段，中央化出站NAT VPC到Outbound NFG，中央化入站VPC到Inbound段。理由是确保流量路径隔离和高效路由。技术原理涉及Cloud WAN的政策定义，实现动态路由传播。 2. **配置出站流量路由** - 在Cloud WAN政策中定义服务插入意图：从Production段到Hybrid段或Inbound段的流量通过Outbound NFG路由。 - 部署中央化NAT VPC，使用小范围路由子网（如10.2.100.0/26）并配置NAT网关。逻辑衔接是确保出站流量（如向on-premises）进行源IP地址转换，避免地址冲突。静态路由需添加到Hybrid和Inbound段中，以处理返回流量。 3. **配置入站流量路由** - 使用段共享（segment sharing）在Inbound和Hybrid段之间动态共享路由。 - 部署VPC端点在中央化入站VPC中（如10.1.0.0/20子网），并利用PrivateLink处理入站请求。理由是避免流量翻译，提高效率。逻辑衔接是将入站流量直接路由到端点，而非工作负载VPC。 4. **验证多区域扩展** - 虽然焦点在单区域，但可扩展到多区域，通过重复配置段和路由。理由是保持架构一致性，技术原理基于Cloud WAN的全局路由能力。 ## 方案客户价值 - **最大化IP空间利用**：通过分配仅限AWS内部路由的私有IPv4范围（如100.64.0.0/10），客户可扩展VPC数量和规模，实现高效地址分配，与传统分布式NAT方案相比，减少内部流量翻译，提升资源利用率。 - **成本优化**：中央化NAT资源减少私有NAT网关部署，潜在降低成本；例如，量化收益包括减少网关实例，优化整体开销，与竞品（如Azure Virtual WAN）相比，AWS方案通过服务插入提供更精细的流量控制机制。 - **可扩展性和灵活性**：解决云迁移中的地址短缺，支持新技术集成，如容器化工作负载；与传统方案差异在于，避免VPC级地址规划，简化网络设计，实现业务快速扩展。 ## 涉及的相关产品 - **AWS Cloud WAN**：用于构建全球网络，提供段管理和服务插入，实现流量路由和优化，在方案中负责中央化流量控制。 - **AWS PrivateLink**：安全连接服务，处理入站流量到VPC端点，在方案中最大化路由IP空间利用，避免直接暴露。 - **私有NAT网关**：转换流量源IP地址，部署在中央化出站VPC中，减少整体网关需求，提升成本效率。 - **AWS Direct Connect**：提供AWS与on-premises的专用连接，在方案中确保混合流量路由。 ## 技术评估 该解决方案技术先进性体现在可扩展性和成本优化上，利用Cloud WAN的服务插入和段共享，实现高效私有IP管理，适用于大规模企业云环境。优势包括：简化网络架构、减少NAT部署并提升IPv4利用率；可行性高，依赖标准AWS服务，易于集成现有基础设施；适用范围覆盖单区域和多区域场景。可能的限制是需手动配置静态路由（例如在Hybrid段），可能增加初始实施复杂度；与竞品（如Google Cloud Interconnect）相比，AWS方案在IPv6支持和政策管理上更具灵活性，但如果客户外部网络已使用类似IP范围，可能需额外规划以避免冲突。 ## 其他信息 - 注意事项包括：AWS路由IP域（如100.64.0.0/10）不应在公司网络中广告，并确保DNS解析避免冲突；Hybrid段动态学习路由时，需防止向on-premises传播。 - 作者背景：Mehdi Dahane和Philipp Schaefer作为AWS解决方案架构师，提供专业见解，强调实际应用经验。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 通过 AWS Cloud WAN 服务插入解决私有 IPv4 地址耗尽问题 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/addressing-private-ipv4-exhaustion-with-aws-cloud-wan-service-insertion/](https://aws.amazon.com/blogs/networking-and-content-delivery/addressing-private-ipv4-exhaustion-with-aws-cloud-wan-service-insertion/) **发布时间:** 2025-06-26 **厂商:** AWS **类型:** BLOG --- 在本帖中，我们描述如何使用 [Amazon Web Services (AWS) Cloud WAN](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policy-service-insertion.html) 与服务插入来集中化您的私有 NAT 网关 (Private NAT Gateways) 和 [PrivateLink](https://aws.amazon.com/privatelink/)，从而有效且高效地解决私有 IPv4 地址耗尽问题。我们将演示如何最大化可用 IP 空间的使用，同时最小化成本影响。 私有 IPv4 空间，由 [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) 和 [RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598) 定义，在正确规划下，最初看起来像是一个广阔且取之不尽的地址源。然而，在大多数企业网络中，随着组织的发展，客户经常难以为新项目、环境或整个位置分配足够的地址范围。这可能归因于几个原因：难以规划多年的增长和预见规模、设计方向的变化导致使用效率低下、并购以及采用新技术的使用（如容器 (containers)，它们消耗大量 IP 空间）。 这可能会导致客户在开始云之旅或需要扩展以满足业务需求时，在其私有 IPv4 范围内可用的空间有限。为了解决这种情况，AWS 提供多种解决方案和建议，例如：[Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/)、[对 IPv6 的广泛支持](https://aws.amazon.com/vpc/ipv6/)、PrivateLink 以及分布式私有 NAT 网关 (Private NAT Gateways)，如帖子 [如何通过私有 NAT 解决方案解决私有 IP 耗尽问题](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) 中所述。 另一种战略方法是使用 AWS Cloud WAN 来提供一个持久、可扩展且经济高效的解决方案。 # 先决条件和假设 本帖假设您熟悉 AWS 网络服务，包括 NAT 网关 (NAT Gateways)、AWS PrivateLink 和 AWS Cloud WAN，以及企业网络概念的基础知识。我们不会专注于定义这些服务和概念，而是概述它们的功能以及如何在突出架构中使用它们。 # 解决方案概述 目前，面对私有 IPv4 地址短缺且尚未迁移到 Amazon VPC Lattice 或 IPv6 的客户，通常会在其虚拟私有云 (VPC) 中部署私有 NAT 网关。 本帖中描述的解决方案允许您消除在 AWS 内剩余流量的 NAT 需求，并最大化可用 IP 空间的使用，从而让您扩展 VPC 的数量和大小。 该方法基于分配一个仅在 AWS 环境中可路由的私有 IPv4 范围，并在区域 (Regional) 级别而不是 VPC 级别部署集中化的 NAT 和 PrivateLink。如 图 1 所示的概念架构。 *  * *图 1: 概念架构—AWS 可路由 IP 域* 在此示例中，我们将运营商级 NAT (Carrier-Grade NAT，简称 CGN) 范围 100.64.0.0/10 (RFC 6598) 分配给 AWS 环境，并将其分为 /12 CIDR 以分配给每个 AWS 区域。此范围在 AWS 区域之间路由，但当它离开 AWS 时，会通过区域私有 NAT 网关翻译成公司范围可路由 IP 域 (示例中为 10.0.0.0/8)。这让您拥有一个扩展范围，用于在 AWS 内部署 VPC 和工作负载，并在内部自由路由，而无需对从一个 VPC 到另一个 VPC 的流量进行 NAT。 这里选择的范围是作为示例，因为客户传统上选择在 NAT 设备后面使用它，而不将其路由到公司广域网 (WAN)。如果您正在路由此范围，则可以选择任何其他仅部署在 NAT 设备后面的私有范围，并在多个位置（如 AWS、企业和第三方数据中心）重复使用。 如果您没有足够大的非路由 IP 空间，则可以选择一个较小的范围，并在所有 AWS 区域、本地位置和第三方数据中心中重复使用。在这种情况下，区域内剩余的流量不会被翻译。但是，所有离开区域的流量（无论是到另一个 AWS 区域还是到本地位置）都必须由区域私有 NAT 网关翻译。 在本帖中，我们探讨如何通过应用以下要点中概述的逻辑（如 图 2 所示的关键设计原则）来实现这一点： 1. AWS 可路由 IP 域到 AWS 可路由 IP 域：路由 2. AWS 可路由 IP 域到公司范围可路由 IP 域：NAT 3. 公司范围可路由 IP 域到 AWS 可路由 IP 域：PrivateLink 4. 公司范围可路由 IP 域到公司范围可路由 IP 域：路由  *图 2: 设计原则* # 解决方案架构 图 3 显示了一个区域的高级架构，包括以下元素： - 使用 AWS 可路由 IP 空间 (100.64.0.0/10) 的工作负载 VPC，其中使用大 CIDR 的能力允许更大的可扩展性。此范围在 AWS 中可路由，消除了在工作负载 VPC 内需要 NAT 网关或 VPC 端点 (VPC endpoints) 的需求。 - 一个单一的集中化出站 NAT VPC，用于在流量离开 AWS 时进行翻译。使用集中化 NAT 减少了所需的私有 NAT 网关数量。此 VPC 需要一个小型可路由子网 (示例中为 10.2.100.0/26)，其中每个可用区 (Availability Zone，简称 AZ) 可以分配一个 /28 来容纳 NAT 网关。 - 一个单一的集中化入站 VPC，用于部署入站流量的 VPC 端点。使用集中化入站 VPC 让您最大化可用可路由 IP 空间的使用 (示例中为 10.1.0.0/20)，而非将其分为分配给每个 AZ 的工作负载 VPC 的较小子网。更高效地使用空间让您最大化可拥有的 VPC 端点数量。 *  * *图 3: 高级架构* ## 使用 AWS Cloud WAN 构建连接 为了演示路由工作原理，图 4 引入了 AWS Cloud WAN 和 [AWS Direct Connect](https://aws.amazon.com/directconnect/)，并更详细地显示了 VPC 设计。 网络账户所有者负责部署集中化出站 NAT VPC 和集中化入站 VPC。他们还拥有连接性，如 AWS Cloud WAN 和 Direct Connect。如 图 4 中蓝色所示，可路由子网分配为 10.2.100.0/26 用于 NAT 和 10.1.0.0/20 用于 VPC 端点。这些两个 CIDR 需要通过 Direct Connect 向本地网络公布。 ** *  * *图 4: 区域内的流量流* ### 从 VPC 中的工作负载启动到本地的流量 1. 从 VPC 1 中的工作负载启动的流量，通过附件路由到 AWS Cloud WAN 核心网络。 2. AWS Cloud WAN 将被配置为将所有目的地址为本地网络的流量路由到集中化出站 NAT VPC。 3. NAT 网关将源 IP 地址翻译为其自身地址 (示例中为 10.2.100.1)，并将其路由回 AWS Cloud WAN。 4. Cloud WAN 然后将流量转发到本地网络通过 AWS Direct Connect。 返回流量遵循相同的路径，返回步骤 (5) 到 (8)。返回数据包的目的地址为 NAT IP 地址 (10.2.100.1)。NAT 网关将目标 IP 地址从自身地址翻译回发起请求的工作负载地址。然后，它将数据包发送到 AWS Cloud WAN，后者将其转发回 VPC 和工作负载。 ### 从本地到 VPC 中的工作负载启动的流量 1. 从本地网络启动的流量通过 AWS Direct Connect 路由到 AWS Cloud WAN。 2. AWS Cloud WAN 将流量直接转发到部署在集中化入站 VPC 中的 VPC 端点 (示例中为 10.1.0.1)，因为它不需要任何翻译。 3. 使用 PrivateLink，VPC 端点将数据包发送到 4. 然后，网络负载均衡器 (NLB) 可以将其发送到目标组中的一个实例。 返回流量遵循相同的路径，返回步骤 (5) 到 (8)。实例将返回数据包发送到 NLB，后者通过相同的 VPC 端点转发。从那里，数据包被发送到 AWS Cloud WAN，后者将其路由回本地网络通过 Direct Connect。 ### 使用 AWS Cloud WAN 服务插入进行路由 现在我们描述了架构和流量模式，让我们检查解决方案实现。我们将演示如何使用 AWS Cloud WAN 服务插入在出站流量的路径中插入集中化 NAT 网关，并使用段之间路由共享处理入站流量。 图 5 显示了 AWS Cloud WAN 段以及段和 VPC 子网的路由表。它还显示了多个账户如何使用集中化入站 VPC 来为各自应用程序部署 VPC 端点。  *图 5: 使用 AWS Cloud WAN 服务插入进行路由* #### 配置 AWS Cloud WAN 段和 VPC 附件 要部署此架构，您需要在 AWS Cloud WAN 核心网络上配置四个段以及相关的附件： - **生产段 (Production segment)**：用于关联工作负载 VPC 附件。 - **混合段 (Hybrid segment)**：用于通过 Direct Connect 关联到本地网络的连接。 - **入站段 (Inbound segment)**：用于关联集中化入站 VPC。这是托管 PrivateLink 端点的 VPC。 - **出站网络功能组 (Outbound Network Function Group，简称 NFG)**：这是一个由 AWS Cloud WAN 服务插入创建的托管段，用于附加集中化出站 NAT VPC 并在出站流量的路径中插入 NAT 网关。 AWS Cloud WAN 核心网络的部署以及段和附件的配置超出了本帖的范围，但已在 [AWS Cloud WAN 用户指南](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-create-policy-console.html) 中详细说明。 #### 配置出站流量的路由 从 VPC 中的工作负载向本地资源启动的出站流量需要在离开 AWS 之前进行翻译 (NAT)。使用服务插入，您在策略中定义意图，AWS Cloud WAN 确保出站流量通过集中化出站 NAT VPC 和其中的 NAT 网关进行路由。 根据您的应用程序，您可能还需要允许从 VPC 中的工作负载启动的流量到达部署在集中化入站 VPC 中的 PrivateLink 端点。端点位于公司范围可路由 IP 域 (示例中为 10.1.0.0/20)，而工作负载位于 AWS 可路由 IP 域 (100.64.0.0/10 范围)。因此，此流量必须根据先前描述的设计原则进行翻译。 剩余在生产段内的流量不需要 NAT。 必要的服务插入策略意图如下： | **服务插入策略意图** | | --- | | **源段** | **目标段** | **操作** | | 生产 | 混合 | 通过 Outbound NFG 发送 | | 生产 | 入站 | 通过 Outbound NFG 发送 | *表 1: 服务插入策略意图* 要为生产段设置服务插入，请按照 [AWS Cloud WAN 用户指南中添加段操作的部分](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policy-network-actions-routes.html) 中所述的步骤操作。 当流量到达 NAT 网关时，它会将数据包的源 IP 地址翻译为其自身地址 (示例中为 10.2.100.1)。为了确保返回流量能到达 NAT 网关，在混合段和入站段中都需要静态路由。这是因为，虽然服务插入功能确保源段和目标段之间动态路由传播，但它不会直接传播附加到 NFG 的 VPC 路由。在 图 5 中，静态路由在混合段和入站段路由表中以红色显示。这是解决方案在初始实施中唯一需要的静态路由，并指向集中化出站 NAT VPC 的整个 CIDR。 #### 配置入站流量的路由 从本地网络进入 AWS 的流量需要被引导到部署在集中化入站 VPC 中的 PrivateLink 端点。因此，此 VPC 中使用的子网属于公司范围可路由 IP 域，可以直接路由而不需 NAT 网关。 要实现在段之间直接路由，您需要使用 [段共享](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policy-network-actions-routes.html) 而非服务插入。后者，如其名称所示，用于在流量路径中插入服务，这不是这里的需求。 在入站段和混合段之间配置段共享让它们动态共享路由。这导致混合段学习集中化入站 VPC 的路由，而入站段学习本地网络的路由。 这建立了本地网络和集中化入站 VPC 之间的直接路径，这是预期的结果。如果您需要检查来自本地网络的流量，则可以创建一个单独的检查 VPC，并使用服务插入路由流量到它。这在帖子 [使用 AWS Cloud WAN 服务插入简化全局安全检查](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-global-security-inspection-with-aws-cloud-wan-service-insertion/) 中有所描述。 ### 多区域架构 虽然本帖专注于单区域实现，但所呈现的概念可以扩展到多区域部署。然而，对多区域架构的详细探讨超出了本讨论的范围。 # 注意事项 - AWS 可路由 IP 域可以在 AWS 外部重复使用，但不应在公司网络上公布。 - 如果 AWS 可路由 IP 域在 AWS 外部使用，则需要在出站和入站 NAT 后面。 - 考虑您的 DNS 解析，并确保 AWS 外部的资源不会将域名解析到 AWS 可路由 IP 域内的 IP 地址。 - NFG 不会从附加到它的 NAT VPC 中动态传播路由。您必须在其他段中配置静态路由指向 NAT VPC，以允许返回流量。 - 混合段从生产段动态学习 AWS 可路由 IP 域路由。确保这些路由不会公布到本地网络。 - 本帖中的路由表仅显示相关路由。其他路由可以动态学习，但不会影响路由。 # 结论 在本帖中，我们讨论了如何使用 AWS Cloud WAN 与服务插入来解决组织中私有 IPv4 地址耗尽的挑战。这里描述的架构让您通过使用仅在 AWS 环境中可路由的 IP 范围来创建一个可扩展平台。同时，您可以通过为整个区域集中聚合 NAT 资源而不是在工作负载 VPC 中部署它们来优化成本。此外，使用集中化入站 VPC 与 AWS PrivateLink 让您最大化可用可路由私有 IPv4 范围的使用。 # 作者介绍  ### Mehdi Dahane Mehdi 是 AWS 的网络专家解决方案架构师，支持全球账户，就云架构提供建议并开发解决方案，以实现预期结果并优化效率、操作和成本。他拥有超过 20 年的跨行业经验，涵盖广泛领域，包括公有和私有云环境、软件定义网络 (SDN)、全球连接性、安全和多租户环境。在不工作时，他可以被发现跑步或与家人和朋友享受户外活动。  ### Philipp Schaefer Philipp Schaefer 是 AWS 的首席解决方案架构师。他拥有超过 20 年的制造、医疗和能源行业软件设计经验，目前与 AWS 客户和合作伙伴合作推动他们的云转型计划。 <!-- AI_TASK_END: AI全文翻译 -->