亚马逊AWS官方博客

基于 AWS Cloud WAN 和 Amazon Transit Gateway 构建全球互联网络方案对比

随着企业的发展，客户对于云中网络的要求也在不断的提高。网络架构从传统的单 VPC 应用按照子网划分，到多 VPC 应用按照环境属性进行划分。应用部署也从单区域逐渐过渡到多区域，客户对于应用的访问不仅仅局限于对云上资源的访问，越多的客户想依托于亚马逊云科技全球骨干网络实现全球网络互联。但随之而来的问题是云中网络路由维护的复杂性和较弱的扩展性，客户比以往更希望能够降低基础架构的复杂性，使得其能够有足够的时间专注于业务；AWS 在 re:Invent 2021 发布了 AWS Cloud WAN （预览版）并在 2022 年 7 月 12 日正式推出；AWS Cloud WAN 是一种托管广域网（WAN）服务，可轻松构建、管理和监控连接云端和本地环境中运行的资源的全球网络，它提供了一种将客户数据中心、分支机构和云资源连接到一起的集中网络管理方法，降低了云上网络配置的复杂性。

AWS Cloud Wan 在 Network Manager 控制台中，包含以下几种对象：

  • 全球网络（Global Network）：充当网络对象的高级容器的单个网络。全球网络可以同时包含 AWS Transit Gateway 和其他 Cloud WAN 核心网络。
  • 核心网络（Core Network）：AWS 管理的全球网络的一部分。核心网络包括区域连接点和 attachment，截止目前为止 attachment 类型为 Site to Site VPN、Amazon VPC 、Connect （SD-WAN）、Transit Gateway Route Table。
  • 边缘站点（Edge locations）： 类似于 AWS Transit Gateway ，由 AWS 在每个区域中管理的区域连接点。
  • 段（Segment）：跨区域且名称唯一，段是隔离的路由域，默认情况下，只有同一网段内的 attachment 可以通信，也可以定义同一段之间的 attachment 具备隔离属性或将一个段共享给其他段实现路由共享。
  • 对等连接（Peering）：通过对等连接可将同一区域的 Edge location 和 Transit Gateway 通过路由表的方式进行关联。
  • 策略（Policy）：在 AWS Cloud WAN 中核心网络的配置通过策略文档实现，在策略文档中定义了 attachment 之间的网络连接策略及如何对网络中的流量分为不同的 Segment。

通过上述的基础概念的说明可以看到 Cloud WAN 中的网络流量模型更多的是以 Segment 作为基础，通过配置不同的 Segment 规则属性从而实现网络流量的控制。为了能够更好地了解 Cloud WAN 的原理和配置实现，分为单区域部署和多区域部署两种场景进行举例说明 Transit Gateway 和 Cloud WAN 的实现差异。

单区域部署场景

假设客户在新加坡拥有分支机构，客户的网络分为授信和非授信两个区域，非授信区域包含分支机构 Site to Site VPN 接入、互联网发布区域和互联网出口。信任区域包含生产应用部署区域和研发应用部署区域。

  • 需要具备统一的互联网出入口；
  • 互联网入口访问应用需要通过 IPS/WAF 实现互联网入口的 IPS 检测和防护；
  • 互联网出口需要通过安全设备实现基于 Domain 的访问控制；
  • 非授信区域到授信区域之间的访问默认禁止流量放行，只有经过审批的流量才可放行；
  • 授信区域之间的访问入向流量需要通过 IP 地址和端口协议控制，出向流量不做控制。

图一：客户网络需求图（单分支机构）

将客户的需求在云上进行实体化，使用 AWS 相关的服务进行构建，客户所需的网络要求汇总如下：

南北向流量：统一的互联网入口和出口，互联网进入流量需要经过 IPS 安全设备清洗，出互联网的流量需要经过 Domain 过滤，互联网出口网关使用 AWS NAT Gateway 实现单可用区最大的冗余；

东西向流量：授信和非授信区域之间的流量需要经过 4 层防火墙进行流量清洗，授信区域之间需要根据应用类型或者应用环境通过 IP 地址和端口进行实现访问控制；

安全产品使用： 客户使用第三方入侵防御软件实现互联网入口的 IPS 检测和防护，使用 AWS Network Firewall 控制云中的东西向流量和互联网出口的 Domain 控制。

Transit Gateway 的流量模型设计

根据单区域场景，将相关的网络环境根据 VPC 属性设定网络访问安全矩阵。

网络环境 非生产 VPC 生产 VPC 互联网服务发布 VPC 互联网出口和安全防护 VPC

分支机构

（DX/ipsec）
非生产 VPC 互通 互通 经过防火墙 经过防火墙 经过防火墙
生产 VPC 互通 互通 经过防火墙 经过防火墙 经过防火墙
互联网服务发布 VPC 经过防火墙 经过防火墙 N/A 经过防火墙 经过防火墙
互联网出口和安全防护 VPC 经过防火墙 经过防火墙 经过防火墙 N/A 经过防火墙

分支机构

（DX/ipsec）

 经过防火墙 经过防火墙 经过防火墙 经过防火墙 经过防火墙

根据上述的安全矩阵，将相关的网络区域分为 Trust/Untrust/Inspect 三个区域。

  • Trust 区域：包含非生产 VPC、生产 VPC，他们之间访问互通；
  • Untrust 区域：包含分支机构接入以及互联网发布 VPC，他们访问应用网络需要经过防火墙；
  • Inspect 区域：包含互联网出口和安全防护 VPC ，用于东西向流量的管控和互联量流量出口控制。
区域 Attachment（附件） Next Hop（流量下一跳） Target（目标网络）
Trust 非生产 VPC 0.0.0.0/0 互联网出口和安全防护  VPC（静态路由）
生产 VPC 非生产 VPC CIDR 非生产 VPC
TGW 对等连接 生产 VPC CIDR 生产 VPC
Untrust 分支机构（DX/Site to Site） 0.0.0.0/0 互联网出口和安全防护 VPC（静态路由）
互联网服务发布 VPC
Inspect 互联网出口和安全防护 VPC 互联网服务发布 VPC CIDR 互联网服务发布 VPC
非生产 VPC CIDR 非生产 VPC
生产 VPC CIDR 生产 VPC
分支机构（DX/Site to Site） CIDR 分支机构（DX/Site to Site）

整个网络架构实现图如下：

图二：单区域 Transit Gateway 网络架构图

Cloud WAN 的流量模型设计

上述架构可同样采用 Cloud WAN 实现，在 Cloud WAN 中分段代表应用安全检查的自然隔离边界。将上述的需求进行网络分段并设定对应的安全矩阵。

网络环境按照段进行划分：

段名称 包含的 VPC 是否隔离 编号
ingress 互联网服务发布 VPC 唯一 100
workload

非生产 VPC

生产 VPC

 否 200
inspect 互联网出口和安全防护 VPC 唯一 300
edge 分支机构接入网络 隔离 400

段和段之间的网络访问安全矩阵：

段名称 workload edge ingress inspect
workload 互通 经过 inspect 经过 inspect 互通
edge 经过 inspect 隔离 经过 inspect 互通
ingress 经过 inspect 经过 inspect N/A 互通
Inspect 互通 互通 互通 互通

从上述的安全矩阵中可以得出以下配置信息：

段共享配置

  • edge、workload、ingress 三个段和 inspect 段共享，使得 inspect 段中具有这 3 个段所有 attachment 的路由。

静态路由配置

  • edge 段的 0.0.0/8 下一跳为 inspect 段
  • workload、ingress 两个段的默认路由（0.0.0）下一跳为 inspect 段

图三：单区域 Cloud WAN 网络架构图

Cloud WAN 策略示例（Json）：

{
  "version": "2021.12",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "asn-ranges": [
      "64512-64555"
    ],
    "edge-locations": [
      {
        "location": "ap-southeast-1",
        "asn": 64513
      }
    ]
  },
  "segments": [
    {
      "name": "inspect",
      "require-attachment-acceptance": false
    },
    {
      "name": "edge",
      "require-attachment-acceptance": false,
      "isolate-attachments": true,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "ingress",
      "require-attachment-acceptance": false,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "apparea",
      "require-attachment-acceptance": false,
      "deny-filter": [
        "inspect"
      ]
    }
  ],
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "edge",
      "destination-cidr-blocks": [
        "10.0.0.0/8"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62"
      ]
    },
    {
      "action": "create-route",
      "segment": "apparea",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62"
      ]
    },
    {
      "action": "create-route",
      "segment": "ingress",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62"
      ]
    },
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "inspect",
      "share-with": [
        "edge",
        "apparea",
        "ingress"
      ]
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 200,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "apparea"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "apparea"
      }
    },
    {
      "rule-number": 100,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "ingress"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "ingress"
      }
    },
    {
      "rule-number": 300,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "inspect"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "inspect"
      }
    },
    {
      "rule-number": 400,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "edge"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "edge"
      }
    }
  ]
}

多区域部署场景

将上述场景进行扩展，假设客户的分支机构遍布全球且云中应用根据延迟和其他因素部署在多个区域，区域内部的 VPC 数量和网络安全和单区域部署场景一致。客户要求依托 AWS 骨干网实现全网互通，且需要在云中提供较高安全的防护策略实现接入方之间的流量可在云中细粒度的管控；

Transit Gateway 的流量模型设计

由于 Transit Gateway 为区域属性，当多区域需要区域时不同区域之间的 Transit Gateway 网络联通模式有两种选择模式，采用 Full-Mesh 的架构模式或 Hub-Spoke 模式。

图四：Full-Mesh 模式下的 Transit Gateway 组网

图五：Hub-Spoke 模式下的 Transit Gateway 组网

采用以上两种模式的优缺点如下：

当采用 Full-Mesh 架构时，所有 Transit Gateway 之间需要建立对等关系，对等连接的数量为一个等差数列，根据等差数列求和公式所需创建的对等连接数量为 n（n-1）/2 ，其中 n 代表 Transit Gateway 的数量。由于 Transit Gateway 对等连接自身不支持动态路由，所需需要在 Transit Gateway 关联对等连接的路由表中手工创建对端所需的静态路由，在不考虑将路由进行汇聚的情况下数量为（n-1）* VPC 数量。但由于对等连接会优选底层链路所以两个区域之间延迟最低。

当采用 Hub-Spoke 架构时，可以根据地理位置或者延迟选择其中几个区域做为 Hub 区域，Hub 区域之间 Full-Mesh，其他区域根据延迟分别和设定的 Hub 区域建立对等连接，从而构建 Hub-Spoke 模式，对等链接的数量为 N。但由于不同 Hub 区域之间的互联首先需要经过 Hub 区域之间的对等链接延迟会有所增加。

两者之间组网模式的优缺点如下表：

组网模式 对等连接数量 静态路由数量/区域 访问延迟 成本 冗余性
Full-mesh N（N-1）/2 （N-1）个区域所包含的所有 VPC 总数量，并需要确保所有路由正确无误 直接通过骨干网进行通讯，路径最优

附件所需成本高；

流量传输需经过多个 Region 成本低；

 区域故障不影响其他区域之间互联
Hub-Spoke N （N-1）个区域所包含的所有 VPC 总数量，并需要确保所有路由正确无误 同属于不同 Hub 区域的应用互访需经过所在 Hub 区域导致延迟有所增加

附件所需成本低；

流量传输需经过多个 Region 成本较高；

 Hub 区域故障会影响其他 Spoke 区域之间的互联

当考虑线下数据中心采用 DXGW 方式接入到云中网络时，由于每个 DXGW 最多可以连接 3 个 AWS Transit Gateway 且 DXGW 的前缀数不能重叠。所以在单 DXGW 的前提下无论选择上述哪种组网方式为了实现区域互联都需要将其中一些区域做为 Hub 区域使用，其他的区域作为 Spoke 区域，并为了实现区域之间的全网互通配置大量的静态路由。参见多区域（超过3个）的 Transit Gateway 和 DXGW 的互联。

为了简化管理和配置，接下来将以多区域 Hub-Spoke 的部署模型进行考虑云上所需构建的流量模型。

Transit Gateway 的流量模型设计

首先将相关的网络环境根据 VPC 属性设定网络访问安全矩阵。

网络环境 非生产 VPC 生产 VPC TGW 对等连接 互联网服务发布 VPC 互联网出口和安全防护 VPC

分支机构

（DX/ipsec）
非生产 VPC 互通 互通 互通 经过防火墙 经过防火墙 经过防火墙
生产 VPC 互通 互通 互通 经过防火墙 经过防火墙 经过防火墙
TGW 对等连接 互通 互通 互通 经过防火墙 经过防火墙 经过防火墙
互联网服务发布 VPC 经过防火墙 经过防火墙 经过防火墙 N/A 经过防火墙 经过防火墙
互联网出口和安全防护 VPC 经过防火墙 经过防火墙 经过防火墙 经过防火墙 N/A 经过防火墙

分支机构

（DX/ipsec）

 经过防火墙 经过防火墙 经过防火墙 经过防火墙 经过防火墙 经过防火墙

根据上述的安全矩阵，同样将相关的网络区域分为 Trust / Untrust / Inspect 三个区域。

  • Trust 区域：包含非生产 VPC、生产 VPC，TGW 对等连接，他们之间访问互通；
  • Untrust 区域：包含分支机构接入以及互联网发布 VPC，他们访问应用网络需要经过防火墙；
  • Inspect 区域：包含互联网出口和安全防护 VPC ，用于东西向流量的管控和互联量流量出口控制。
区域 Attachment（附件） Next Hop（流量下一跳） Target（目标网络）
Trust 非生产 VPC 0.0.0.0/0 互联网出口和安全防护 VPC（静态路由）
生产 VPC 非生产 VPC CIDR 非生产 VPC
TGW 对等连接 生产 VPC CIDR 生产 VPC
TGW 对等连接 其他区域的 CIDR 汇总 （静态路由）
Untrust 分支机构（DX/Site to Site） 0.0.0.0/0 互联网出口和安全防护 VPC （静态路由）
互联网服务发布 VPC
Inspect 互联网出口和安全防护 VPC 互联网服务发布 VPC CIDR 互联网服务发布 VPC
非生产 VPC CIDR 非生产 VPC
生产 VPC CIDR 生产 VPC
分支机构（DX/Site to Site） CIDR 分支机构（DX/Site to Site）
TGW 对等连接 其他区域的 CIDR 汇总 （静态路由）

整个网络架构实现图如下：

图六：多区域 Transit Gateway 互联网络架构图

上述架构局限性：

  • AWS DXGW 只能 Associate 到 3 个 Transit Gateway，其他的 Region 和线下 DC 之间的互通需要通过 TGW Inter-region 对等连接完成；
  • 截止目前为止 TGW Inter-region 对等连接只支持静态路由。当不同 Hub Region 后端的 Spoke Region 需要进行通讯时流量需要绕回至 Hub Region，会有较大的延迟开销；如考虑在不同 Hub Region 的 Spoke Region 之间的互通会有更大的复杂程度；
  • 同时为了实现 Client VPN 拨入拥有独立的 IP 且和分支机构可以互访需要在整个云中网络中配置静态路由从而实现不同 Client 接入端之间的网络联通。

将上述架构使用 Cloud WAN 进行实现，为了体现不同区域或者 VPC 之间的东西向流量管控对于架构复杂程度的影响，将分为 2 个场景进行说明：

  • Cloud WAN 的流量模型设计 – （Ingress/Egress 流量管控，东西向流量通过安全组/ACL 控制）
  • Cloud WAN 的流量模型设计 – （Ingress/Egress 流量管控，东西向流量通过有状态防火墙控制）

Cloud WAN 的流量模型设计 –（Ingress/Egress 流量管控，东西向流量默认互通）

当使用 Cloud WAN 产品只对 Ingress 和 Egress 流量进行控制时，通过段的划分和自身的隔离属性使得云上网络设计变得非常简单。

网络环境按照段进行划分：

段名称 包含的 VPC 是否隔离 编号
ingress 互联网服务发布 VPC 隔离 100
workload

非生产 VPC

生产 VPC

 否 200
inspect 互联网出口和安全防护 VPC 隔离 300
edge 分支机构接入网络 隔离 400

段和段之间的网络访问安全矩阵：

段名称 workload edge ingress inspect
workload 互通 互通 互通 互通
edge 互通 互通 否 否
ingress 互通 否 否 互通
Inspect 互通 否 互通 否

提示，当配置段静态路由时，如段的目标有多个区域的 attachment，优选同一个 CNE 附件作为路由下一跳。从上述的安全矩阵中可以得出以下配置信息：

段共享配置

  • workload、edge 段之间共享
  • workload、ingress 段之间共享
  • workload、ingress 两个段和 inspect 共享

静态路由配置

  • workload、ingress 两个段的默认路由（0.0.0）下一跳为 inspect 段

图七：多区域 Cloud WAN 网络架构图（Ingress/Egress 流量管控，东西向流量默认互通）

Cloud WAN 策略示例（Json）：

{
  "version": "2021.12",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "asn-ranges": [
      "64512-64555"
    ],
    "edge-locations": [
      {
        "location": "ap-southeast-1",
        "asn": 64513
      },
      {
        "location": "eu-central-1",
        "asn": 64514
      }
    ]
  },
  "segments": [
    {
      "name": "inspect",
      "require-attachment-acceptance": false,
      "isolate-attachments": true
    },
    {
      "name": "edge",
      "require-attachment-acceptance": false,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "ingress",
      "require-attachment-acceptance": false,
      "isolate-attachments": true,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "workload",
      "require-attachment-acceptance": false,
      "deny-filter": [
        "inspect"
      ]
    }
  ],
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "workload",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62",
        "attachment-0356cf1e54fa3db5a"
      ]
    },
    {
      "action": "create-route",
      "segment": "ingress",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62",
        "attachment-0356cf1e54fa3db5a"
      ]
    },
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "inspect",
      "share-with": [
        "ingress",
        "workload"
      ]
    },
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "edge",
      "share-with": {
        "except": [
          "inspect"
        ]
      }
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 200,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "workload"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "workload"
      }
    },
    {
      "rule-number": 100,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "ingress"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "ingress"
      }
    },
    {
      "rule-number": 300,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "inspect"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "inspect"
      }
    },
    {
      "rule-number": 400,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "edge"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "edge"
      }
    }
  ]
}

 Cloud WAN 的流量模型设计 — （Ingress/Egress 流量管控，东西向流量管控）

将 Cloud WAN 多区域架构进行再次演进为东西向流量管控，由于 Segment 的定义为隔离的路由域，所以默认段中的 attachment 会学习到其他 attachment 的路由信息，当需要对东西向流量进行管控的时候就需要考虑将 Segment 进行拆分从而实现更为精确的流量控制。假设以新加坡、法兰克福 2 个区域之间实现东西向流量的管控完成段和网络访问安全矩阵的配置：

网络环境按照段进行划分：

Segment 包含的 VPC 是否隔离 编号
ingress 互联网服务发布 VPC 唯一 100
workload2sin

新加坡区域

非生产 VPC

生产 VPC

 否 200
workload2frn

法兰克福区域

非生产 VPC

生产 VPC

 否 201
inspect2sin

新加坡区域

互联网出口和安全防护 VPC

 唯一 300
inspect2frn

法兰克福区域

互联网出口和安全防护 VPC

 唯一 301
edge2sin

新加坡区域

分支机构接入网络

 不同接入之间隔离 400
edge2frn

法兰克福区域

分支机构接入网络

 不同接入之间隔离 401

段和段之间的网络访问安全矩阵：

段名称 ingress workload2sin workload2frn inspect2sin inspect2frn edge2sin edge2frn
Ingress (见说明) N/A inspect2sin/inspect2frn inspect2sin/inspect2frn inspect2sin/inspect2frn inspect2sin/inspect2frn inspect2sin/inspect2frn inspect2sin/inspect2frn
workload2sin inspect2sin/inspect2frn 互通 互通 互通 N/A 过 inspect2sin 过 inspect2frn
workload2frn inspect2sin/inspect2frn 互通 互通 N/A 互通 过 inspect2sin 过 inspect2frn
inspect2sin inspect2sin/inspect2frn 互通 过 inspect2frn N/A N/A 互通 过 inspect2frn
inspect2frn inspect2sin/inspect2frn 过 inspect2sin 互通 N/A N/A 过 inspect2sin 互通
edge2sin inspect2sin/inspect2frn 过 inspect2sin

过 inspect2sin

过 inspect2frn

 互通 过 inspect2sin 过 inspect2sin

过 inspect2sin

过 inspect2frn
edge2frn inspect2sin/inspect2frn

过 inspect2frn

过 inspect2sin

 过 inspect2frn 过 inspect2frn 互通

过 inspect2frn

过 inspect2sin

 过 inspect2frn

说明：由于 ingress 并没有按照区域进行拆分为不同的段，当配置段静态路由时，如段的目标有多个区域的 attachment，优选同一个 CNE attachment 作为路由下一跳。inspect2sin/inspect2frn 表示如果 ingress 访问当前本区域的 workload 段只会过当前区域的 Inspect 安全段。

从上述的安全矩阵中可以得出以下配置信息：

段共享配置

  • workload2frn、workload2sin 段之间共享
  • workload2frn、ingress、edge2frn与inspect2frn 段之间共享
  • workload2sin、ingress、edge2sin与inspect2sin 段之间共享

静态路由配置

  • workload2frn 默认路由（0.0.0）下一跳为 inspect2frn
  • workload2sin 默认路由（0.0.0）下一跳为 inspect2sin
  • edge2frn 10.0.0.0/8 下一跳为 inspect2frn
  • edge2sin 10.0.0.0/8 下一跳为 inspect2sin
  • ingress 默认路由（0.0.0）下一跳为 inspect2frn 和 inspect2sin 段
  • inspect2frn 到新加坡区域的汇聚路由（例如 0.0.0/9）下一跳为 inspect2sin
  • inspect2sin 到新加坡区域的汇聚路由（例如 128.0.0/9）下一跳为 inspect2frn

图八：多区域 Cloud WAN 网络架构图（Ingress/Egress 流量管控，东西向流量管控）

对上述架构进行测试

测试场景：新加坡、法兰克福两个 CNE 站点接入的客户端互访

测试主机：10.4.0.53（接入到新加坡 CNEs 的 Site to Site VPN）； 10.134.2.43（接入到法兰克福 CNEs 的 Site to Site VPN）

测试方式：采用 ping 命令并检测流量经过不同区域的防火墙，相关信息在 alert 中体现。

流量发起和接收截图

源端发起 ping 命令

图九：源端发起 ping 命令

接受端查看数据包来源

图十：目标端查看数据包来源

防火墙流量日志

inspect2sin 防火墙日志

图十一：靠近源端的防火墙日志信息

inspect2frn 防火墙日志

图十二：靠近目标端的防火墙日志信息

Cloud WAN 策略示例（Json）：

{
  "version": "2021.12",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "asn-ranges": [
      "64512-64555"
    ],
    "edge-locations": [
      {
        "location": "ap-southeast-1",
        "asn": 64513
      },
      {
        "location": "eu-central-1",
        "asn": 64514
      }
    ]
  },
  "segments": [
    {
      "name": "inspect",
      "require-attachment-acceptance": false,
      "isolate-attachments": true
    },
    {
      "name": "edge",
      "require-attachment-acceptance": false,
      "isolate-attachments": true,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "ingress",
      "require-attachment-acceptance": false,
      "isolate-attachments": true,
      "deny-filter": [
        "inspect"
      ]
    },
    {
      "name": "workload",
      "require-attachment-acceptance": false,
      "deny-filter": [
        "inspect"
      ]
    }
  ],
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "edge",
      "destination-cidr-blocks": [
        "10.0.0.0/8"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62",
        "attachment-0356cf1e54fa3db5a"
      ]
    },
    {
      "action": "create-route",
      "segment": "workload",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62",
        "attachment-0356cf1e54fa3db5a"
      ]
    },
    {
      "action": "create-route",
      "segment": "ingress",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-06a20b52b087fee62",
        "attachment-0356cf1e54fa3db5a"
      ]
    },
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "inspect",
      "share-with": [
        "edge",
        "workload",
        "ingress"
      ]
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 200,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "workload"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "workload"
      }
    },
    {
      "rule-number": 100,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "ingress"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "ingress"
      }
    },
    {
      "rule-number": 300,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "inspect"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "inspect"
      }
    },
    {
      "rule-number": 400,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "segment",
          "value": "edge"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "edge"
      }
    }
  ]
}

截止目前为止 Cloud WAN 还存在以下限制：

  • 暂不支持原生的 Direct Connect attachment，需要使用 Transit Gateway 作为两者之间的桥梁。通过 Direct Connect attachment 将 Direct Connect Gateway 与 Transit Gateway 互连后再将 Transit Gateway 于 Cloud WAN 配置对等连接；
  • 暂时不支持多播功能。

Transit Gateway 和 Cloud WAN 集成的一些注意事项：

  • Transit Gateway 和 Cloud WAN 之间的对等互连仅在同一区域中受支持，不支持跨区域建立。
  • 由于 Cloud WAN 在对等连接上使用动态路由/边界网关协议（BGP）。需要 Transit Gateway 和 Cloud WAN BGP 自治系统编号（ASN）不冲突。
  • 将 Transit Gateway 附件到 Cloud WAN 是通过 Transit Gateway 的路由表实现，前置条件是 Transit Gateway 和 Cloud WAN 之间建立对等连接。附件创建成功后会在 Transit Gateway 中创建一个 Transit Gateway 策略表，Transit Gateway 策略表关联的附件无法传播或通过静态路由添加到其他 Transit Gateway 路由表中。
  • 出现在 Transit Gateway 路由表中的任何路由都会通过 Cloud WAN 段动态通告到映射到同一段的其他 Transit Gateway，且映射仅对单个 Transit Gateway 路由表（TGW-RT）有效。Transit Gateway 和 Cloud WAN的对等连接不能传播到 Transit Gateway 的其他路由表中。
  • 当流量通过 Transit Gateway 离开 VPC，又通过 Cloud WAN 连接返回 VPC 时。只有路径中不经过涉及会话保持的有状态的网络服务（例如防火墙）非对称网络流量才可以工作。

在不考虑成本的前提下，Transit Gateway 和 Cloud Wan 选择：

  • 如果有应用需要多播支持，Transit Gateway 是最优的选择。
  • Cloud WAN 配置具备云原生的版本管理功能，当架构部署存在差异时可随时回退。
  • 在进行东西向流量管控时管控的细粒度越高所需要配置的静态路由越多也就越复杂，Cloud WAN 更多的目的是实现一个大的网络平面，而 Transit Gateway 反而对于流量的控制会更灵活。
  • 当互联区域比较少（例如 1-3）个时，如果做区域全网互联使用 Transit Gateway 是一个比较好的选择。
  • 当互联区域较多（大于 3）个时，且流量不需要做东西向管控时使用 Cloud WAN 是一个比较好的选择，并且 Cloud WAN 段内的访问控制最好通过 ACL 或安全组。如果涉及到东西向流量管控需要充分考虑场景的复杂度再进行择优选择。
  • 为了使得管理界面更为清晰，当企业存在多区域互联但在区域内有精细化管理需求的最佳实践，可使用 TGW 作为区域内部的 CE，负责处理区域内的流量转发和流量管控，TGW 上行再接 CNE 负责出区域的骨干网流量的转发和管理。

参考文档：

本篇作者

崔新岩

目前就职于亚马逊云科技专业服务部门，专注于企业客户入云解决方案的设计和落地实施。

黄敢

目前就职于亚马逊云科技专业服务部门，专注于企业整体云上基础设施架构设计、云上灾备/迁移方案设计、最佳实践以及落地实施。

刘瀚文

高级产品技术专家，亚马逊云科技产品部网络方向。负责基于 AWS 的云计算网络方案架构的咨询和设计，现致力于网络和 Network-as-a-Service 相关领域的研究。在加入 AWS 之前，在思科中国担任高级系统工程师，负责运营商方案咨询和架构设计，在运营商组网和大企业基础网络方面有丰富经验。