亚马逊AWS官方博客

借助 Cloud Foundations 实现多账户组织云上网络环境两种共享模式的整体规划与一键部署

亚马逊云科技提供了丰富的网络服务与组件,让您可以灵活定义各种各样的网络拓扑结构,满足业务应用的不同需求。主要的网络服务与组件包括 Amazon Virtual Private Cloud (Amazon VPC) 及其关联的流日志、子网、路由表、终端节点、网络地址转换网关、互联网关、Amazon Transit Gateway 中转网关、中转网关路由表及其挂载、关联和传播,Amazon Route 53 托管区域等等。另一方面,无论该组织是基于 Amazon Organizations 的或是自行管理的虚拟组织,多账户组织云上运行环境成为越来越多用户上云的不二选择。网络相关服务组件多和亚马逊云科技账户多的“两多”情形,使得构建云上网络环境的学习曲线陡增,部署过程低效,测试排查困难。如何对组织整体网络拓扑结构进行简洁定义,然后对所定义网络资源高效部署到所涉账户,是本文试图解决的问题。

借助亚马逊云科技的 Cloud Foundations 解决方案,您可以专注于多账户组织云上网络环境的拓扑结构与规划设计,把剩下繁杂的网络资源创建及配置工作交予 Cloud Foundations 通过自动化方式完成。

共享网络资源

在多账户组织构建云上网络环境,按照共享网络资源类别,可以分为两种共享模式:

  • 共享网关联通:在网络账户创建中转网关并共享至成员账户,在成员账户创建 VPC 并挂载至共享中转网关,在网络账户基于 VPC 挂载配置中转网关路由表的关联和传播。共享中转网关没有对组织的限制,故该方法即适用于使用 Amazon Organizations 的情形,也适用于虚拟组织情形;
  • 共享网络联通:在网络账户创建中转网关和所有 VPC 及其相关资源,并配置中转网关的 VPC 挂载、路由表关联和传播,共享子网至相应成员账户。子网只能在 Amazon Organizations 组织范围内共享,故不适用于虚拟组织情形。默认情况下一个账户可以拥有 5 个 VPC。如果不够可以申请提升限额

我们用下表把上述两种模式归纳对比:

共享模式 共享网关联通 共享网络联通
共享资源 中转网关 子网
适用情形 Amazon Organizations 组织或者虚拟组织 Amazon Organizations 组织
拓扑结构 分散管理 VPC 集中管理  VPC
模式特色 成员账户拥有 VPC 所有控制权 不同账户可使用相同子网
运维管理 较难 较易

两种共享模式没有绝对的优劣之别,您可以根据业务实际进行选择。如果您不依赖 Amazon Organizations 管理组织,则只能使用共享网关联通。如果依赖,鉴于共享网络联通集中管理 VPC 的拓扑结构,在运维管理可能会相对容易和高效。在共享网络联通中如果一个子网共享给多个账户,需要注意地址重叠的问题。

Cloud Foundations 支持依赖 Amazon Organizations 组织管理多账户,也支持自行管理的虚拟组织。Cloud Foundations 也同时支持上述两种网络共享模式,满足您个性化的业务场景和负载要求。

局限性

本解决方案暂不包含对以下问题的解决:

  • 基于互联网协议第六版 IPv6 的地址;
  • 混合共享联通,即同时共享中转网关和子网的混合网络拓扑结构;
  • 云下云上网络联通,无论通过 Amazon Direct Connect 专用网络连接还是其他第三方解决方案;

解决方案概览

要规划设计一个良好结构的多账户云上网络环境可谓千头万绪。需要基于现实的业务需求,并对业务中短期发展适度超前预估。从 VPC、子网的网段分配开始,逐一设计路由表路由,各类网关联通,各 VPC 基于中转网关路由表的联通和隔离。此外从降本增效的角度,还要考虑接口终端节点网络地址转换 (NAT) 网关的集中管理。规划设计之后,对所有资源逐一创建和配置,如果不借助自动化工具,又是一个耗时费力的漫长过程。

我们从规划和部署两方面分别简化。规划方面,利用 JSON 格式定义一个简洁的框架,一目了然的整体定义所有上述 VPC 及关联资源和 VPC 间的联通关系。部署方面,利用 Cloud Foundations 的流水线工厂产品,一键部署 JSON 格式定义的所有网络资源、共享资源并记录 VPC 和中转网关的流日志到日志账户。对于约十几个 VPC 规模的网络而言,部署时间在分钟级别,而手动部署则至少在小时级别。

有关 Cloud Foundations 的总架构图和设计思想可以参考《快速构建安全规范和架构完善的云上多账户运行环境》。

共享网络联通

我们先以“共享网络联通”示例,再阐述与“共享网关联通”的异同。下图展示了 5 个 VPC、1 个中转网关和 2 张中转网关路由表的共享网络拓扑结构。其中开发子网通过 Amazon Resource Access Manager (Amazon RAM) 共享至开发账户 1,生产子网共享至生产账户 1 和 2,日志子网共享至日志账户。开发、生产、日志 VPC 可以访问接口终端节点、网络地址转换 VPC,反之亦然。但是开发、生产、日志 VPC 之间不能互相访问。您可根据业务实际需求,参考中转网关文档,规划设计各 VPC 之间联通隔离管控措施,并通过中转网关路由表实施。

我们以 Terraform 的 Amazon VPC 公共模块为基础构建 VPC 及其关联资源。该模块简洁规范的创建并配置 VPC,适用于大部分通用场景。为了简洁定义各子网网段即无类别域间路由 (CIDR),我们基于 Terraform 的 cidrsubnet 函数引入“网段偏移量”的概念。通过网段偏移量,易于展示各子网网段在不同 VPC 内相似的偏移关系,便于比较和查错。试比较下列两组子网网段:

类型 子网 1 (VPC: 10.30.16.0/20) 子网 2 (VPC: 10.30.32.0/20)
可用区 A 可用区 B 可用区 A 可用区 B
公有 10.30.16.0/23 10.30.18.0/23 10.30.32.0/23 10.30.34.0/23
私有 10.30.20.0/23 10.30.22.0/23 10.30.36.0/23 10.30.38.0/23
数据库 10.30.24.0/23 10.30.26.0/23 10.30.40.0/23 10.30.42.0/23
中转网关 10.30.28.32/28 10.30.28.48/28 10.30.44.32/28 10.30.44.48/28

初看两组网段,可以发现其中的某种规律和内在联系,例如网段除最后一行在第三位等差递增,但是两组子网网段之间的联系还是比较模糊。如果前缀长度是奇数,则这样的规律和联系可能更不明显。以子网所在 VPC 的无类别域间路由 (CIDR) 为基础计算网段偏移量,试比较:

类型 子网 1 (VPC: 10.30.16.0/20) 子网 2 (VPC: 10.30.32.0/20)
可用区 A 可用区 B 可用区 A 可用区 B
公有 (3, 0) (3, 1) (3, 0) (3, 1)
私有 (3, 2) (3, 3) (3, 2) (3, 3)
数据库 (3, 4) (3, 5) (3, 4) (3, 5)
中转网关 (8, 194) (8, 195) (8, 194) (8, 195)

可以发现两组子网网段偏移量完全一致。这样一目了然的偏移量联系有利于更高效的规划网络,便于发现相应子网规划不一致的情况。

定义网络结构

按照 JSON 格式,根据下述规则定义网络联通。对于数组类型,建议您保持数组中元素位置稳定,以避免 Terraform 销毁和重建资源。一级属性有:

属性 类型 默认值 说明
1 amazon_side_asn int 64512 亚马逊云科技自治系统号
2 endpoint_vpc_index int N/A 接口终端节点专属 VPC 的数组索引,-1 表示不启用,不能与其他索引相同
3 nat_vpc_index int N/A 网络地址转换专属 VPC 的数组索引,-1 表示不启用,不能与其他索引相同
4 vpcs map[] [] VPC 数组
5 tgw_cidr string N/A 中转网关无类别域间路由 CIDR
6 tgw_route_tables map[] [] 中转网关路由表数组

VPC 数组定义

属性 类型 默认值 说明
1 name string N/A VPC 的标识。VPC 最终命名为 前缀-vpc-${name}.
2 cidr string N/A VPC 无类别域间路由
3 az_count int 2 可用区数,可取 2 或 3
4 create_igw bool FALSE 是否创建并附加互联网网关到 VPC
5 enable_nat bool FALSE 是否为可用区创建网络地址转换网关
6 accounts string[] [] 拟共享子网或中转网关的账户数组
7 gateway_endpoints string[] [] 网关终端节点数组,可取 s3dynamodb
8 interface_endpoints string[] [] 接口终端节点数组,例如 ec2, kms
9 offsets int[][][] N/A 子网网段偏移量多维数组。五组子网偏移量分别为公有私有数据库Redshift内部子网。第一二三维数组长度必须为 5、az_count、2

中转网关路由表数组定义

属性 类型 说明
1 name string 路由表名称。最终名称为 前缀-tgw-route-table-${name} 建议您根据关联命名
2 associations string[] 关联到路由表的 VPC 数组。 VPC 名称是在上表名称中定义的
3 propagations string[] 传播到路由表的 VPC 数组。 VPC 名称是在上表名称中定义的

对网段偏移量数组 offsets 而言:

  • 如果不创建某类子网则留空,但必须创建内部子网,以连接中转网关;
  • 内部子网不会创建网络地址转换 NAT 网关;
  • 内部子网的无类别域间路由 CIDR 范围可设小,例如 /28;

接口终端节点 VPC

接口终端节点 VPC 旨在集中管理接口终端节点,在大部分情况下可节省网络费用。接口终端节点 VPC 会在网络账户为每一个接口终端节点创建 Amazon Route 53 私有托管区域,添加记录指向接口终端节点,并关联所有 VPC。正确定义接口终端节点 VPC 的方法为:

  1. endpoint_vpc_index 设置该 VPC 在数组中的位置,-1 表示不启用;
  2. 该 VPC 必须包含私有子网,并设置接口终端节点数组;
  3. 其他 VPC 无需设置任何接口终端节点,但是网关终端节点 (S3, DynamoDB) 还是在各 VPC 按需设置;

网络地址转换 VPC

网络地址转换 VPC 旨在集中管理网络地址转换网关,在大部分情况下可节省网络费用。 此 VPC 仅包含对网络地址转换 NAT 网关而非互联网关的集中管理,所以对需要使用互联网关的 VPC,您仍然需要设置 create_igw。 正确定义网络地址转换 NAT VPC 的方法为:

  1. nat_vpc_index 设置该 VPC 在数组中的位置,-1 表示不启用;
  2. 该 VPC 必须以 nat 为名,包含公有私有子网,设置 enable_natcreate_igw
  3. 其他 VPC 无需开启网络地址转换 NAT 网关;
  4. 中转网关无类别域间路由 CIDR 必须覆盖所有 VPC 的 CIDR,但是不能0.0.0/0

定义示例

下列 JSON 内容是对上面架构图的定义示例。仅使用不到 1,400 字节(不含空格),即整体规划并简洁定义了 2 个专属 VPC,3 个负载 VPC,1 个中转网关和 2 张中转网关路由表的互联互通网络拓扑结构。

{
  "amazon_side_asn": 64512,
  "endpoint_vpc_index": 0,
  "nat_vpc_index": 1,
  "vpcs": [
    {
      "name": "endpoints",
      "cidr": "10.0.0.0/20",
      "az_count": 2,
      "interface_endpoints": ["ec2", "ssm", "ssmmessages", "ec2messages"],
      "offsets": [
        [],
        [[4, 2], [4, 3]],
        [],
        [],
        [[8, 128], [8, 129]]
      ]
    },
    {
      "name": "nat",
      "cidr": "10.0.16.0/20",
      "az_count": 2,
      "create_igw": true,
      "enable_nat": true,
      "offsets": [
        [[4, 0],   [4, 1]],
        [[4, 2],   [4, 3]],
        [],
        [],
        [[8, 128], [8, 129]]
      ]
    },
    {
      "name": "logs",
      "cidr": "10.0.32.0/20",
      "accounts": ["LOGS_ACCOUNT"],
      "gateway_endpoints": ["s3"],
      "offsets": [
        [[4, 0],   [4, 1]],
        [[4, 2],   [4, 3]],
        [],
        [],
        [[8, 128], [8, 129]]
      ]
    },
    {
      "name": "app-dev",
      "cidr": "10.0.48.0/20",
      "accounts": ["DEV_ACCOUNT"],
      "gateway_endpoints": ["s3"],
      "offsets": [
        [[4, 0],   [4, 1]],
        [[4, 2],   [4, 3]],
        [],
        [[4, 6],   [4, 7]],
        [[8, 128], [8, 129]]
      ]
    },
    {
      "name": "app-prod",
      "cidr": "10.0.64.0/20",
      "accounts": ["PROD_ACCOUNT_1", "PROD_ACCOUNT_2"],
      "gateway_endpoints": ["s3", "dynamodb"],
      "offsets": [
        [[4, 0],   [4, 1]],
        [[4, 2],   [4, 3]],
        [[4, 4],   [4, 5]],
        [],
        [[8, 128], [8, 129]]
      ]
    }
  ],
  "tgw_cidr": "10.0.0.0/16",
  "tgw_route_tables": [
    {
      "name": "apps",
      "associations": ["logs", "app-dev", "app-prod"],
      "propagations": ["endpoints", "nat"]
    },
    {
      "name": "endpoints",
      "associations": ["endpoints", "nat"],
      "propagations": ["logs", "app-dev", "app-prod"]
    }
  ]
}

部署和销毁

借助 Cloud Foundations 强大的自动化运维功能,您可以“一键部署”上述 JSON 定义中所有的网络资源、共享资源并记录 VPC 和中转网关的流日志到日志账户。一键部署共享网络联通的主要步骤如下:

  1. parameter-editor 角色登陆基础账户的参数库控制台,新建或修改名为 /前缀/parameter/network/vpc 的参数,类型为加密字串客户密钥标识参考其他加密参数,值为 JSON 定义内容;
  2. catalog-user 角色登陆基础账户 Amazon Service Catalog 控制台,启动共享网络联通流水线产品 network/vpc。 如已启动可略过;
  3. pipeline-approver 角色登陆基础账户 Amazon CodePipeline 控制台,发布名为 前缀-pipeline-network-vpc-apply 的流水线;

删除共享网络联通相关资源的操作步骤和上述步骤相反,销毁流水线以 destroy 为后缀。

共享网关联通

把上面的关系网络联通改造成共享网关联通,把中转网关通过 Amazon RAM 共享到成员账户。专属 VPC(即接口终端节点 VPC 和网络地址转换 VPC)仍然在网络账户集中管理,负载 VPC 则在相应成员账户创建并挂载到中转网关。由于通过中转网关联通不能包含重叠的无类别域间路由 CIDR,所以对于生产账户 2 来说,需要使用不同的 CIDR 来创建 VPC(下图未标出)。同一个账户可以创建多个 VPC 并挂载到中转网关。中转网关连接网络账户和各成员账户内的 VPC 并通过其路由表进行网络隔离管控。

定义网络结构

共享网关联通采用和共享网络联通几乎相同的网络结构定义规则,除了以下几点:

  1. 专属 VPC(即接口终端节点 VPC 和网络地址转换 VPC)必须创建在网络账户,亦即省略其共享账户数组;
  2. VPC 数组中的共享账户数组 accounts 如果有则只能包含一个账户,因为不能有重叠的 VPC CIDR。省略该数组,则会在网络账户中创建该 VPC;
  3. 如要在一个成员账户中创建多个不同 VPC,分别在不同 VPC 的共享账户数组 accounts 中设置该账户;

就上述定义示例而言,如果要改造为共享网关联通定义,生产 VPC 只能指定一个生产账户。如有需要,可另设不重叠 CIDR 的 VPC,指定给生成账户 1 或 2。

部署和销毁

和共享网络联通类似,Cloud Foundations 可以帮助您以共享网关联通拓扑结构“一键部署” JSON 定义中所有资源并记录流日志到日志账户。部署共享网关联通比共享网络联通多一个步骤,因为共享网关联通是一个二阶流水线产品,需要生成流水线后再次发布,才会真正创建或销毁资源。具体参见《借助 Cloud Foundations 实现 Terraform 基础设施即代码的自动化管理及其持续集成和持续部署》。部署主要步骤如下:

  1. 和“共享网络联通”第一步相同;
  2. catalog-user 角色登陆基础账户 Amazon Service Catalog 控制台,启动共享网关联通流水线产品 network/tgw/pipeline。 如已启动可略过;
  3. pipeline-approver 角色登陆基础账户 Amazon CodePipeline 控制台,发布名为 前缀-pipeline-network-tgw-pipeline-apply 的流水线;
  4. 发布名为 前缀-pipeline-network-tgw-apply-fresh 的流水线;

删除共享网关联通相关资源的操作步骤和上述步骤相反,销毁流水线以 destroy 为后缀。

其他课题

主要成本

共享网络联通和共享网关联通主要区别是共享的资源不同,前者是子网,后者是中转网关。使用 Amazon RAM 不会产生额外费用。中转网关对 VPC 挂载数量和流量分别按小时计费。Amazon VPC 对网络地址转换网关计费。另外存储到 Amazon S3 的流日志会产生数据存储费用。最后就是在 Amazon EC2 实例上的工作负载产生的数据传输费用

流日志

无论以何种模式构建云上网络环境,Cloud Foundations 会自动为所有 VPC 和中转网关配置流日志,以 parquet 格式记录所有通信类型,并集中存储到日志账户的流日志桶中。

工作展望

以一套自动化组件简洁高效地满足规划部署千变万化的网络联通需求是不容易的。目前组件的网络规划和部署功能可以满足云上网络环境构建的大部分基础和典型需求。后续我们会在标签化自适应、多区域部署、多中转网关挂载类型、云下云上互联互通方面持续增强和创新,以满足您更多更高的业务场景和负载要求。

总结

本文介绍了借助 Cloud Foundations 的网络功能,如何整体规划并简洁定义基于共享网络联通和共享网关联通的网络拓扑结构,如何一键部署定义好的 JSON 内容,包括网络资源、共享资源并记录 VPC 和中转网关的流日志到日志账户。上述两大步骤帮助您大幅节省规划并部署多账户组织云上网络环境的时间和精力,使您可以专注于紧贴业务需求和中长期发展的网络规划本身,而无需费心于相关亚马逊云科技网络服务、组件的创建和配置,提高工作效率,加速云上网络建设。您可以访问 Cloud Foundations 解决方案页面了解更多信息,或者联系亚马逊云科技获取更多信息。

本篇作者

袁文俊

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

周涛

亚马逊云科技专业服务团队云架构顾问。专注于企业整体云上基础设施架构设计、迁移方案设计、最佳实践以及落地实施。

何华

目前就职于亚马逊云科技专业咨询服务部门,专注于企业客户入云解决方案的设计和落地实施。在网络通信、网络安全领域有多年的实践经验,拥有 AWS Certified Advanced Networking Specialty和Cisco Certified Internetwork Expert(CCIE#21832)等网络技术相关认证。

刘育新

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