亚马逊AWS官方博客

Cloud Foundations 网络模块新增特性包括安全组、解析程序、中转网关连接挂载、专用网络连接网关、东西南北流量合并检查、入站流量集中检查、非主区域网络部署

随着 Cloud Foundations (CF) 交付越来越多客户，在灵活性要求较高的网络部署方面，我们也根据客户各种各样实际需求对网络模块进行增强或开发新功能，较好满足了绝大部分常见通用网络构建要求。本文就近期新增的网络构建功能进行归纳总结并做系统介绍。有关 Cloud Foundations 网络模块两种共享模式[1]、网络流量检查[2]、多张网络构建[3]等内容，可以阅读相关文章了解学习，本文不再赘述。

在项目交付过程中，我们发现 Cloud Foundations 网络模块较好解决了基础网络架构搭建，基础网络流量检查，多区域多账户网络连通等基础网络建设问题。但在以下方面仍有支持不尽完善甚至有所或缺之处。在 Amazon VPC (VPC) 方面对安全组及其规则支持缺失；在 Amazon Transit Gateway (TGW) 中转网关方面对连接挂载支持缺失；在网关负载均衡器 (GWLB) 流量检查方面提供了东西南北分别利用两个 VPC 各自检查架构，但缺少合并利用一个 VPC 各自检查架构；在入站流量集中检查方面对互联网关路由表支持不够完善；在整体网络方面尚未支持 Amazon Route 53 解析程序，Amazon Direct Connect (DX) 专用网络连接网关，以及仅于非主区域部署网络的需求。以下逐一介绍有关更新。

安全组及其规则

安全组是安全网络构建不可或缺的重要一环。此次更新使得网络模块可以规范、便捷、自动、批量定义并部署安全组及其出入站规则，助力您构建更加安全的网络。在网络定义 vpc 属性中新增 groups 属性来定义安全组，其类型为映射。安全组属性：

属性 类型 默认值 说明
description string Managed by CF 安全组描述
in map[] [] 入站规则数组
out map[] [] 出站规则数组

出入站规则属性：

属性 类型 默认值 说明
cidr string null

目标网段，和 group 二选一，也可取如下预置值：

vpc 指代当前 VPC 网段，* 指代全网段流量 0.0.0.0/0
description string Managed by CF 规则描述
group string null

引用安全组 ID，也可取如下预置值：

default 指代默认安全组，this 指代当前安全组
ports int[] 起止端口范围
protocol string tcp 协议，也可取如下预置协议，有预置端口者可省略端口

预置协议及其默认端口：

协议 默认端口 协议 默认端口
* / oracle 1521
geneve 6081 postgres 5432
http 80 redshift 5439
https 443 rdp 3389
icmp 8 ssh 22
mssql 1443 tcp /
mysql 3306 udp /
nfs 2049

其中：

  1. 如协议为 *，则无需定义端口；
  2. 如协议为 icmp，则代码为回应请求 8；
  3. 如协议为 tcp, udp，则需定义起止端口范围，如为单个端口，只需设置数组首位；
  4. 如协议为含默认端口的协议之一且未另行定义端口，则端口取协议对应端口默认值。

值得一提的是，上述安全组及其规则的属性和预置值与 Cloud Foundations 产品工厂[4]定义安全组及其规则的属性和预置值相同。目前系统为每个 VPC 配置一个默认安全组，入站允许公共网段和自身组访问，出站允许访问一切。

示例

以下就针对不同使用案例的安全组规则给出对应安全组定义实例。

  1. Web 服务器规则：下述定义中用 * 指代全网段流量 0.0.0/0，用预置协议及其默认端口避免硬编码端口； 
    {
  "vpcs": {
    "security": {
      "cidr": "10.1.0.0/16",
      "groups": {
        "web": {
          "in": [
            { "cidr": "*", "protocol": "http" },
            { "cidr": "*", "protocol": "https" }]
        }
    }}
}}
    JavaScript
  1. 数据库服务器规则：下述定义中入站规则用 vpc 指代当前 VPC 网段 1.0.0/16 从而避免硬编码 VPC 网段，用预置协议及其默认数据库端口，通过 default 引用默认安全组标识，亦可通过安全组标识直接引用； 
    {
  "vpcs": {
"security": {
      "cidr": "10.1.0.0/16",
      "groups": {
        "db": {
          "in": [
            { "protocol": "mssql",    "cidr": "vpc" },
            { "protocol": "mysql",    "cidr": "vpc" },
            { "protocol": "redshift", "cidr": "vpc" },
            { "protocol": "postgres", "group": "default" },
            {
              "protocol": "oracle",
              "group": "sg-095dea906a6232182",	
              "description": "Allow connections from EC2 security group"
            }],
          "out": [
            { "protocol": "http",  "cidr": "*"  },
            { "protocol": "https",  "cidr": "*"   }]
        }
    }}
}}
    JavaScript
  1. 用于从您的计算机连接到实例的规则：出站规则允许访问一切； 
    {
  "vpcs": {
    "security": {
      "cidr": "10.1.0.0/16",
      "groups": {
        "ec2": {
          "in": [
            { "cidr": "54.222.61.34/32", "protocol": "ssh" },
            { "cidr": "54.222.61.34/32", "protocol": "rdp" }],
          "out": [{ "cidr": "*", "protocol": "*" }]
        }
    }}
}}
    JavaScript
  1. DNS 服务器规则和Amazon EFS 规则：默认协议为 tcp，单个端口只需设置一位，NFS 允许自身组访问； 
    {
  "vpcs": {
    "security": {
      "cidr": "10.1.0.0/16",
      "groups": {
        "dns": {
          "in": [
            {  "cidr": "vpc", "ports": [53] },
            { "protocol": "udp", "group": "default", "ports": [53] },
            { "protocol": "nfs", "group": "this" }]
        }
    }}
}}
    JavaScript

Route 53 解析程序

Cloud Foundations 网络模块增加对 Route 53 解析程序的支持，满足本地网络或其他 VPC 与当前 VPC 之间执行动态 DNS 互查需求。根据最佳实践，入站和出站端点各一个就足以满足各向 DNS 查询，所以系统默认只创建出入站端点各一个。网络定义增加 resolver 一级资源解析程序属性：

属性 类型 默认值 说明
in map 单个入站端点
out map 单个出站端点
rules map[] [] 转发规则数组

出入站端点属性：

属性 类型 默认值 说明
vpc string DNS 查询经过 VPC。解析程序端点弹性网络接口于该 VPC 内部子网分配 IP 地址。
groups string[] 默认安全组

所属经过 VPC 的安全组数组，也可取如下预置值：

default 指代默认安全组

规则属性：

属性 类型 默认值 说明
domain string 域名
ips string[] 目标 IP 地址数组
type enum FORWARD 规则类型，还可取 SYSTEM, RECURSIVE.
vpcs string[] 使用此规则的 VPC 数组

与此同时，和 VPC 流日志一样，系统自动配置发送至网络账户 Amazon CloudWatch 日志组以及日志账户网络桶的查询日志记录并绑定至转发规则使用的 VPC。此处跨账户日志配置是 Cloud Foundations 多账户云上环境有机集成的标志之一。参考以下示例：

  1. 解析程序出入站端点均经过轴 VPC 查询 DNS；
  2. 两端点设置默认安全组及网络安全组，其中网络安全组在轴 VPC 中定义；
  3. 转发规则示例中被开发辐 VPC 使用；
  4. 转发规则出站端点则使用唯一出站端点； 
    {
  "resolver": {
    "in":  { "vpc": "security", "groups": ["default", "web"] },
    "out": { "vpc": "security", "groups": ["default", "web"] },
    "rules": {
      "example": {
        "domain": "site.company.com",
        "ips": ["123.45.67.89"],
        "vpcs": ["dev"]
      }
    }
  },
  "vpcs": {
    "security": {
      "cidr": "192.168.0.0/16",
      "groups": {
        "web": {
          "in": [
            { "cidr": "*", "protocol": "http" },
            { "cidr": "*", "protocol": "https" }],
          "out": [{ "cidr": "*", "protocol": "*" }]
        }
      },
      "subnets": [[[12, 0], [12, 1]], [], [[8,  3], [8,  4]]]
    },
    "dev": {
      "cidr": "10.0.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8,  3], [8,  4]]]
    }
}}
    JavaScript

下图展示上述定义解析程序出站端点，注意到其配置两个安全组：

下图展示系统自动配置的两种类型查询日志记录配置，其中日志组在当前网络账户，S3 网络桶在日志账户：

中转网关连接挂载

为满足客户通过配置中转网关连接软件定义广域网络 (SD-WAN) 的需求，Cloud Foundations 网络模块新增对中转网关连接 (Connect) 挂载和对等节点的支持。此挂载支持通用路由封装 (GRE) 隧道协议，通过边界网关协议 (BGP) 实现动态路由。其依赖现有 VPC 或专用网络连接挂载作为运输挂载来传输数据。具体参阅官方文档。我们为中转网关新增 cidrs 属性配置其网段，注意与 cidr 属性的区别。中转网关部分属性：

属性 类型 默认值 说明
cidr cidr 公共网段，需覆盖所有辐 VPC 网段
cidrs cidr[] [] 中转网关网段数组
connects map {} 中转网关连接挂载定义

连接挂载和对等节点属性：

属性 类型 默认值 说明
address string 从中转网关网段取首个可用地址 中转网关地址，为中转网关指定 GRE 外部 IP 地址。
attachment string 做为传输连接的现有 VPC 挂载 ID
cidrs cidr [] 内部网段数组 BGP 地址，指定用于 BGP 对等连接的内部地址范围。从 169.254.0.0/16 中指定 /29 CIDR 块。
peer.asn int 中转网关系统自治号 对等系统自治号。如果将其配置为与中转网关系统自治号 (eBGP) 不同，则必须使用生存时间 (TTL) 值 2 配置 ebgp-multihop。
peer.address string 对等节点 GRE 地址。为对等节点设备端指定 GRE 外部 IP 地址。

下述示例定义轴 VPC 放置第三方虚拟设备，配置中转网关连接挂载利用该 VPC 挂载为运输挂载：

{
  "vpcs": {
    "security": {
      "is_hub": true,
      "cidr": "192.168.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "tgw": {
    "asn": 64513,    "cidr": "10.0.0.0/8",
    "enabled": true, "cidrs": ["192.0.2.0/24"],
    "connects": {
      "vpc": {
        "attachment": "security",
        "cidrs": ["169.254.7.0/29"],
        "peer": { "asn": 64515, "enabled": true, "address": "192.168.0.11" }
      }
    }
}}
JavaScript

下图展示根据上述定义部署的资源类型为 Connect 的中转网关挂载及其两个连接对等节点。其中传输挂载为轴 VPC 挂载。

专用网络连接网关

Amazon Direct Connect 专用网络连接是常见的用以绕过互联网直接连接客户内部网络到专用网络连接位置的服务。Cloud Foundations 网络模块支持创建专用网络连接网关并关联中转网关，之后您可以创建中转虚拟接口将 DX 连接到专用网络连接网关进而连接到中转网关。和中转网关一样，一个区域只含有一个专用网络连接网关。网络定义增加 dx 一级资源专用网络连接网关属性：

属性 类型 默认值 说明
asn int 64512 自治系统号，建议与所有中转网关各不相同
enabled bool false 是否创建并配置专用网络连接网关
prefixes cidr[] [tgw.cidr] 允许的前缀数组，默认为关联中转网关公共网段

当多个中转网关与专用网络连接网关关联时不允许出现重叠的允许前缀。下述示例定义了一个专用网络连接网关自治号为 64512，一个中转网关自治号为 64513，公共网段为 10.1.0.0/16。部署之后可以在专用网络连接控制台查看专用网络连接网关启用、关联和配置情况。

{
  "dx":  { "asn": 64512, "enabled": true },
  "tgw": { "asn": 64513, "enabled": true, "cidr": "10.1.0.0/16" }
}
JavaScript

下图展示了专用网络连接网关及其关联的中转网关状态：

至此，Cloud Foundations 网络模块支持四类一级属性，分别是：

  1. vpcs: 虚拟私有云 VPC 定义；
  2. tgw: 中转网关定义；
  3. resolver: 解析程序定义；
  4. dx: 专用网络连接定义；

除 VPC 外，其他三个资源在一个区域只能定义一个。

东西南北流量合并检查

在之前有关各向网络流量检查的博客[3]中我们展示了六种借助 Cloud Foundations 网络模块可以定义并一键部署的常见多区域网络轴辐拓扑架构，分别是：

  1. VPC 对等连接；
  2. 互联网出口集中管理；
  3. 南北流量检查；
  4. 东西流量检查；
  5. 东西南北流量分别检查；
  6. 多区域中转网关对等连接；

上述第五种架构利用轴 VPC 进行南北流量检查，另设检查 VPC 进行东西流量检查，亦即通过两个 VPC 对南北和东西流量“分别”检查。此时需在每个 VPC 中各设一个防护设备，可以相同或者相异。例如用原生网络防火墙检查东西流量，用网关负载均衡器搭配第三方防火墙检查南北流量。在实践中我们发现还缺一种常见架构，即在轴 VPC 中利用同一个防护设备分别检查南北和东西流量，即东西南北流量合并检查。此处“合并”指的是把第五种架构种的轴 VPC 和检查 VPC 合并为一个 VPC，把两个防护设备合并为一个。具体来说，是将第五种架构中转网关流量检查前路由表对东西和南北流量的分流迁移至下图轴 VPC 内部子网路由表完成。防护设备可选择网关负载均衡器配合第三方设备。

主要配置点为：

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

为此，Cloud Foundations 网络模块更新网关负载均衡器属性，新增 same_ns_ew 控制是否单设东西流量终端节点，新增 same_subnet 控制网关负载均衡器是否在单独子网。如网关负载均衡器与其终端节点不在同一子网，则轴 VPC 需准备至少两个私有子网：

属性 类型 默认值 说明
enabled bool false 是否创建并配置网关负载均衡器
cross_zone bool false 网关负载均衡器跨可用区负载均衡
groups map {} 目标组
in_public bool false 是否置终端节点于公有子网
same_ns_ew bool true 南北与东西终端节点是否相同
same_subnet bool true 网关负载均衡器与其终端节点是否在同一子网

目标组属性：

属性 类型 默认值 说明
type enum instance 目标类型，还可取 ip
health.enabled bool false 健康检查
health.path string 健康检查路径
health.port int 80 健康检查端口
health.protocol string TCP 健康检查协议，还可取 HTTP, HTTPS

以下配置和上述第三种架构[3]相较而言只是多了 gwlb.same_ns_ew = false。 此外，该配置将网关负载均衡器与其终端节点置于不同子网，设置 gwlb.same_subnet = false。 此时轴 VPC 需配置至少两个私有子网。

{
  "vpcs": {
    "security": {
      "is_hub": true,
      "cidr": "192.168.0.0/16",
      "nat": { "enabled": true },
      "igw": { "enabled": true },
      "gwlb": {
        "enabled":    true, "same_ns_ew":  false, 
        "cross_zone": true, "same_subnet": false,
        "groups": { "main": { "health": { "enabled": true } } }
      },
      "subnets": [
        [[12, 0], [12, 1]], [[8, 1], [8, 2]],
        [[8,  3], [8,  4]], [[8, 5], [8, 6]]]
      },
    "dev": {
      "cidr": "10.0.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "prod": {
      "cidr": "10.1.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    }
  },
  "tgw": {
    "enabled": true,
    "cidr": "10.0.0.0/8",
    "tables": {
      "pre": { "associations": ["dev", "prod"], "routes": { "*": "security" } },
      "post": { "associations": ["security"], "propagations": ["dev", "prod"] }
    }
}}
JavaScript

从下图轴 VPC 内部子网关联路由表可以看出，全网段流量导入南北终端节点，公共网段流量导入东西终端节点。上述两个终端节点属于同一个网关负载均衡。如此就实现了在一个 VPC 同一个防护设备中对东西南北流量分别检查。

入站流量集中检查

Cloud Foundations 网络模块增强对入站流量集中检查的支持，扩展互联网网关关联路由表定义，可以指定子网流量按可用区导入防护设备终端节点。在此我们以之前有关各向网络流量检查的博客[3]中第五种架构即“东西南北流量分别检查”为例，介绍如何将其入站辐 VPC 升级为含流量检查。首先为互联网网关新增属性：

属性 类型 默认值 说明
enabled bool false 是否创建并配置互联网网关
table.enabled bool false 是否创建并配置互联网网关路由表
table.subnets int[] [] 互联网关路由指向防护设备子网索引

子网索引参考 VPC 子网数组属性定义，即数组按序包含内部、公有和私有子网。 其中第一位为内部子网，第二位为公有子网，从第三位开始为私有子网。如应用负载均衡器在第一、二个私有子网，则对应索引为 [2, 3]。

入站流量通常于公有子网防护设备进行检查，所以需为防护设备设定是否置于公有子网。当终端节点置于公有子网时，通常不需要再放置网络地址转换 (NAT) 网关，同时私有子网流量导入和轴 VPC 以及东西检查 VPC 略有不同。网络模块为 VPC 的网络防火墙和网关负载均衡器都新增以下属性：

属性 类型 默认值 说明
in_public bool false 是否置终端节点于公有子网

以下为更新的第五种东西南北流量分别检查架构图，其中入站辐 VPC 设计参考了这篇博客[5]的“入站集中式部署模型”：

其中入口辐 VPC 主要配置点更新为：

  1. 入口辐 VPC 设置内部、公有、私有子网；
  2. 入口辐 VPC 公有子网路由表全网段流量导入互联网关；
  3. 入口辐 VPC 私有子网路由表全网段流量按可用区导入防护设备终端节点，公共网段流量导入中转网关；
  4. 入口辐 VPC 互联网关路由表私有子网流量按可用区导入防护设备终端节点；

以下配置更新要点主要在入口辐 VPC 处，其中互联网网关开启路由表并指向第一个私有子网，其索引为 2；网关负载均衡器设置在公有子网部署；设置一个目标组并开启健康检查。网络防护设备方面出口轴 VPC 和入站辐 VPC 均使用网关负载均衡器搭配第三方防火墙，而东西流量检查辐 VPC 则使用原生网络防火墙。读者可根据自身实际情况对各处防护设备进行灵活搭配。

{
  "vpcs": {
    "inspect": {
      "nfw": { "enabled": true },
      "cidr": "192.168.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8, 3], [8, 4]]]
    },
    "egress": {
      "is_hub": true,
      "cidr": "10.0.0.0/16",
      "nat": { "enabled": true },
      "igw": { "enabled": true },
      "gwlb": {
        "enabled": true,    "same_ns_ew": true,
        "cross_zone": true, "same_subnet": false,
        "groups": { "main": { "health": { "enabled": true } } }
      },
      "subnets": [
        [[12, 0], [12, 1]], [[8, 1], [8, 2]],
        [[8,  3], [8,  4]], [[8, 5], [8, 6]]
      ]
    },
    "ingress": {
      "cidr": "10.1.0.0/16",
      "igw": {
        "enabled": true,
        "table": { "enabled": true, "subnets": [2] }
      },
      "gwlb": { 
        "enabled": true, "in_public": true,
        "groups": { "main": { "health": { "enabled": true } } }
      },
      "subnets": [[[12, 0], [12, 1]], [[8, 1], [8, 2]], [[8, 3], [8, 4]]]
    },
    "dev": {
      "cidr": "10.2.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8,  3], [8,  4]]]
    },
    "prod": {
      "cidr": "10.3.0.0/16",
      "subnets": [[[12, 0], [12, 1]], [], [[8,  3], [8,  4]]]
    }
  },
  "tgw": {
    "enabled": true,
    "cidr": "10.0.0.0/8",
    "tables": {
      "pre": {
        "associations": ["ingress", "dev", "prod"],
        "routes": { "*": "egress", "tgw": "inspect" }
      },
      "post": {
        "associations": ["inspect", "egress"],
        "propagations": ["ingress", "dev", "prod"]
      }
    }
  }
}
JavaScript

从下图互联网关路由表路由列表可以看出，指向第一个私有子网网段的流量已按可用区导入防护设备终端节点。如需导入多个子网，设置多个对应子网索引即可。

非主区域网络部署

在交付实践中，我们遇到客户要求在主区域不部署任何网络资源以节约开销，主要在管控区域部署网络和工作负载资源的情形。囿于技术或监管原因，的确会出现承载网络和工作负载的“主要区域”和部署 Cloud Foundations 时设置的主区域相异情况。另一方面，Amazon IAM 等不分区域的全局资源需要在主区域提前创建。为此，网络模块对 VPC 资源新增 enabled 属性控制资源部署。VPC 该属性是所有资源类似属性中唯一默认为真的：

属性 类型 默认值 说明
enabled bool true 是否创建 VPC

假设主区域为宁夏，主要（管控）区域为北京，下述定义中在主区域通过关闭开关仅创建流日志用和只读等角色，在主要（管控）区域创建网络资源。凡是需共享至成员账户的 VPC 都需事先在这些账户创建相关角色。无需共享而仅在网络账户管理的 VPC，例如轴 VPC，检查 VPC 等，则无需提前创建角色，统一在主要（管控）区域管理。

{
  "vpcs": {
    "sandbox": { "enabled": false, "accounts": ["156165649349"] }},
  "cn-north-1": {
    "vpcs": {
      "security": { "is_hub": true, "cidr": "192.168.0.0/16" },
      "sandbox": { "cidr": "10.1.1.0/24", "accounts": ["156165649349"] }
    }
}}
JavaScript

总结

本文介绍了 Cloud Foundations最近一年在各个方面对网络模块进行的功能增强和新增特性。这些举措都是为了解决实际交付项目过程中所遇到各种各样的复杂网络构建问题。正所谓“罗马非一日建成”，Cloud Foundations 网络模块对纷繁复杂的亚马逊云科技网络资源的支持也不是一天建成，且还在积极建设过程中。本着“以终为始”理念和“从客户中来，到客户中去”思想，我们会积极倾听客户需求，持续满足千变万化又具有普遍适用特点的网络架构要求。下一步，我们将重点加强网络安全、网络防火墙方面的全面支持和建设能力。

参考资料

  1. 博客：《借助 Cloud Foundations 实现多账户组织云上网络环境两种共享模式的整体规划与一键部署》，2023年2月
  2. 博客：《借助 Cloud Foundations 规划设计云上多区域网络轴辐拓扑结构一键部署东西南北流量分别或合并检查》，2023 年 11 月
  3. 博客：《借助 Cloud Foundations 共享网络产品于多个网络账户规划设计并一键部署云上跨区域互联的多张网络》，2024年2月
  4. 博客：《借助 Cloud Foundations 产品工厂规划设计并一键部署云上多账户访问控制及权限策略等基础设施资源》，2024年3月
  5. 博客：《Network Firewall 部署小指南（二）路由设计》，2024年10月

本篇作者

Clement Yuan

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

刘育新

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