<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 使用 AWS Cloud Control 简化网络部署
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
AWS Cloud Control API 提供了一个统一的、语言无关的接口，用于管理 AWS 资源，旨在解决多云环境中的网络配置和资源管理挑战。该解决方案的核心内容包括标准化 Create-Read-Update-Delete-List (CRUD-L) 接口，支持跨区域和多账户部署，帮助组织简化云资源管理。**AWS Cloud Control API** 适用于复杂网络场景，如跨多个 AWS 账户和区域的网络部署，满足行业需求，例如在多云景观中减少配置错误和部署时间。通过声明式方法，组织可以专注于架构设计和业务逻辑，而非工具细节的复杂性。
## 实施步骤
1. **准备先决条件**
- 在 Network Deployment 账户中创建 IAM 用户，并附加权限策略（如 network_deployment_user_policy），以管理 IAM、Amazon S3、CodePipeline、CodeBuild 和 DynamoDB。
- 安装并配置 AWS CLI，使用创建的访问密钥进行身份验证。
- 安装 Git，以克隆仓库并管理代码。
2. **克隆并设置 Git 仓库**
- 克隆指定仓库（例如：git clone https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control.git）。
- 切换目录、移除原远程仓库，并添加新远程仓库 URL，然后推送内容。
3. **创建 IAM 角色**
- 在 Network Deployment 账户中创建 CodePipelineRole，使用 Cloud Control API 的 create-resource 操作部署角色。
- 在成员账户中创建相应角色，并更新 Principal 以引用 Deployment 账户的角色 ARN。
4. **设置 CodeBuild 项目**
- 使用 Python 环境创建 CodeBuild 项目，指定源类型为 CODEPIPELINE，并关联 CodePipelineRole。
5. **创建 Amazon S3 存储桶**
- 在 Network Deployment 账户中创建 S3 桶用于存储工件，并启用版本控制。
6. **部署 CodePipeline**
- 在指定区域（如 us-east-1）创建 CodePipeline，使用 YAML 文件配置，并链接 CodeBuild 项目。
- 更新配置后，检查资源创建状态。
7. **设置 DynamoDB 表**
- 在 Network Deployment 账户中创建 DynamoDB 表，用于存储数据。
8. **更新配置并触发 CI/CD 管道**
- 修改部署脚本和 YAML 文件（如 Account ID 和 CIDR），然后提交到 Git 仓库以触发管道执行。
## 方案客户价值
- **简化部署和管理**：通过统一的 CRUD-L 接口减少配置错误和部署时间，相比传统工具如 AWS CloudFormation，**AWS Cloud Control API** 自动解析依赖关系，降低手动干预，实现更高效的资源管理。
- **提升跨账户和跨区域灵活性**：支持假设角色（Assumed Role）无缝处理多账户隔离，减少操作开销，在多区域场景中重用配置文件，避免了传统方案中需要手动参数化的复杂性。
- **自动化和动态更新**：集成 CI/CD 管道（如 AWS CodePipeline）实现声明式自动化，相比 Terraform 或 CDK，减少错误并提供实时反馈，支持动态更新路由表和防火墙规则，适用于突发流量场景。
- **成本和效率优化**：虽然未量化具体指标，但通过最小化手动错误和简化接口，潜在地降低运维成本；然而，在大规模组网时，可能面临管理复杂度上升的问题，需要结合实际情况评估。
## 涉及的相关产品
- **AWS Cloud Control API**：作为核心产品，提供统一的资源管理接口，用于简化网络资源部署和更新。
- **AWS Transit Gateway**：用作网络中枢，实现跨区域和账户的连接，支持单次 API 调用创建资源。
- **AWS Network Firewall**：处理流量检查和规则配置，通过 CRUD 操作动态管理，提升安全性。
- **AWS CodePipeline 和 CodeBuild**：用于 CI/CD 自动化，集成 Cloud Control API 实现管道化部署。
- **Amazon S3 和 DynamoDB**：分别用于存储工件和数据，支持管道执行和资源状态跟踪。
## 技术评估
**AWS Cloud Control API** 在技术先进性上表现出色，提供一致的接口，支持实时更新和跨账户操作，适用于多云网络场景的资源管理。该方案的可行性高，通过声明式配置自动解析依赖，减少了传统 IaC 工具（如 CloudFormation）的模板复杂性，并降低了错误率。然而，个别资源可能仍需单独 API 调用，潜在限制包括在大规模部署时管理复杂度增加，以及对新功能的采用依赖 AWS 更新周期。相比 Terraform 的状态文件管理，Cloud Control API 的错误反馈更透明，但在大规模组网时可能面临优化挑战。总体而言，该方案在简化操作和提升效率方面具有显著优势，适合企业级网络架构。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 使用 AWS Cloud Control 简化网络部署
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/streamlining-network-deployments-using-aws-cloud-control/](https://aws.amazon.com/blogs/networking-and-content-delivery/streamlining-network-deployments-using-aws-cloud-control/)
**发布时间:** 2025-04-21
**厂商:** AWS
**类型:** BLOG
---
## 引言
在当今的多云环境（multi-cloud landscape）中，组织在网络配置和资源管理方面面临重大挑战。传统的工具通常需要深入的、特定工具的知识，这会导致部署时间延长和配置错误。
[AWS Cloud Control API](https://aws.amazon.com/cloudcontrolapi/) 通过提供一个统一的、语言无关的接口来解决这些常见的云管理挑战。它允许立即访问最新的 AWS 功能，以及跨服务的标准化 Create-Read-Update-Delete-List（CRUD-L）接口。这些改进简化了云资源部署和管理。简化与 AWS 服务的交互，使 AWS Cloud Control API 能够让组织专注于其架构设计和业务逻辑，而不是纠缠于各种管理工具和服务特定 API。这带来更快的实施、更少的错误，以及在多云环境中更流畅的操作。
本文演示了 AWS Cloud Control API 如何优化网络资源开发。我们展示了一个示例设置，使用 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 和 [AWS Network Firewall](https://aws.amazon.com/network-firewall/)，跨越多个 AWS 账户和 AWS 区域，突出使用 AWS Cloud Control API 的声明式方法来部署和管理这些资源的最佳实践。本文讨论的概念和构建块可以扩展到其他网络资源，例如 [AWS Cloud WAN](https://aws.amazon.com/cloud-wan/) 或 [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/)。
## 真实场景使用 AWS Cloud Control API
在此示例场景（图 1）中，我们有一个工作负载跨两个 AWS 区域（us-east-1 和 us-west-2）运行。共享服务账户中的内部应用通过 Transit Gateway 连接到此工作负载，我们使用它进行跨区域连接。工作负载与内部应用之间的所有通信都经过 Network Firewall 的检查。 [博客](https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-centralized-traffic-filtering-using-aws-network-firewall/) 提供了关于使用 AWS Network Firewall 和 AWS Transit Gateway 进行集中部署的技术深入分析。
图 1: AWS Cloud Control API 简化真实网络场景的开发和部署
以下表格（表 1）总结了我们真实场景的构建块，以及 AWS Cloud Control API 功能如何简化其开发和部署。
| **Label#** | **Block description** | **AWS Cloud Control API feature** |
|------------|-------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| 1 | **Centralized connectivity:** 使用 Transit Gateway 作为所有流量流量的中心点。 | 通过单个 create_resource API 调用来配置 Transit Gateway 及其附件。 |
| 2 | **Traffic inspection:** 将所有流量路由通过 Network Firewall。 | 使用 Cloud Control API 的 CRUD 操作动态配置 Network Firewall 规则。 |
| 3 | **Multi-account setup:** 确保不同账户中的工作负载隔离。 | 使用假设角色（assumed roles）与 Cloud Control API 安全地在账户间配置资源。 |
| 4 | **Dynamic updates:** 保持路由表随工作负载变化而更新。 | 使用 read 和 update 操作动态获取当前附件并更新 Transit Gateway 路由表。 |
| 5 | **Automation:** 通过 CI/CD 管道最小化手动干预。 | 将 Cloud Control API 集成到 CI/CD 管道中，实现网络资源的声明式、自动化配置和管理。 |
*表 1: 使用 AWS Cloud Control API 的真实场景构建块*
### Centralized connectivity（集中连接）
对于此多区域工作负载，Transit Gateway 充当网络中转中心，连接 us-east-1 和 us-west-2 中的 VPC，以及共享服务账户。以下表格总结了 AWS Cloud Control API 如何通过单个 API 调用配置 Transit Gateway 及其附件，从而简化此集中连接架构，如图 1 中的标签 1 所示。表 2 还与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）进行了比较。
| **Feature** | **AWS Cloud Control API** | **AWS CloudFormation** | **AWS CDK** | **Terraform** |
|----------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|
| Unified and Consistent Interface | Cloud Control API 提供一致的接口来管理 Transit Gateway 及其附件。尽管需要针对 Transit Gateway 和每个附件进行单独的 API 调用，但它提供了标准化的 CRUD 操作。这种方法相对于服务特定 API 简化了管理，但仍需使用 create_resource 操作进行单个资源配置。这消除了学习不同基础设施即代码（IaC）工具的细节的需要。 | 采用基于模板的方法，为 Transit Gateway 和附件定义单独的资源，需要严格的语法规则。 | 需要为 Transit Gateway 和附件定义单独的类，需要编程专业知识。 | 需要定义多个 HashiCorp Configuration Language (HCL) 资源，并为每个资源显式指定模块和参数。 |
| Real Time Updates | 提供一致的接口，用于管理资源，可简化采用新功能，因为这些功能通过 Cloud Control API 立即可用。 | 更新延迟，因为 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 资源规范必须更新以包含新 AWS 功能。 | 更新延迟，依赖于 AWS SDK。 | 更新延迟，需要提供程序更新。 |
| Declarative State Management | 使用 YAML 文件，自动解析依赖关系。API 自动解析依赖关系并相应配置资源，减少复杂性。 | 完全声明式，但需要手动配置资源间的依赖关系。 | 代码驱动，需要显式依赖关系。 | 声明式，但需要显式模块和手动解析资源依赖关系。 |
| Error Transparency | API 通过 get_resource_request_status 方法提供详细的配置状态反馈，使故障排除更清晰。 | 堆栈创建期间记录错误，但可能冗长且难以追踪。 | 错误处理依赖于编程逻辑，可能需要额外的调试步骤。 | 错误记录在 Terraform CLI 中，需要检查状态文件来解析。 |
| Cross-Account and Cross-Region Support | 与假设角色无缝集成。Cloud Control API 在正确设置 AWS Identity and Access Management (IAM) 角色时，在账户和 AWS 区域间一致工作。 | 需要 StackSets 或额外参数来处理跨账户和跨区域设置。 | 需要自定义逻辑来管理假设角色和 AWS 区域特定资源。 | 需要为每个账户和 AWS 区域创建提供程序配置，这可能变得复杂。 |
| Example | [Code snippet](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/Cloud-Control-api-functionality/Centralized_Connectivity.md) |
*表 2: AWS Cloud Control API 与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）在集中连接方面的比较*
### Traffic Inspection（流量检查）
为了保护多区域工作负载及其与内部应用的通信，我们将所有流量路由通过 Network Firewall，如图 1 中的标签 2 所示。Cloud Control API 在实现此流量检查方面提供几个优势，如以下表 3 所示。
| **Feature** | **AWS Cloud Control API** | **AWS CloudFormation** | **AWS CDK** | **Terraform** |
|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| Dynamic Rule Configuration | 使用 create_resource 和 update_resource 操作，可以通过 Cloud Control API 动态定义和更新 Network Firewall 规则。这减少了完全堆栈重新部署的需要，但并非在所有场景中完全消除。 | 需要堆栈更新和重新部署来更改规则。 | 需要代码更改和重新部署来修改规则。 | 需要文件更新和状态管理来修改规则。 |
| Multi-Region Support | 重复使用 YAML 文件或使用 AWS 区域特定参数调用 API。 | 需要单独的模板或嵌套堆栈。 | 需要重复或参数化代码。 | 需要 AWS 区域特定提供程序块和手动操作。 |
| Simplified Traffic Routing | 提供声明式配置，便于集成，但复杂场景可能仍需一些手动配置。 | 路由规则需要在模板中手动配置和解析依赖关系。 | 需要显式代码定义。 | 路由必须显式声明，依赖关系手动解析。 |
| CRUD-L Operations for Updates | 使用 API 调用进行更新/审核。例如，使用 update_resource 修改防火墙规则，或使用 list_resource 获取活动防火墙配置。 | 更新涉及完全堆栈重新部署，审核需要外部脚本或手动检查。 | 更新需要代码修改和重新部署，审核需要 AWS SDK 集成。 | 更新是增量的，但需要处理状态文件，审核需要脚本或插件。 |
| Fewer Manual Errors | 通过单个 API 接口，减少了语法错误或工具间不一致（如 AWS Cloud Development Kit – [AWS CDK](https://aws.amazon.com/cdk/) 或 CloudFormation）的风险。 | 基于模板的配置容易出现依赖错误或错误配置。 | 编程逻辑增加了语法或逻辑错误的风险。 | 错误可能源于手动状态管理和资源间依赖关系。 |
| Example | [Code snippet](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/Cloud-Control-api-functionality/Network_Inspection.md) |
*表 3: AWS Cloud Control API 与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）在流量检查方面的比较*
### Multi-account setup（多账户设置）
我们的场景涉及多个账户：不同 AWS 区域中的工作负载账户和共享服务账户。实现此多账户设置对于工作负载隔离和安全性至关重要，如图 1 中的标签 3 所示。以下表 4 展示了 AWS Cloud Control API 如何促进此设置。
| **Feature** | **AWS Cloud Control API** | **AWS CloudFormation** | **AWS CDK** | **Terraform** |
|-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|
| Assumed Role Support | Cloud Control API 与 IAM 无缝集成，允许跨账户假设角色。这使您能够在成员账户中安全部署和管理资源，而无需额外设置。 | 需要在模板中手动配置 IAM 角色和账户。 | 需要显式 AWS SDK 逻辑来假设角色，增加复杂性。 | 需要多个提供程序块和角色假设逻辑，增加复杂性。 |
| Resource Sharing | 在声明式配置中使用 AWS::RAM::ResourceShare，Cloud Control API 允许您将 Transit Gateway 与 [AWS Organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 中的所有账户共享。 | 需要专用模板来处理 [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) 资源共享，增加管理开销。 | 需要代码逻辑来显式实现 AWS RAM 资源共享。 | 涉及创建资源共享模块或手动配置 AWS RAM。 |
| Security Best Practices | API 强制执行 AWS 安全原则，如最小权限，并简化跨账户的安全部署，减少操作开销。 | 模板的手动配置可能导致错误风险。 | 需要自定义逻辑来遵守安全最佳实践。 | 依赖于手动配置的 IAM 角色和提供程序设置来遵守安全。 |
| Consistency Across Accounts | 使用单个 YAML 文件为所有账户定义资源。 | 一致性必须通过模板重用或嵌套堆栈手动管理。 | 需要参数化逻辑和代码来实现账户间一致性。 | 需要可重用模块来实现一致性，需要为每个账户仔细配置。 |
| Example | [Code snippet](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/Cloud-Control-api-functionality/Multi_Account_setup.md) |
*表 4: AWS Cloud Control API 与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）在多账户设置方面的比较*
### Dynamic updates（动态更新）
为了适应工作负载增长和变化，我们需要跨 AWS 区域和账户保持路由表和防火墙规则更新，如图 1 中的标签 4 所示。AWS Cloud Control API 简化了这些动态更新，如以下表 5 所示。
| **Feature** | **AWS Cloud Control API** | **AWS CDK** | **AWS CloudFormation** | **Terraform** |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| Real-Time Resource Awareness | 使用 read_resource 操作动态获取资源（如 VPC、Transit Gateway 附件和路由表）的实时状态。 | 依赖于 AWS SDK 或手动查询资源状态。 | 不原生支持。依赖于现有堆栈模板进行更改。 | 维护状态文件（本地/后端），需要手动刷新以同步实时状态。 |
| Incremental Updates | 使用 update_resource 只修改需要更改的资源部分，减少停机时间，并避免完全堆栈重新部署。 | 需要显式逻辑来修改属性并重新部署资源堆栈。 | 整个堆栈更新，通常重新部署无关资源。 | 支持增量更新，但需要仔细处理状态文件。 |
| Automation-Friendly | Cloud Control API 的声明式特性使其易于集成到 CI/CD 管道中，确保路由表、附件和防火墙规则始终与当前工作负载同步。 | 自动化需要在 CI/CD 管道中编写脚本和逻辑，增加复杂性。 | 更改必须提交到堆栈模板，并通过 CI/CD 管道触发堆栈更新。 | 可集成到管道中，但需要显式配置状态和更新。 |
| Code | 清晰且代码行少，用于管理动态基础设施。 | 需要额外逻辑和脚本来处理复杂更改。 | 管理动态基础设施更改需要重新部署堆栈。 | 动态更新可管理，但需要状态文件一致性和仔细配置。 |
*表 5: AWS Cloud Control API 与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）在动态更新方面的比较*
### Automation（自动化）
为了最小化手动干预并确保多区域、多账户设置的一致性，我们将网络资源管理集成到 CI/CD 管道中，如图 1 中的标签 5 所示。AWS Cloud Control API 在此自动化方面提供几个优势，如表 6 所示。
| **Feature** | **AWS Cloud Control API** | **AWS CDK** | **AWS CloudFormation** | **Terraform** |
|----------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
| Unified Interface for All Stages | 从配置到更新和删除，提供相同的接口，便于集成到 CI/CD 管道中，如 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 或 [GitHub Actions](https://github.com/features/actions)。 | 需要单独的脚本和逻辑来处理不同生命周期阶段，增加复杂性。 | 模板可跨阶段使用，但需要单独配置更新和删除。 | 一致的 CLI 和状态管理简化生命周期操作，但管道复杂性增加。 |
| Declarative File Reuse | 为部署创建的 YAML 文件可在管道中重用。 | 代码驱动方法需要参数化或额外脚本来适应管道重用。 | 模板可重用，但可能需要参数化以适应管道。 | 配置文件可重用。但需要仔细管理后端状态文件以用于管道。 |
| Error Feedback in Pipelines | API 提供清晰的成功和失败状态，可在管道中程序化检查以触发重试或回滚。 | 错误处理依赖于管道脚本中的自定义逻辑。 | 堆栈创建/更新中的错误需要手动捕获或使用外部工具。 | 状态管理和应用步骤中的错误可捕获，但需要脚本来处理重试。 |
| Immediate Availability of New Features | 可能立即部署。 | 需要更新 AWS SDK 和 AWS CDK 才能使用新功能。 | 新功能需要资源规范更新，可能导致延迟。 | 需要提供程序更新来支持新 AWS 功能，可能导致延迟。 |
| Example | [Code snippet](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/Cloud-Control-api-functionality/Automation.md) |
*表 6: AWS Cloud Control API 与其他自动化选项（如 AWS CloudFormation、CDK 和 Terraform）在自动化方面的比较*
本文的其余部分将详细说明如何使用 AWS Cloud Control API 部署所讨论的真实场景。该解决方案有一些先决条件，如下所述。
## 先决条件
部署该解决方案需要以下先决条件：
1. 在 Network Deployment 账户中创建一个 IAM 用户，使用已设置 [AWS Management Console](https://aws.amazon.com/console/) 访问权限并具有 IAM 相关权限的用户登录到 Network Deployment 账户。执行以下步骤：
- 导航到 IAM 控制台。在控制台中创建 IAM 策略 ‘*network_deployment_user_policy*’，使用策略文档 [network_deployment_user_policy.json](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/code/prereqs/network-deployment-account/network_deployment_user_policy.json)。该策略具有 IAM、Amazon S3、CodePipeline、AWS CodeBuild 和 Amazon DynamoDB 的必要权限。
- 根据 [IAM 用户指南](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) 中提到的步骤创建新 IAM 用户 ‘*network_deployment_user*’。将上一步创建的 IAM 策略 ‘*network_deployment_user_policy*’ 附加到此用户。
- 为该用户创建访问密钥，以使用 [AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI) 进行编程调用。
2. 按照 [安装步骤](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 在本地安装 AWS CLI。然后，使用上一步创建的 IAM 用户 ‘*network_deployment_user*’ 的访问密钥凭证配置 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)。
```
aws configure
```
3. 按照此 [链接](https://git-scm.com/downloads) 中概述的步骤在本地安装 Git。
## 部署步骤
要使用 CodePipeline 和 AWS Cloud Control API 在组织中的账户间部署解决方案，请执行以下步骤：
1. 克隆并设置 Git 仓库
- 克隆 Git 仓库到本地机器
```
git clone https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control.git
```
- 切换到克隆目录
```
cd sample-network-deployment-using-aws-cloud-control
```
- 移除原始远程仓库连接
```
git remote remove origin
```
- 将计划用于网络部署的仓库 URL 添加为新远程 origin
```
git remote add origin <your-new-repo-url>
```
- 将所有内容推送到新仓库
```
git push -u origin <default-branch-name>
```
2. IAM 角色
- **Deployment Account Role:** 在 Network Deployment 账户中创建 “*CodePipelineRole*”。该角色由 CodePipeline 和 CodeBuild 阶段用于假设成员账户的权限，以进行资源部署。要使用 AWS Cloud Control API 部署 CodePipeline 使用的 IAM 角色，请将 [codepipeline_role.json](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/code/prereqs/network-deployment-account/codepipeline_role.json) 文件传递给以下命令：
```
aws cloudcontrol create-resource --type-name "AWS::IAM::Role" --desired-state file://codepipeline_role.json --region us-east-1 --profile <deployment-account-profile>
```
- 保存使用以下命令创建的 IAM 角色的 Amazon Resource Name (ARN)：
```
aws cloudcontrol get-resource --type-name "AWS::IAM::Role" --identifier CodePipelineRole --profile <deployment-account-profile> --region us-east-1
```
- **Member Account Role:** 在每个成员账户中创建一个 IAM 角色。更新 Principal 以使用上一步在 Network Deployment 账户中创建的正确 IAM 角色 ARN。从 Git 仓库中使用 [member_account_deployment_role.json](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/code/prereqs/member-account/member_account_deployment_role.json)，并在共享服务账户和网络账户（在本示例中视为示例成员账户）中运行以下命令。对于每个成员账户，使用适当的 profile。
```
aws cloudcontrol create-resource --type-name "AWS::IAM::Role" --desired-state file://member_account_deployment_role.json --region us-east-1 --profile <member-account-1-profile>
```
3. CodeBuild 项目
- 使用 Python 环境作为运行时，并使用先前创建的 CodePipelineRole。参考仓库根目录中的 [buildspec.yml](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/buildspec.yml) 文件。
```
aws codebuild create-project --name "MultiAccountCloudControlBuild" --description "CodeBuild project for deploying AWS resources." --source type=CODEPIPELINE --artifacts type=CODEPIPELINE --environment type=LINUX_CONTAINER,image=aws/codebuild/standard:5.0,computeType=BUILD_GENERAL1_SMALL --service-role "arn:aws:iam::deployment-account-id:role/CodePipelineRole" --region us-east-1 --profile <deployment-account-profile>
```
4. Amazon S3 工件存储桶
- 在 Network Deployment 账户中创建 S3 桶用于工件存储。该桶由 CodePipeline 使用。使用以下命令创建 S3 桶。
```
aws s3api create-bucket --bucket YourS3BucketName --region us-east-1 --profile <deployment-account-profile>
```
- 启用桶版本控制。
```
aws s3api put-bucket-versioning --bucket YourS3BucketName --versioning-configuration Status=Enabled --region us-east-1 --profile <deployment-account-profile>
```
5. 在 Network Deployment 账户中设置 CodePipeline
- 在 US East (N. Virginia) 区域（us-east-1）或首选 AWS 区域中创建 CodePipeline。本文使用 US East (N. Virginia) 区域。使用一个分支（如 cloud-control-branch）来触发管道，并将 CodeBuild 项目（在步骤 3 中创建）链接到执行脚本。
- 参考 [codepipeline.json](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/code/prereqs/network-deployment-account/codepipeline.json)，并使用 Network Deployment 账户中创建的 CodePipeline 角色的 ARN 更新 RoleArn。
- 在 ArtifactStore 下，更新存储工件的 S3 桶名称。更新 Git VCS 配置。然后，运行以下命令创建 CodePipeline。
```
aws cloudcontrol create-resource --type-name "AWS::CodePipeline::Pipeline" --desired-state file://codepipeline.json --profile <deployment-account-profile>
```
- 检查资源创建状态：
```
aws cloudcontrol get-resource-request-status --request-token "RequestToken"
```
6. 在 Network Deployment 账户中设置 DynamoDB 表
- 在 us-east-1 区域或其他首选 AWS 区域中创建 DynamoDB 表。本文在 us-east-1 区域中操作。要部署 DynamoDB 表，请参考 [dynamodb_table.json](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/code/prereqs/network-deployment-account/dynamodb_table.json) 并运行以下命令创建 DynamoDB 表：
```
aws cloudcontrol create-resource --type-name "AWS::DynamoDB::Table" --desired-state file://dynamodb_table.json --region us-east-1 --profile <deployment-account-profile>
```
7. 更新配置文件并调用 CI/CD 管道
- 部署脚本和支持的 YAML 配置文件位于 [scripts 文件夹](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/tree/main/code/scripts)。更新账户 ID、VPC CIDR、子网 CIDR 和/或命名约定。
- 提供并更新用户信息后，将更改提交到在步骤 5 中部署的 CodePipeline 的源 Git 仓库。管道的 CodeBuild 阶段引用 buildspec 文件并执行部署脚本。 [readme.md](https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control/blob/main/README.md) 文件解释了部署脚本如何使用 YAML 配置文件。
## 结论
本文的比较分析显示，AWS Cloud Control API 解决了传统 IaC 工具（如 AWS CloudFormation、AWS CDK 和 Terraform）面临的许多挑战。其一致的 Create、Read、Update、Delete 和 List（CRUD-L）接口、实时资源感知以及流畅的跨账户管理功能，使其适合具有复杂多账户网络设置的企业。
组织在扩展和保护云网络方面面临挑战。AWS Cloud Control API 提供了一个统一的、声明式的资源管理接口，简化了跨多个账户和 AWS 区域设置和维护网络架构的过程。它支持动态资源更新、无缝集成 CI/CD 管道，以及无需工具特定更新即可立即访问新 AWS 功能。
## 关于作者
### Shiva Vaidyanathan
Shiva Vaidyanathan 是 AWS 的首席云架构师。他为客户提供技术指导、设计并领导实施项目，以确保他们在 AWS 上的成功。他致力于利用前沿生成式 AI（Generative AI）技术简化云网络。在此之前，他参与了多个 NSF 资助的研究项目，专注于在公共云基础设施中进行安全计算。他拥有罗格斯大学计算机科学硕士学位和纽约大学电气工程硕士学位。
### Omkar Nyalpelly
Omkar Nyalpelly 专注于网络架构和自动化，特别关注 AWS Landing Zones。他拥有丰富的 AWS 专业知识和在 SDLC 中应用 DevOps 方法论的背景，领导关键实施和迁移项目。他的专业知识确保了云操作的安全、可扩展和高效。在 AWS 专业服务中，他构建以客户为中心的解决方案，利用生成式 AI 增强云基础设施自动化。工作之外，他喜欢打板球、棒球和摄影。Omkar 拥有南卫理公会大学网络和电信硕士学位。
<!-- AI_TASK_END: AI全文翻译 -->