亚马逊AWS官方博客

借助 Cloud Foundations 规划设计云上多区域网络轴辐拓扑结构一键部署东西南北流量分别或合并检查

云上多区域网络结构规划设计是构建云上运行环境不可或缺的重要一环。此项工作有几大难点。

一是高度定制化。和其他常规基础设施服务不同，网络规划和业务需求紧密相关，且每个用户都有不同的实际情况，大到不同区域之间 Amazon Transit Gateway 中转网关的联通关系，小到单个 Amazon VPC（以下简称 VPC）和子网的网段大小，都有千变万化的可能。而类似 Amazon CloudTrail 这样的基础服务不同客户之间的配置可能相差无几。

二是多区多账户。现代云上运行环境基本上是基于组织的多账户架构，而稍复杂的架构会同时管控多个亚马逊云科技区域的多个可用区。因此涉及云上网络资源在这“三多”背景下的互联互通和持续构建。我们今年 2 月的博客[1]介绍了如何在单区域环境下构建网络。本文会以多区域环境为背景介绍网络自动化构建的增强功能。

三是流量检查。网络安全方方面面，其中流量检查需要整体考虑，在网络规划初期就要介入。亚马逊云科技提供 AWS Network Firewall 网络防火墙和网关负载均衡器等服务协助配置检查。按可用区配置流量检查牵涉许多网络云资源，手动配置耗时费力且容易出错。本文会着重介绍流量检查自动适配的增强。

四是自动化部署。网络规划设计完毕后，如何快速有序部署多区域各项网络资源是另一大挑战。特别是在多区域环境下，对等连接建立和接收有先后依赖关系。此外诸如网络账户 VPC 流日志、中转网关流日志发送到安全账户 Amazon KMS 客户密钥加密的日志账户对应 Amazon S3 日志桶里相应前缀下此类繁杂工作，都会被妥当配置而无需您操心。

Cloud Foundations 提供共享网络联通和共享网关联通产品满足您网络定制化构建需求。代码化构建和自动化运维是 Cloud Foundations 的核心法宝。最近我们优化产品，提高定制灵活度，并进一步降低上述四点网络构建难度，助力您高效打造安全稳健和可扩展的云上网络环境。

网络产品新增功能一览

为满足客户更广更深更灵活的网络规划设计需求，切实减轻简化网络构建过程中的负担和过程，Cloud Foundations 最近在以下功能点进行优化和增强，主要聚焦解决上述四大痛点难点：

功能 之前功能 最近更新
私有子网数量 3 无限制
多区域部署 不支持 支持
中转网关对等连接 不支持 支持
中转网关路由表路由 支持，预置路由 支持，自定义路由
互联网出口集中管理 支持，无流量检查 支持，有流量检查
流量检查路由 不支持 支持，东西南北流量分别或合并检查
流量检查设备 不支持 支持，网络防火墙或网关负载均衡器
自定义安全组 不支持 支持
自定义网络访问控制列表 不支持 支持

以下章节就上述新增功能点结合常见网络结构定义规范进行逐一讲解讨论。其中有关自定义安全组和网络访问控制列表的功能属于 Cloud Foundations “产品工厂”的功能，与共享网络产品相辅相成，共同协助构建紧贴您实际业务需求的云上网络环境（有关产品工厂的应用简介可以参考我们 2023 年 9 月的博客[2]）。

轴辐拓扑结构

轴辐拓扑结构[3] （hub and spoke）顾名思义，即为中心辐射星状结构。除轴节点以外所有辐节点仅和轴节点连接。本文所述轴辐结构包含两个维度：

  1. 通过中转网关互联的 VPC 之间：网络地址转换 VPC 可视为轴 VPC，其他为辐 VPC；
  2. 通过中转网关对等连接互联的区域之间：主区域为轴区域，其他为辐区域；

网络结构定义优化调整

根据客户反馈和实际项目经验总结，我们对网络结构定义优化调整，更加便利网络定义和有效支持新增功能，包括：

  1. 增加属性：enable_tgw 支持仅创建 VPC 的情形；
  2. 增加属性：enable_nfw 支持配置网络防火墙，enable_gwlb 支持配置网关负载均衡器；
  3. 增加属性：peers 支持配置 VPC 对等连接；
  4. 变更属性名称：amazon_side_asn 调整为 asn，默认值 64512；
  5. 变更属性名称：create_igw 变更为 enable_igw，统一使用 enable 控制开关；
  6. 变更属性内容：tgw_cidr 调整为辐 VPC 公共网段，且不得为全网段 0.0.0.0/0；
  7. 变更属性类型：vpcs 和 tgw_route_tables 由数组变更为映射，便于调整项目位置而无需重新销毁创建资源；
  8. 删除属性：endpoint_vpc_index 和 nat_vpc_index，数组变更为映射后，无需通过索引定位；
  9. 变更属性限制：offsets 属性第一维数组长度不再限定，支持任意数量的私有子网，其中第一个是内部子网用于配置中转网关弹性网络接口，第二个为公有子网，从第三个开始都是私有子网；
  10. 增加属性：中转网关路由表增加 routes 映射，支持灵活定义中转网关路由表路由；

如果借用集合的包含关系，则辐 VPC 网段，公共网段和全网段关系可以表示为：辐 VPC 网段⊆公共网段⊂全网段，即公共网段不得等于全网段。中转网关路由表路由属性是映射，键值对取值范围为：

键 值
CIDR 无类别域间路由（网段） blackhole 黑洞路由
* 全网段 0.0.0.0/0 peer 中转网关对等连接挂载
VPC 名称 对应 VPC 网段 VPC 名称 对应 VPC 挂载
tgw 本区域公共网段
main 主区域公共网段
区域名称 该区域公共网段

除上述属性变更以外，另一大更新是增强网络地址转换 VPC 对网络流量的检查功能。通过适当开启网络设备达到不同的互联网出口集中管理和东西南北流量集中检查功能：

序号 场景 enable_nat enable_igw enable_nfw enable_gwlb
1 互联网出口集中管理 true true false false
2 网络防火墙东西检查 false false true false
3 网络防火墙南北检查 true true true false
4 网关负载均衡器东西检查 false false false true
5 网关负载均衡器南北检查 true true false true

场景六：东西南北流量分别检查，此时须在轴 VPC 南北流量检查基础上添加一个辐 VPC 并开启任一防护设备进行东西流量检查。两处检查设备可以相同，亦可相异。以下结合网络结构定义优化调整和新增功能，通过几个常见网络结构案例，说明其用法和注意事项。默认情况下，Cloud Foundations 会对中转网关开启设备模式支持，以确保出入流量通过对称路径路由。

VPC 对等连接

VPC 之间互联有对等连接和通过中转网关两种形式。对等连接一大优势为免费。当网络结构不复杂，互联数量不多，特别是成本优先时推荐使用。下图展示 4 个 VPC 两两互联的情形，相当于从 4 选 2 的组合。

网络定义示例如下。其中任意侧发起对等连接即可。按需配置公私子网，无需配置内部子网。

{
  "vpcs": {
    "vpc-1": {
      "cidr": "10.1.0.0/16",
      "offsets": [[], [], [[4, 1], [4, 2]]]
    },
    "vpc-2": {
      "cidr": "10.2.0.0/16",
      "peers": ["vpc-1"],
      "offsets": [[], [], [[4, 1], [4, 2]]]
    },
    "vpc-3": {
      "cidr": "10.3.0.0/16",
      "peers": ["vpc-1", "vpc-2"],
      "offsets": [[], [], [[4, 1], [4, 2]]]
    },
    "vpc-4": {
      "cidr": "10.4.0.0/16",
      "peers": ["vpc-1", "vpc-2", "vpc-3"],
      "offsets": [[], [], [[4, 1], [4, 2]]]
    }
  }
}

定义包含 4 个 VPC，分别是 VPC1（行 3 – 5），VPC2（行 7 – 10），VPC3（行 12 – 15），VPC4（行 17 – 20）。

互联网出口集中管理

对应场景一。之前 Cloud Foundations 的网络模块已经支持互联网出口集中管理，但是固化了中转网关部分路由。新增的 routes 属性支持中转网关路由表静态路由配置，更加灵活便捷。有关本场景的其他介绍资料可以参考官方网络白皮书[4]和这篇 2019 年 10 月的博客[5]。

出入境流量路径：

  1. 源自辐 VPC 私有子网的出境流量，经子网路由表全网段导入中转网关；
  2. 经辐 VPC 挂载关联中转网关流量检查前路由表，导入轴 VPC 挂载；
  3. 经轴 VPC 内部子路由表导入同可用区 NAT 网关，经互联网关出境；
  4. 返回流量经互联网关导入同可用区 NAT 网关；
  5. 经轴 VPC 公有子网路由表，公共网段流量导入中转网关；
  6. 经轴 VPC 挂载关联中转网关流量检查后路由表，导入辐 VPC 挂载；
  7. 最后，经辐 VPC 子网路由表本地路由导入流量目的地。

主要配置点为：

  1. 轴 VPC 设内公子网，私有子网可选；
  2. 轴 VPC 公有子网按可用区放置网络地址转换网关；
  3. 轴 VPC 公有子网路由表公共网段流量按可用区导入中转网关，全网段流量导入互联网关；
  4. 轴 VPC 内私子网路由表全网段流量按可用区导入网络地址转换网关；
  5. 辐 VPC 不设公有子网，内私子网路由表全网段流量导入中转网关；
  6. 中转网关流量检查前路由表 pre：
    • a) 所有辐 VPC 挂载关联至此表；
    • b) 轴 VPC 挂载无需传播至此表；
    • c) 添加路由，全网段流量导入轴 VPC 挂载；
    • d) 添加黑洞路由导入公共网段流量，使得辐 VPC 之间不能通信；
  7. 中转网关流量检查后路由表 post：
    • a) 轴 VPC 挂载关联至此表；
    • b) 所有辐 VPC 挂载传播至此表；
    • c) 手动配置其他网段流量导入对等连接、Amazon Direct Connect 专用网络连接或虚拟私有网络挂载；
{
  "vpcs": {
    "nat": {
      "cidr": "192.168.0.0/16",
      "enable_igw": true, "enable_nat": true,
      "offsets": [[[12, 0], [12, 1]], [8, 1], [8, 2]]]
    },
    "dev": {
      "cidr": "10.0.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "prod": {
      "cidr": "10.1.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "enable_tgw": true,
  "tgw_cidr": "10.0.0.0/8",
  "tgw_route_tables": {
    "pre": {
      "associations": ["dev", "prod"],
      "routes": { "*": "nat", "tgw": "blackhole" }
    },
    "post": { "associations": ["nat"], "propagations": ["dev", "prod"] }
  }
}

定义包含 3 个 VPC（行 2 – 14）和 2 个中转网关路由表（行 19 – 24）。

南北流量检查

对应场景三、五。在场景一“互联网出口集中管理”的基础上，于轴 VPC 配置私有子网并开启任意检查设备即可对互联网出入南北流量进行检查。

  • enable_nfw：配置亚马逊云科技网络防火墙，以安全账户客户托管密钥加密，其日志保存至日志账户对应桶和网络账户日志组。路由表按可用区直接使用网络防火墙终端节点。
  • enable_gwlb：配置网关负载均衡器以配合第三方防火墙设备使用，此时会继续配置 VPC 终端节点服务并最终按可用区配置 VPC 终端节点以供路由表使用。

以下用“网络防护设备终端节点”指代上述终端节点。您不可以同时开启两开关。官方白皮书对配置网络防火墙进行出[4]和入[4]流量检查，配置网关负载均衡器进行出[4]和入[4]流量检查都有相应章节介绍。这篇 2020 年 12 月的博客[6]也进行了全面分析。事实上以下配置除对南北流量进行检查外，东西流量也在轴 VPC 一并检查。后续章节会讨论东西南北流量分别检查的情形六。

南北流量路径：

  1. 源自辐 VPC 私有子网的出境流量，经子网路由表全网段导入中转网关；
  2. 经辐 VPC 挂载关联中转网关流量检查前路由表，导入轴 VPC 挂载；
  3. 经轴 VPC 内部子路由表导入同可用区防护设备终端节点；
  4. 检查完毕后，经私有子网路由表导入同可用区 NAT 网关，经公有子网互联网关出境；
  5. 返回流量经互联网关导入同可用区 NAT 网关；
  6. 经轴 VPC 公有子网路由表，公共网段流量导入同可用区防护设备终端节点；
  7. 检查完毕后，经私有子网路由表导入中转网关；
  8. 经轴 VPC 挂载关联中转网关流量检查后路由表，导入辐 VPC 挂载；
  9. 最后，经辐 VPC 子网路由表本地路由导入流量源头。

主要配置点为：

  1. 轴 VPC 设内公私子网；
  2. 轴 VPC 第一个私有子网按可用区放置防护设备终端节点；
  3. 轴 VPC 内部子网路由表全网段流量按可用区导入防护设备终端节点；
  4. 轴 VPC 私有子网路由表全网段流量按可用区导入网络地址转换网关，公共网段流量导入中转网关；
  5. 轴 VPC 公有子网路由表公共网段流量按可用区导入防护设备终端节点，全网段流量导入互联网关；
  6. 轴 VPC 互联网关路由表内部子网流量按可用区导入防护设备终端节点；
  7. 辐 VPC 不设公有子网，内私子网路由表全网段流量导入中转网关；
  8. 中转网关流量检查前路由表 pre：
    • a) 所有辐 VPC 挂载关联至此表；
    • b) 轴 VPC 挂载无需传播至此表；
    • c) 添加路由，全网段流量导入轴 VPC 挂载；
  9. 中转网关流量检查后路由表 post：
    • a) 轴 VPC 挂载关联至此表；
    • b) 所有辐 VPC 挂载传播至此表；
    • c) 手动配置其他网段流量导入对等连接、专用网络连接或虚拟私有网络挂载；
{
  "vpcs": {
    "nat": {
      "cidr": "192.168.0.0/16",
      "enable_igw": true, "enable_nat": true, "enable_gwlb": true,
      "offsets": [[[12, 0], [12, 1]], [[8, 1], [8, 2]], [[8, 3], [8, 4]]]
    },
    "dev": {
      "cidr": "10.0.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "prod": {
      "cidr": "10.1.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "enable_tgw": true,
  "tgw_cidr": "10.0.0.0/8",
  "tgw_route_tables": {
    "pre": { "associations": ["dev", "prod"], "routes": { "*": "nat" } },
    "post": { "associations": ["nat"], "propagations": ["dev", "prod"] }
  }
}

定义包含 3 个 VPC（行 2 – 14）和 2 个中转网关路由表（行 19 – 21）。

东西流量检查

对应场景二、四。在“南北流量检查”基础上，于轴 VPC 关闭网络地址转换网关和互联网关即可对云上网络内部东西流量进行检查。这篇 2020 年 11 月的博客[7]对东西流量检查进行了深入讨论。

东西流量路径：

  1. 源自辐 VPC 私有子网的出 VPC 流量，经子网路由表全网段导入中转网关；
  2. 经辐 VPC 挂载关联中转网关流量检查前路由表，导入轴 VPC 挂载；
  3. 经轴 VPC 内部子路由表导入同可用区防护设备终端节点；
  4. 检查完毕后，经私有子网路由表全网段导入中转网关；
  5. 经轴 VPC 挂载关联中转网关流量检查后路由表，导入目的辐 VPC 挂载；
  6. 最后，经辐 VPC 子网路由表本地路由导入流量目的地。

主要配置点为：

  1. 轴 VPC 设内私子网；
  2. 轴 VPC 第一个私有子网按可用区放置防护设备终端节点；
  3. 轴 VPC 内部子网路由表全网段流量按可用区导入防护设备终端节点；
  4. 轴 VPC 私有子网路由表公共网段流量按可用区导入中转网关；
  5. 辐 VPC 不设公有子网，内私子网路由表全网段流量导入中转网关；
  6. 中转网关流量检查前路由表 pre：
    • a) 所有辐 VPC 挂载关联至此表；
    • b) 轴 VPC 挂载无需传播至此表；
    • c) 添加路由，全网段流量导入轴 VPC 挂载；
  7. 中转网关流量检查后路由表 post：
    • a) 轴 VPC 挂载关联至此表；
    • b) 所有辐 VPC 挂载传播至此表；
    • c) 手动配置其他网段流量导入对等连接、专用网络连接或虚拟私有网络挂载；
{
  "vpcs": {
    "nat": {
      "cidr": "192.168.0.0/16",
      "enable_gwlb": true,
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "dev": {
      "cidr": "10.0.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "prod": {
      "cidr": "10.1.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "enable_tgw": true,
  "tgw_cidr": "10.0.0.0/8",
  "tgw_route_tables": {
    "pre": { "associations": ["dev", "prod"], "routes": { "*": "nat" } },
    "post": { "associations": ["nat"], "propagations": ["dev", "prod"] }
  }
}

定义包含 3 个 VPC（行 2 – 14）和 2 个中转网关路由表（行 19 – 21）。

东西南北流量分别检查

对应场景六。在“南北流量检查”的基础上，另设一检查辐 VPC 专门用于东西流量检查，而轴 VPC 则专门用于南北流量检查和流量出口。另设一辐入口 VPC 接受流入流量。此时可配置两个检查设备，产生排列四种检查组合：

序号 东西流量检查设备 南北流量检查设备
1 网络防火墙 网络防火墙
2 网络防火墙 网关负载均衡器
3 网关负载均衡器 网络防火墙
4 网关负载均衡器 网关负载均衡器

另一篇 2020 年 11 月的博客[8]在文章最后部分讨论了类似的双网络防护设备应用架构。

本场景中，东西流量通过检查辐 VPC 的防护设备检查，南北流量通过出口轴 VPC 的防护设备检查。流量路径与上述“南北流量路径”和“东西流量路径”相似，在此不再赘述。

出口轴 VPC 主要配置点为：

  1. 轴 VPC 设内公私子网；
  2. 轴 VPC 第一个私有子网按可用区放置防护设备终端节点；
  3. 轴 VPC 内部子网路由表全网段流量按可用区导入防护设备终端节点；
  4. 轴 VPC 私有子网路由表全网段流量按可用区导入网络地址转换网关，公共网段流量导入中转网关；
  5. 轴 VPC 公有子网路由表公共网段流量按可用区导入防护设备终端节点，全网段流量导入互联网关；
  6. 轴 VPC 互联网关路由表内部子网流量按可用区导入防护设备终端节点；
  7. 除出入口外的辐 VPC 不设公有子网，内私子网路由表全网段流量导入中转网关；
  8. 中转网关流量检查前路由表 pre：
    • a) 除检查外的其他辐 VPC 挂载关联至此表；
    • b) 出口轴 VPC 挂载无需传播至此表；
    • c) 检查辐 VPC 挂载无需传播至此表；
    • d) 添加路由，全网段流量导入出口轴 VPC 挂载；
    • e) 添加路由，公共网段流量导入检查辐 VPC 挂载；
  9. 中转网关流量检查后路由表 post：
    • a) 出口轴 VPC 挂载关联至此表；
    • b) 检查辐 VPC 挂载关联至此表；
    • c) 其他辐 VPC 挂载传播至此表；
    • d) 手动配置其他网段流量导入对等连接、专用网络连接或虚拟私有网络挂载；

检查辐 VPC 主要配置点为：

  1. 检查辐 VPC 设内私子网；
  2. 检查辐 VPC 第一个私有子网按可用区放置防护设备终端节点；
  3. 检查辐 VPC 内部子网路由表全网段流量按可用区导入防护设备终端节点；
  4. 检查辐 VPC 私有子网路由表全网段流量按可用区导入中转网关；

入口辐 VPC 主要配置点为：

  1. 入口辐 VPC 设内公子网；
  2. 入口辐 VPC 内部子网路由表全网段流量按可用区导入中转网关；
  3. 入口辐 VPC 公有子网路由表公共网段流量导入中转网关，全网段流量导入互联网关；
{
  "vpcs": {
    "inspect": {
      "enable_nfw": true,
      "cidr": "192.168.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "nat": {
      "cidr": "10.0.0.0/16",
      "enable_igw": true, "enable_nat": true, "enable_nfw": true,
      "offsets": [[[12, 0], [12, 1]], [[8, 1], [8, 2]], [[8, 3], [8, 4]]]
    },
    "ingress": {
      "cidr": "10.1.0.0/16",
      "enable_igw": true,
      "offsets": [[[12, 0], [12, 1]], [8, 1], [8, 2]]]
    },
    "dev": {
      "cidr": "10.2.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "prod": {
      "cidr": "10.3.0.0/16",
      "offsets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "enable_tgw": true,
  "tgw_cidr": "10.0.0.0/8",
  "tgw_route_tables": {
    "pre": {
      "associations": ["ingress", "dev", "prod"],
      "routes": { "*": "nat", "tgw": "inspect" }
    },
    "post": {
      "associations": ["inspect", "nat"],
      "propagations": ["ingress", "dev", "prod"]
    }
  }
}

定义包含 5 个 VPC（行 2 – 24）和 2 个中转网关路由表（行 29 – 36）。

多区域中转网关对等连接

我们增强了 Cloud Foundations 的网络组件支持多区域部署，并通过中转网关对等连接建立跨区域互联互通。参考前述新增中转网关路由表路由属性，可以建立以主区域中转网关为轴，管控区域中转网关为辐的跨区域网络轴辐拓扑结构。设计多区域网络结构时，结合您业务实际情况和工作负载对 IP 地址数量多寡的要求等，全局规划各区域、各 VPC 和各子网网段并做适当预留。在区域内各 VPC 之间和亚马逊云科技各区域中转网关之间两个层面，妥当设计网络资源互联互通关系。

主要配置点为：

  1. 管控区域分别与主区域建立对等连接，管控区域之间无对等连接；
  2. 区域内网络构建和上节“东西南北流量分别检查”相同，亦可相异；
  3. 主区域中转网关流量检查前路由表 pre：
    • a) 除检查外的其他辐 VPC 挂载关联至此表；
    • b) 出口轴 VPC 挂载无需传播至此表；
    • c) 检查辐 VPC 挂载无需传播至此表；
    • d) 所有中转网关对等连接挂载关联至此表；
    • e) 添加路由，全网段流量导入出口轴 VPC 挂载；
    • f) 添加路由，公共网段流量导入检查辐 VPC 挂载；
  4. 主区域中转网关流量检查后路由表 post：
    • a) 出口轴 VPC 挂载关联至此表；
    • b) 检查辐 VPC 挂载关联至此表；
    • c) 其他辐 VPC 挂载传播至此表；
    • d) 添加路由，管控区域流量导入相应对等连接挂载，通过区域名引用该区域公共网段；
    • e) 手动配置其他网段流量导入专用网络连接或虚拟私有网络挂载；
  5. 管控区域中转网关流量检查后路由表 post：
    • a) 添加路由，主区域流量导入对等连接挂载，通过 main 引用主区域公共网段；
{
  "vpcs": {
    "inspect": {
      "enable_nfw": true,
      "cidr": "100.0.0.0/16",
     "offsets": [[[12, 0], [12, 1]], [], [[12, 2], [12, 3]]]
    },
    "nat": {
      "cidr": "10.0.0.0/20",
      "enable_igw": true, "enable_nat": true, "enable_nfw": true,
      "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]], [[4, 3], [4, 4]]]
    },
    "ingress": {
      "cidr": "10.0.16.0/20",
      "enable_igw": true,
      "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]]]
    },
    "dev": {
      "cidr": "10.0.32.0/20",
      "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
    },
    "prod": {
      "cidr": "10.0.48.0/20",
      "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
    }
  },
  "enable_tgw": true,
  "tgw_cidr": "10.0.0.0/16",
  "tgw_route_tables": {
    "pre": {
      "associations": ["peer", "ingress", "dev", "prod"],
      "routes": { "*": "nat", "tgw": "inspect" }
    },
    "post": {
      "associations": ["inspect", "nat"],
      "propagations": ["ingress", "dev", "prod"],
      "routes": { "us-east-1": "peer", "us-west-1": "peer" }
    }
  },
  "us-east-1": {
    "asn": 64513,
    "vpcs": {
      "inspect": {
        "enable_nfw": true,
        "cidr": "100.1.0.0/16",
        "offsets": [[[12, 0], [12, 1]], [], [[12, 2], [12, 3]]]
      },
      "nat": {
        "cidr": "10.1.0.0/20",
        "enable_igw": true, "enable_nat": true, "enable_nfw": true,
        "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]], [[4, 3], [4, 4]]]
      },
      "ingress": {
        "cidr": "10.1.16.0/20",
        "enable_igw": true,
        "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]]]
      },
      "dev": {
        "cidr": "10.1.32.0/20",
        "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
      },
      "prod": {
        "cidr": "10.1.48.0/20",
        "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
      }
    },
    "enable_tgw": true,
    "tgw_peer": true,
    "tgw_cidr": "10.1.0.0/16",
    "tgw_route_tables": {
      "pre": {
        "associations": ["peer", "ingress", "dev", "prod"],
        "routes": { "*": "nat", "tgw": "inspect" }
      },
      "post": {
        "associations": ["inspect", "nat"],
        "propagations": ["ingress", "dev", "prod"],
        "routes": { "main": "peer" }
      }
    }
  },
  "us-west-1": {
    "asn": 64514,
    "vpcs": {
      "inspect": {
        "enable_nfw": true,
        "cidr": "100.2.0.0/16",
        "offsets": [[[12, 0], [12, 1]], [], [[12, 2], [12, 3]]]
      },
      "nat": {
        "cidr": "10.2.0.0/20",
        "enable_igw": true, "enable_nat": true, "enable_nfw": true,
        "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]], [[4, 3], [4, 4]]]
      },
      "ingress": {
        "cidr": "10.2.16.0/20",
        "enable_igw": true,
        "offsets": [[[8, 0], [8, 1]], [[4, 1], [4, 2]]]
      },
      "dev": {
        "cidr": "10.2.32.0/20",
        "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
      },
      "prod": {
        "cidr": "10.2.48.0/20",
        "offsets": [[[8, 0], [8, 1]], [], [[4, 3], [4, 4]]]
      }
    },
    "enable_tgw": true,
    "tgw_peer": true,
    "tgw_cidr": "10.2.0.0/16",
    "tgw_route_tables": {
      "pre": {
        "associations": ["peer", "ingress", "dev", "prod"],
        "routes": { "*": "nat", "tgw": "inspect" }
      },
      "post": {
        "associations": ["inspect", "nat"],
        "propagations": ["ingress", "dev", "prod"],
        "routes": { "main": "peer" }
      }
    }
  }
}

定义包含 3 个区域，其中有主区域（行 2 – 37）、美东区域（行 40 – 78）和美西区域（行 82 – 120）。

总结

本文主要介绍了 Cloud Foundations 近期对网络模块之改进增强，包括无限制的私有子网，VPC 对等连接，多区域部署及联通，含网络防火墙和网关负载均衡器的网络防护设备支持等。此外就东西南北流量检查的配置及架构，举例说明了六种互联互通和流量检查情形。相信上述网络结构和定义示例可以满足大部分网络构建需求。您可以结合本文及文中引用的其他文章，举一反三，构建更安全稳健，更加贴近您实际业务需求的网络结构。当然我们不得不承认，网络建设要求和结构千变万化，尽管 Cloud Foundations 网络模块提供了诸多属性和功能供您组合，有可能仍然不能满足您某些网络构建的要求。对此我们欢迎并期待您的反馈，并将持续优化和增强网络模块，以期支持建设更加广泛、深入、灵活、复杂的云上网络结构。

参考资料

  1. 博客：借助 Cloud Foundations 实现多账户组织云上网络环境两种共享模式的整体规划与一键部署，2023-02
  2. 博客：借助 Cloud Foundations 一键部署弹性堡垒机安全合规地实现会话管理及端口转发，2023-09
  3. AWS 可靠性支柱：REL02-BP04 轴辐式拓扑优先于多对多网格
  4. AWS 白皮书：Building a Scalable and Secure Multi-VPC AWS Network Infrastructure, 2023-07
  5. 博客：Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway, 2019-10
  6. 博客：Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway, 2020-12
  7. 博客：Introducing AWS Gateway Load Balancer: Supported architecture patterns, 2020-11
  8. 博客：Deployment models for AWS Network Firewall, 2020-11

本篇作者

袁文俊

亚马逊云科技专业服务部顾问。曾在亚马逊美国西雅图总部工作多年，就职于 Amazon Relational Database Service (RDS) 关系型数据库服务开发团队。拥有丰富的软件开发及云上运维经验。现负责业务持续性及可扩展性运行、企业应用及数据库上云和迁移、云上灾难恢复管理、云上良好架构框架等架构咨询、方案设计及项目实施工作。

刘育新

AWS ProServe 团队高级顾问，长期从事企业客户入云解决方案的制定和项目的实施工作。

张梦鑫

目前就职于亚马逊云科技专业咨询服务部门，专注于企业客户入云解决方案的设计和落地实施。在企业数据中心和云网络架构有丰富的实践经验，拥有 AWS Certified Advanced Networking Specialty 和 HCIE- Security 等网络技术相关认证。