亚马逊AWS官方博客

中小企业上云采用多账户策略的优势

注：本文是中小企业上云系列博客的第一篇，读者可点击链接阅读下一篇 《中小企业上云采用多账户策略的初级架构》。

相比大型企业，中小企业上云的资源规模一般较小；同时因其业务特点需要在激烈的市场中快速响应和适应变化，以加速业务创新和发展。因此大部分中小企业在上云初期往往直接采用单账户模式承载云上所有业务负载。随着云上业务不断发展、组织结构不断调整，在单账户模式下企业对云上资源的治理能力、安全性、成本控制以及业务的敏捷性等方面面临诸多挑战。

亚马逊云科技账户特点

亚马逊云科技账户是用来承载云上服务的资源容器，其所对应的账户 ID 通过唯一的 12 位数字（例如 012345678901）进行标识。对于初次接触亚马逊云科技的技术人员，容易混淆账户与 Amazon Identity and Access Management（IAM）用户，二者是不同的概念，同 Amazon EC2 一样，IAM 也属于云上提供的一种服务类型。其关系可通过以下示意图表示：

区别于传统的账户模型，亚马逊云科技账户具有如下特点：

  • 是资源隔离的边界：每个账户都是一个独立的资源容器，拥有自己的资源和服务，不同账户之间的资源相互隔离。通过将资源在账户层面隔离，将带来清晰的资源管理边界。
  • 是访问控制的边界：IAM 是实现访问控制和权限管理的最小单位，IAM 作为账户中的一种云服务类型，在不同的账户之间默认情况（说明：IAM 也支持跨账户的访问场景，但是需要源端和目的端分别授权）也是彼此独立，互不干扰。通过将资源在账户层面隔离，将拥有清晰的安全访问控制边界。
  • 是成本控制的边界：每个独立的账户需要绑定相关的支付信息，云上资源的费用是以账户为单位进行支付。通过将资源在账户层面进行隔离，将自动拥有清晰的成本控制边界。
  • 是资源限制及配额的边界：亚马逊云科技为每个账户设置了一些资源使用的限制和配额，例如 EC2 实例的 vCPU 数量、VPC 数量、API 访问频率限制、网络带宽等。这些配额是为了保护整个云基础设施的可用性和性能，以防止个别账户占用过多资源。每个账户都有自己默认的资源使用配额，超出配额的请求可能会被拒绝或受限制。通过合理的账户拆分，可降低因单账户资源限制和配额为企业云上资源带来的相互影响。

企业上云采用的单账户模式

单账户模式即所有的业务资源和服务都集中在一个亚马逊云科技账户下。这种模式简单易管理，对于初学者和小规模应用，确实具有一定的便利性。但是在实际的企业场景中，随着业务的发展和组织架构的调整，会逐渐演进成以 “IAM” 和 “Amazon VPC” 控制为核心的单账户结构：

在该单账户结构中，运维团队将负责账户内所有的 IAM 和 VPC 的创建和管理；各个开发团队将负责应用相关资源（例如 EC2 和 RDS）的创建和管理。运维团队针对 IAM 和 VPC 的控制包括：

  • IAM 的控制：在单账户的结构中，由于所有资源部署在同一个账户，针对不同的资源、服务的访问控制将通过 IAM 精细化的策略控制完成。在这种模式下，如何控制开发人员只能管理指定的 EC2 实例，可参考文档 1 和文档 2 了解 IAM 策略的配置过程及复杂度。
  • VPC 的控制：不同的软件开发周期（例如：开发和生产）需要从网络进行隔离，避免不同的网络流量对核心资源产生干扰。在单账户中，针对不同的软件开发周期通常采用不同的 VPC 进行隔离，而针对网络相关的权限管理仍需通过 IAM 策略完成。

IAM 和 VPC 实现的权限和业务隔离，完全依赖于运维人员的操作水平，对运维人员的技能提出较高要求。同时由于管理的复杂性，往往还会引入其他流程作为补充，提供更安全、更精细化的控制，以满足企业对业务敏捷性和云上治理的需求。例如：

  • IAM 管理：所有 IAM 配置由运维人员进行统一管理，任何新增、修改 IAM 需要重新提交申请。由此给运维人员带来了额外的工作量，同时由于流程的引入也降低了开发人员的生产效率。
  • 标签控制：上述提到如需要在单账户内针对 EC2 等类型资源做最小权限控制时，不可避免会引入了 ABAC 也就是基于标签的 IAM 访问控制模式，对开发人员和运维人员提出了更高阶的技能要求。
  • 资源的生命周期管理：从成本控制和治理角度，需要对云上的资源的生命周期进行统一集中管理，任何资源的变更需通过工单系统提交，或者通过 Amazon CloudFormation 模版进行管理。

传统单账户模式存在的挑战

上述管理模式不仅增加了管理复杂度和成本，并且极大的降低了开发体验和生产力。对于追求敏捷、高效的中小企业，往往难以长期采用这种精细化、集中式的 “IAM” 管理方式。最终逐渐形成了边界模糊的传统单账户结构：

上图中的传统单账户管理方式，确实给开发团队提供了充分的能动性，能够自行部署、运维各自负责的云上资源，短时间内在一定程度上提升了业务敏捷性。但是这种模式使得不同的业务、权限边界愈加模糊，引入了诸多潜在的安全风险和治理复杂度。常见的问题包括：

  1. 账户中出现越来越多的 IAM 管理员权限：为了提升开发生产力，云管理员简化了 IAM 权限管理，不再做精细化的最小权限划分，会导致该账户出现越来越多的具有管理员权限的身份。
  2. 资源命名、标签不统一：由于越来越多的开发人员拥有了资源创建的权限，导致资源的命名、标签难以统一。这些资源可能是为了解云服务特性临时创建的，也有可能是开发人员没有意识到公司的统一命名规范。
  3. 资源边界模糊，相互影响：由于所有资源都堆积在同一个账户，而账户内可分配 IP 地址、API 配额等资源是一定的，不可避免会相互之间造成影响，降低了整个组织的生产力。常见的资源冲突场景包括：
    • IP 地址相互挤占：企业级网络规划中通常要求 IP 地址不能重复，一旦 IP 地址被耗尽， EC2 实例等资源就无法正常部署，会影响全局的工作负载。
    • API 请求限额挤占：为了确保亚马逊云科技服务的可用性，在每个账户的每个区域设置了 API 请求限制。假如某个服务测试过程中调用 EC2 API 太频繁而达到 API 的请求限制，当生产系统里或其他组的应用需要调用 EC2 API 完成业务需求时，访问可能会被限制，从而影响所有业务系统。
    • 虚拟机 vCPU 限额挤占：每个账户的每个区域限制了最多可用的 vCPU 数量，一旦 vCPU 使用达到上限，需要申请提升 vCPU 配额，而配额的提升需要一段时间才能处理，在此期间可能阻碍开发进程，影响开发进度，甚至因为无法创建新的 EC2 实例而影响生产业务系统。
  4. 资源被误改、误删：由于释放了 IAM 权限给部分开发人员，在特定场景下由于人为失误，很可能会造成资源误改或误删，而对公司的业务造成较大损失。
  5. 快速增长的云账单和无人认领的资源：当云上资源越来越多时，企业管理者需要对云上成本进行优化，成本优化最关键的一步是需要识别资源的业务方。但是在单账户的场景中，往往最后存在很多孤立的资源，难以识别资源的拥有者，对成本优化造成较大阻力。
  6. 安全事件影响范围较大：企业安全管理员或运维人员会制定一系列安全措施以尽可能降低安全事件发生的概率，以保证企业业务安全和连续性。当所有资源都集中在一个账户下时，一旦发生安全事件，其影响可能是全局的。例如：
    • 由于某个 EC2 实例漏洞，导致 EC2 被入侵，攻击者将有可能侵入企业内部网络，同时攻击者也有可能获取 EC2 所绑定的 IAM 角色权限，从而影响账号下所有的工作负载。
    • 当某个管理员用户的 IAM 密钥泄漏时，攻击者将有可能拥有该账户下所有负载的权限。
  7. 难以快速满足针对特定工作负载的合规性要求：在特定行业或地区可能对数据隔离和访问控制有特定的要求。当不同类型的数据和业务资源放置划分在同一账户中时，由于这些资源分别有各自的安全配置和要求，又常常分管于不同的业务部门，这种改动往往牵一发动全身，很难快速、有效的只针对特定的数据或者应用以响应安全合规方面要求。
  8. 难以支撑多种云运营模式：云运营模式定义了云基础设施团队和应用团队在云上的责任模型。为了最大限度发挥不同团队的优势，针对不同的工作负载和不同团队的需求，企业内部往往会存在云运营模式。在单账户结构中，应用团队与云基础设施团队，以及应用团队之间缺乏清晰的访问和控制边界，难以支撑多种不同的云运营模式。

采用多账户模式的优势

上述场景所对应的多账户结构示意图如下所示：

上面所示的多账户结构中，开发组一和开发组二将负责各自应用的开发和运维，并拥有相关账户的权限。其中每一个应用对应会有两个账户，分别对应开发环境和生产生产。在采用多账户的模式之后，即不同的工作负载或服务部署在不同的账户，开发团队作为账户的主要负责人，将负责管理各自所属账户内的资源和服务。通过账户定义了不同工作负载、不同团队之间清晰的工作边界，使得：

  1. 开发团队获得了业务上的敏捷性，加速业务创新和迭代
  2. 缩小了云上资源的爆炸半径而避免相互影响
  3. 通过在账户层面能够清晰的梳理出云上资源的消费情况，方便企业实现云上成本控制
  4. 支持多种云运营模式，能够充分发挥不同团队的优势，加速企业的云转型

多账户策略作为亚马逊云科技推荐给客户的最佳实践方案，本身也在致力于构建更多原生服务和功能，让客户更容易、更安全的享受多账户模式带来的优势。例如：

  • Amazon Organizations：Amazon Organizations 是一个用于管理多个账户的服务。通过它可以创建和管理账户层级结构。通过 Amazon Organizations，还可以创建账户组织单元（OU），并在 OU 层级上应用策略、控制访问和共享资源，从而实现对多个账户的集中管理和控制。同时使用 Amazon Organizations 整合账单功能能够合并多个账户的费用并进行支付。
  • Amazon Identity and Access Management（IAM）：IAM 是亚马逊云科技提供的身份和访问管理服务，除了支持单个账户内的权限管理和控制，还可以通过代入角色策略 （Assume Role Policy）以及资源策略 （Resource Policy）来支持跨账户场景的访问和控制。
  • Amazon Resource Access Manager（RAM）：使用 Amazon RAM 能够在多个账户之间共享资源。它可以将本账户的资源分享及授权给其他亚马逊云科技的账户，来完成对本账户的资源进行访问和使用，而无需在每个账户中复制或重复创建资源。使用 RAM，可以轻松地共享资源，例如 Amazon VPC、Amazon Route 53 等，以便多个账户可以安全地共享和使用这些资源。
  • Amazon CloudFormation：CloudFormation 是亚马逊云科技的基础设施即代码服务，它允许以声明性的方式定义和部署基础设施资源。通过 CloudFormation 模版，定义基础设施配置，包括 VPC、子网、安全组等，在单个操作中能够跨多个账户和 区域创建、更新或删除堆栈，以可重复和可管理的方式在多个账户之间快速部署和维护一致的多账户基础设施环境。

同时亚马逊云科技在多年的实战经验中，总结出了多账户白皮书以及云上多账户最佳实践架构。中小企业在初期可以直接采用推荐的基础多账户结构，以亚马逊云科技最佳实践的方式开启云上之旅。后续根据业务的发展情况，再基于初始化的多账户架构逐步扩展。通过采用多账户的策略，让企业可以在前期通过较小的投入快速建立起健壮、可靠的云基础设施环境。

总结

本文分析了在大多数中小企业里，所采用的传统单账户结构体系以及管理形态，并从成本、安全性、云上治理等多个维度进行分析。通过构建一个合理的多账户云上环境，可以为中小企业带来更快的业务创新、更高效的云上安全机制。如想了解针对中小企业采用多账户策略所推荐的初级架构，可点击链接继续阅读。

本篇作者

黄敢

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