利用 AWS Account Factory for Terraform 打造可扩展的帐户发放流程

关键要点

Zurich 保险集团在全球范围内推动数字化转型，利用 AWS 云迁移 1000 个工作负载。采用 Scalable Account Vending (SAV) 解决方案，以实现一致性和可扩展的帐户创建过程。SAV 通过自动化和标准化，减少了帐户创建的时间，从三天缩短至单次请求。利用 AWS Control Tower Account Factory for Terraform 提高了系统的弹性和性能。整个过程采用 GitOps 方法，以确保配置更改不会引入破坏性错误。

简介

Zurich 保险集团 是一家全球领先的多线保险公司，业务遍及200多个地区。公司总部位于瑞士苏黎世，主要提供人寿及财产损失保险。2022年，Zurich 开展了一个 多年的数字转型和创新计划，计划将1000个工作负载迁移到 AWS 云平台，其中包括核心保险和 SAP 工作负载。

在 2022 年，Zurich 构建了其 Global Cloud Foundation 这是开始将工作负载迁移到 AWS 云所需的一套基础全球 AWS 能力，包含本文讨论的可扩展帐户发放SAV解决方案。

Global Cloud Foundation 的目标是解决工作负载团队在迁移到 AWS 云时常见的问题：

我是否符合安全和合规政策？我如何建立所需的连接？我的 AWS 环境是否结构合理？我如何确保在使用云时的安全性？我所需的 AWS 服务是否获得认证并可以在 Zurich 的 AWS 云环境中使用？我是否准备好在云中部署生产工作负载？

对这一基础设施的投资，已经为他们在 2023 年及以后的迁移计划提供了支持。

Zurich 为什么需要可扩展的帐户发放SAV

作为一家联邦全球组织，Zurich 保险集团在多个地区的不同业务单元中有 AWS 的使用，且由不同的区域云卓越中心CCOE团队管理。然而，这种使用缺乏一致性。迁移计划的目标之一是建立一套标准的可重用模式和精心整理的服务，利用 Terraform 预构建，以减少迁移和现代化的工作量并最大化重用。这需要在一致的方式下构建 AWS 环境。

此外，Zurich 还从托管服务转向自助服务 DevSecOps 基础设施的配置，许多工作负载并未具备现有的 DevSecOps 环境，因此他们需要在 Azure DevOps 和 Terraform Cloud 中为其基础设施配置一个新环境，从而加速采用。

因此，云工作负载环境需要包括：

多个 AWS 账户开发、UAT 和生产，每个账户都遵循 Zurich 的标准 IAM 角色、控制、AWS Config 规则、服务如 AWS Backup 计划和保险库及 AWS 实例调度器与工作负载需求对齐的 AWS VPC，实现集中网络连接每个账户的 Terraform Cloud 工作区/团队工作负载的集成 Azure DevOps 项目可选工作负载基础设施的新 Azure DevOps 仓库可选

历史上，这些环境由各 CCOE 团队通过手动和半自动的流程创建。由于 AWS 云工作负载环境的需求增加，对可扩展和自动化解决方案的需求愈显迫切。CCOE 团队在 provision 一个单独的 AWS 账户时，可能需要长达三天，这涉及到多位员工的手动处理，并且每个工作负载所有者需要提出多达八个支持请求以建立其环境。此外，管道经常失败，无法提供支持 Zurich 扩展云采用战略所需的速度或灵活性。

为了解决这个问题，SAV 设定了三个主要目标：

确定并实施一个简化的、全自动化的新 AWS 环境请求机制。通过使用 AWS Account Factory for Terraform 提高帐户发放和基线准备的可扩展性和性能。创建一个在不同业务单位 CCOE 之间一致的机制，以最小化支持和维护开销并分享最佳实践。高级架构

此处展示的端到端解决方案完全以基础设施即代码的形式实施，使用 Zurich 的企业标准 Azure DevOps CI/CD 工具进行协调。

图 1 端到端解决方案使用 Zurich 的工具

工作负载所有者提交的单个 Jira 服务管理请求即可提供整个云工作负载环境，这为迁移工作负载到 AWS 提供了全部基本资源。

深入探讨解决方案

在这一节中，我们将探讨 SAV 架构的两个关键组成部分：使用 AWS Control Tower Account Factory for Terraform 的环境发放，以及 AFT 代码推广流程。

环境发放管道概述

图 2 环境发放管道概述

环境发放工作流程结构如下：请求 AWS 账户的申请通过 JIRA 服务管理 ITSM 工具输入。这将触发 Azure DevOps 中的环境发放管道。

AWS 账户发放

AWS Control Tower Account Factory for TerraformAFT通过响应以 账户请求 Terraform 配置形式提交的请求来创建新的 AWS 账户。每个账户请求配置包含分类 AWS 账户进入适当组织结构和成本中心所需的所有信息和元数据。

环境发放管道通过提取提交表单中输入的数据，生成一系列 AFT 账户请求 Terraform 配置，并将每个请求提交到 AFT 仓库。提交操作触发 AFT 来创建 AWS 账户，并执行将账户基线和所需自定义部署到每个发放账户的 Terraform 模块。

飞鱼加速器下载资源配置

管道的后续阶段使用 Terraform Cloud 提供其他资源，遵循与此相同的模式：

图 3 使用 Terraform Cloud 进行资源配置

管道任务执行一个 Python 脚本，该脚本应用一个 Jinja 模板生成一个 HCL 文件，然后提交到 Azure DevOps git 仓库。此步骤对于支持 CCOE 或工作负载团队在未来可能想使用的 GitOps 的“第二天”管理至关重要。提交将触发在相应的 Terraform Cloud 工作区进行的运行，该过程将资源配置到已链接的账户中。

Terraform Cloud 代码推广

AWS Control Tower Account Factory for Terraform (AFT) 采用 GitOps 方法，通过 Terraform 来进行帐户发放和基线准备。它有创建新账户和向发放账户部署资源的工作流程，通过其 全球和账户自定义选项，这些都有 Terraform 模块实现。然而，当修改这些 Terraform 模块时，存在一个风险，即错误的更改可能会影响到许多甚至所有发放的账户。

Zurich 保险集团通过实施 GitFlow 来降低这一风险。为了修改生产配置，将启动一个拉取请求、审查和合并的流程，以确保不会引入破坏性更改。更改将在低环境中测试后再部署到生产环境中。

该过程如下所示：

图 4 使用 GitFlow 的 Terraform Cloud 代码推广

结论

通过采用 AWS Control Tower Account Factory for Terraform，Zurich 能够实现可扩展性、弹性和性能，以支持预计 3000 个账户的配置。通过将整个过程压缩为一次 ITSM 请求，Zurich 保险集团 CCOE 能提高服务水平协议SLA和客户满意度，减少 CCOE 支持的时间和精力，并通过自动化 DevSecOps 活动保障其 AWS 环境的安全。

Zurich 保险集团云工程负责人 Eamonn Carey 说：

“对于 Zurich 及其公共云之旅，可扩展性和合规性是构建和管理我们的云环境的关键方面。第二天的管理在实现这两者方面起着至关重要的作用。我们的可扩展帐户发放流程和用于第二天管理的预创建仓库带来了诸多益处。它实现了 AWS 账户的快速交付，增强了可扩展性，并促进了标准化。它确保了高效的资源配置，而标准化的配置则确保符合法规和最佳实践。通过将这些元素结合在一起，Zurich 能够简化我们的运营，降低风险，并在我们的云环境中实现最佳的可扩展性和合规性。”

相关信息

AWS Control Tower Account Factory for TerraformTerraform CloudYouTube Zurich Insurance Cloud Acceleration

Raffaele Garofalo

Raffaele Garofalo 是一名高级解决方案架构师，现居瑞士 AWS，并担任 AWS 无服务器 TFC技术领域社区成员。他帮助金融机构利用云技术来扩展和转型业务。Raffaele 的背景是软件开发和架构。

John Duckmanton

John Duckmanton 是亚马逊网络服务AWS专业服务部门的高级云基础设施架构师，现居于英国。他在 IT 行业拥有超过 30 年的基础设施和应用程序交付经验，当前与全球金融服务客户合作，帮助他们加速采用 AWS 云，特别关注云基础设施搭建。