本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 更新中的计算环境 AWS Batch
AWS Batch 提供了多种更新计算环境的策略，每种策略都针对特定的更新场景和要求而设计。这些方法使用相同的底层更新 API，但代表了用于有效管理更新的不同规范方法。您可以使用 AWS Batch 控制台或管理这些更新 AWS CLI。了解这些策略有助您选择最适合自己需求的方法，同时尽可能减少工作负载中断。
本主题概述了可用的更新策略，并提供了有关每种方法的使用场景的指导。有关详细操作过程，请参阅每种更新策略的相应部分。
**重要**
AWS Batch 代表您并在您的账户中创建和管理多个 AWS 资源，包括亚马逊 EC2 启动模板、亚马逊 EC2 Auto Scaling 群组、亚马逊 EC2 竞价队列和亚马逊 ECS 集群。这些托管式资源均经过专门配置，以确保 AWS Batch 的最优运行状态。除非在 AWS Batch 文档中明确说明，否则手动修改这些 AWS Batch托管资源可能会导致意外行为，包括`INVALID`计算环境、实例扩展行为不佳、工作负载处理延迟或意外成本。不能确定 AWS Batch 服务一定能够支持这些手动修改。请务必使用支持的控制台 AWS Batch APIs 或 AWS Batch 控制台来管理您的计算环境。
不支持的手动修改包括在托管的 Amazon ECS 集群上运行您自己的 AWS Batch Amazon ECS 任务或服务，或者直接在托管实例上 AWS Batch启动其他进程、守护程序或服务。 AWS Batch 完全控制托管计算环境中的计算资源，并且可以随时终止实例、停止任务或扩展集群。您在这些托管资源上提交 AWS Batch 任务之外运行的任何工作负载都可以在没有警告的情况下中断。在 AWS Batch托管集群和实例上运行非AWS Batch 工作负载也会干扰 AWS Batch 作业调度和实例扩展。
**Topics**
+ [计算环境更新策略](#update-strategies)
+ [选择合适的更新策略](#choosing-update-strategies)
+ [AMI 更新注意事项](#ami-update-considerations)
+ [执行扩缩更新](scaling-updates.md)
+ [执行基础设施更新](infrastructure-updates.md)
+ [为计算环境执行 blue/green 更新](blue-green-updates.md)
## 计算环境更新策略
使用扩缩更新或基础设施更新策略时，您的计算环境将就地更新。对于 blue/green 更新策略，您可以创建一个新的计算环境（绿色），然后将工作负载从旧计算环境（蓝色）迁移到新的计算环境（绿色）。
AWS Batch 为计算环境更新提供了三种不同的策略：
扩缩更新
扩缩更新通过增加或移除实例来调整计算环境的容量，但不会替换现有实例。这是最快的更新场景，不需要停机时间。需要更改容量设置时使用扩展更新 (vCPUs)。此类更新通常会在几分钟内完成。
Fargate 更新的执行过程与扩缩更新相同。有关更多信息，请参阅 [执行扩缩更新](scaling-updates.md)。
基础架构更新
基础设施更新会将计算环境中的实例替换为具有更新后设置的新实例。此类更新需要特定的服务角色和分配策略配置，但停机时间极少，正在运行的作业可能会出现中断。需要修改实例类型、AMI 配置、联网设置、服务角色、环境状态或其他基础设施组件时，应使用基础设施更新。根据作业完成情况，此类更新通常会在 10-30 分钟内完成。
有关更多信息，请参阅 [执行基础设施更新](infrastructure-updates.md)。
蓝绿更新
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/green在需要零停机时间、想要在完全部署之前测试更改、需要快速回滚功能或使用不支持的配置进行基础架构更新时进行更新。完成更新所需的时间因情况而异，并且由您控制。
有关更多信息，请参阅 [为计算环境执行 blue/green 更新](blue-green-updates.md)。
## 选择合适的更新策略
使用以下决策指南来选择最适合您需求的更新策略：
### 选择扩缩更新的场景
当你只需要调整计算容量 (vCPUs) 时，选择扩展更新策略。需要在无停机时间的情况下快速更新且无需更改基础设施配置时，扩缩更新是理想的选择。
有关详细步骤，请参阅 [执行扩缩更新](scaling-updates.md)。
### 选择基础设施更新的场景
需要修改实例类型、AMI 设置、服务角色、环境状态或联网配置时，应选择基础设施更新策略。您的环境必须使用*AWSServiceRoleForBatch*服务相关角色和`BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`、或`SPOT_PRICE_CAPACITY_OPTIMIZED`的分配策略。如果更新期间可以接受某些作业中断，并且您希望自动更新到最新版本的 Amazon ECS 优化型 AMI，则非常适合选择基础设施更新。
有关详细步骤，请参阅 [执行基础设施更新](infrastructure-updates.md)。
### 在何时选择 blue/green 更新
如果您的工作负载需要零停机时间，或者您需要在过渡生产工作负载之前测试更改，请选择 blue/green 更新策略。当快速回滚功能很重要、您的环境使用`BEST_FIT`分配策略或者您的环境不使用*AWSServiceRoleForBatch*服务相关角色时，这种方法是必不可少的。 Blue/green 当您使用需要手动更新或需要进行重大配置更改 AMIs 的自定义版本时，更新也是最佳选择。
有关详细步骤，请参阅 [为计算环境执行 blue/green 更新](blue-green-updates.md)。
## AMI 更新注意事项
更新方法 AMIs 取决于您的计算环境配置。
### 将 AWS Batch 提供的默认 AMI 更新为最新
AWS Batch 当满足所有这些条件时，可以在[基础设施](infrastructure-updates.md#infrastructure-updates.title)更新期间更新到最新 Amazon ECS 优化的 AMI：
**注意**
基础设施更新完成后，`updateToLatestImageVersion` 将设置为 `false`。要启动其他更新，必须将 `updateToLatestImageVersion` 设置为 `true`。
+ 计算环境使用*AWSServiceRoleForBatch*服务相关角色
+ 分配策略设置为 `BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED` 或 `SPOT_PRICE_CAPACITY_OPTIMIZED`
+ 未在 `imageId`、`imageIdOverride` 或启动模板中显式指定 AMI ID
+ `updateToLatestImageVersion` 设置为 `true`
### AMI 使用 blue/green 部署进行更新
AMIs 在以下情况下，必须使用 blue/green 部署进行更新：
+ 使用 `BEST_FIT` 分配策略时（不支持基础设施更新）
+ 不使用*AWSServiceRoleForBatch*[服务相关角色](using-service-linked-roles-batch-general.md)时
### 自定义 AMI 的 AMI 更新
如果您在计算环境的启动模板中指定自定义 AMI，则 EC2 配置中的`imageId``imageIdOverride`参数或参数 AWS Batch 不会在基础设施更新期间自动更新您的自定义 AMI。您可以通过在创建计算环境时最初使用的参数中指定新 ID 来更新自定义 AMI ID。如果您想切换到使用 AWS Batch提供的 AMI，则可以通过在计算环境更新中删除自定义 AMI ID 来实现。
# 执行扩缩更新
扩缩更新通过增加或移除实例来调整计算环境的容量。这是最快的更新策略，不需要替换现有实例。扩缩更新适用于任何服务角色类型和分配策略，因此是最灵活的更新选项。
## 触发扩缩更新的更改
当您仅修改以下设置时， AWS Batch 将执行扩缩更新。如果您修改了其中任何设置以及其他计算环境设置，[请改为 AWS Batch 执行基础架构更新](infrastructure-updates.md#infrastructure-updates.title)。
仅修改以下设置时会触发扩缩更新：
+ `desiredvCpus`— 设置环境的目标数 v CPUs 。
+ `maxvCpus`— 定义可以启动的最大 v CPUs 数。
+ `minvCpus`— 指定CPUs 要保持的最小 v 数。
+ `minScaleDownDelayMinutes`— 指定任务完成后实例在计算环境中 AWS Batch 保持运行的最短时间（以分钟为单位）。
**注意**
`minScaleDownDelayMinutes`不适用于在基础设施更新期间被替换的实例。
对于 Fargate 计算环境，您还可以修改以下设置以执行扩缩更新：
+ `securityGroupIds`— 计算环境的安全组 IDs 。
+ `subnets`：计算环境的子网。
**注意**
我们建议不要使用`desiredvCpus`来启动缩放更新，因为 AWS Batch 会动态调整`desiredvCpus`。而应使用 `minvCpus`。
更新 `desiredvCpus` 时，该值必须介于 `minvCpus` 和 `maxvCpus` 之间。新值必须大于或等于当前的 `desiredvCpus`。有关更多信息，请参阅 [更新`desiredvCpus`设置时出现错误消息](error-desired-vcpus-update.md)。
**重要**
如果您将其中任何一个扩展设置与其他计算环境设置（例如实例类型 IDs、AMI 或启动模板）一起修改，则 AWS Batch 会执行基础架构更新而不是扩展更新。基础设施更新需要更长的时间，并且可能会替换现有实例。
------
#### [ Performing scaling updates using the AWS 管理控制台 ]
1. 打开 AWS Batch 控制台，网址为[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)。
1. 在导航窗格中，选择**环境**，然后选择**计算环境**选项卡。
1. 选择要更新的计算环境。
1. 选择**操作**，然后选择**编辑**。
1. 修改一个或多个[支持扩缩更新的设置](#scaling-updates-triggers)。例如：
+ 对于**最小值 v CPUs**，输入最小值 v CPUs。
+ 在**所需的 v** 中CPUs，输入所需的 v 数CPUs。
+ 对于**最大 v CPUs**，请输入最大值 v CPUs。
1. 选择**保存更改**。
1. 监控计算环境状态。更新应该很快完成，因为只涉及扩缩操作。
------
#### [ Performing scaling updates using the AWS CLI ]
使用 **update-compute-environment** 命令执行扩缩更新。以下两个示例演示了常见的扩缩操作：您可以修改以下一个或多个[支持扩缩更新的设置](#scaling-updates-triggers)
+ 此示例更新了所需的 v、最小值和最大值 vCPUs：
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## 监控扩缩更新
使用 AWS Batch 控制台监控您的扩展更新，以查看计算环境状态并检查实例数量和 vCPU 指标。您还可以使用 with AWS CLI **describe-compute-environments** 命令来检查状态并监控实例计数和 vCPU 值。
# 执行基础设施更新
基础设施更新会将计算环境中的实例替换为具有更新后设置的新实例。此更新策略需要的时间比扩缩更新更长，并且需要特定的服务角色和分配策略设置。基础设施更新是一种在保持服务可用性的同时修改基本计算环境配置的方法。
**重要**
基础架构更新需要*AWSServiceRoleForBatch*服务相关角色和`BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`、或`SPOT_PRICE_CAPACITY_OPTIMIZED`的分配策略。如果您的环境不符合这些要求，请改用 blue/green 更新。
## 触发基础设施更新的更改
修改以下任何设置时，将 AWS Batch 执行基础架构更新。当您同时修改这些设置以及扩缩更新设置时，也会执行基础设施更新。
以下设置会触发基础设施更新：
**计算配置**
+ `allocationStrategy`— 确定如何 AWS Batch 选择实例类型。
+ `instanceTypes`：指定要使用的 EC2 实例类型。
+ `bidPercentage`：竞价型实例的最大按需价格百分比。
+ `type`：计算环境类型（`EC2` 或 `SPOT`）。
**AMI 和启动配置**
+ `imageId`：要用于实例的特定 AMI。
+ `ec2Configuration`：EC2 配置，包括 `imageIdOverride`。
+ `launchTemplate`：EC2 启动模板设置。
+ `ec2KeyPair`：用于实例访问的 SSH 密钥对。
+ `updateToLatestImageVersion`：AMI 自动更新设置。
**网络和安全性**
+ `subnets`：所启动的实例的 VPC 子网（适用于 EC2 计算环境）。
+ `securityGroupIds`：实例的安全组（适用于 EC2 计算环境）。
+ `placementGroup`：EC2 置放群组配置。
**其他设置**
+ `instanceRole`：用于 EC2 实例的 IAM 角色。
+ `tags`：应用到 EC2 实例的标签。
**重要**
如果您修改了任何基础设施更新设置以及扩缩更新设置（例如 `desiredvCpus`、`maxvCpus`、或 `minvCpus`），则 AWS Batch 会执行基础设施更新。基础设施更新需要是时间比扩缩更新更长。
## 基础设施更新期间的 AMI 选择
在基础设施更新期间，计算环境的 AMI ID 可能会发生变化，具体取决于 AMIs 是否在这三个设置中指定。 AMIs 在`imageId`（in`computeResources`）、`imageIdOverride`（in）或中`ec2Configuration`指定的启动模板中指定`launchTemplate`。假设在这些设置中 IDs 均未指定 AMI，且`updateToLatestImageVersion`设置为`true`。然后，将支持的最新 Amazon ECS 优化 AWS Batch 的 AMI 用于任何基础设施更新。
如果至少在其中一个设置中指定了 AMI ID，则更新将取决于提供了更新前使用的 AMI ID 的设置。创建计算环境时，选择 AMI ID 的优先级首先是启动模板，然后是`imageId`设置，最后是`imageIdOverride`设置。但是，如果使用的 AMI ID 来自启动模板，则更新`imageId`或`imageIdOverride`设置都不会更新 AMI ID。更新从启动模板中选择的 AMI ID 的唯一方法是更新启动模板。如果启动模板的版本参数为`$Default`或`$Latest`，则会评估指定启动模板的默认版本或最新版本。如果默认选择了不同的 AMI ID 或选择了最新版本的启动模板，则将在更新中使用该 AMI ID。
如果未使用启动模板来选择 AMI ID，则会使用`imageId`或`imageIdOverride`参数中指定的 AMI ID。如果同时指定了这两个参数，则会使用`imageIdOverride`参数中指定的 AMI ID。
假设计算环境使用由`imageId`、`imageIdOverride`或`launchTemplate`参数指定的 AMI ID，并且要使用由 AWS Batch支持的最新 Amazon ECS 优化 AMI。然后，更新必须删除提供 AMI 的设置 IDs。对于`imageId`，需要为该参数指定一个空字符串。对于`imageIdOverride`，需要为`ec2Configuration`参数指定一个空字符串。
如果 AMI ID 来自启动模板，则可以通过以下任一方式更改为支持的最新 Amazon ECS 优化 AWS Batch 的 AMI：
+ 通过为`launchTemplateId`或`launchTemplateName`参数指定一个空字符串，删除启动模板。这将删除整个启动模板，而不仅仅是 AMI ID。
+ 如果启动模板的更新版本未指定 AMI ID，则必须将`updateToLatestImageVersion`参数设置为`true`。
## 更新期间的作业处理
使用更新策略配置在基础设施更新期间如何处理正在运行的作业。如果设置为 `terminateJobsOnUpdate=true`，则正在运行的作业将立即终止，`jobExecutionTimeoutMinutes` 设置将被忽略，并且更新将在可以替换实例时立即继续执行。如果设置为 `terminateJobsOnUpdate=false`，则正在运行的作业将在指定的超时期限内继续运行，默认超时期限为 30 分钟，超过超时期限的作业将被终止。
**注意**
要重试在更新期间被终止的作业，请配置作业重试策略。有关更多信息，请参阅 [自动作业重试](job_retries.md)。
------
#### [ Performing infrastructure updates using the AWS 管理控制台 ]
1. 打开 AWS Batch 控制台，网址为[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)。
1. 在导航窗格中，选择**环境**，然后选择**计算环境**选项卡。
1. 选择要更新的计算环境。
1. 选择**操作**，然后选择**编辑**。
1. 在**更新行为**部分中，配置如何处理正在运行的作业：
+ 选择**将 AMI 更新到最新版本**，以将 AMI 更新为最新版本。
+ 选择**更新时立即终止作业**，以在更新进程运行时终止作业。
+ 对于**作业执行超时**，输入在更新进程启动之前要等待的分钟数。
1. 修改一项或多项[要求使用基础设施更新的设置](#infrastructure-updates-triggers)。例如：
+ **实例角色**
+ **使用 EC2 竞价型实例**
+ **允许的实例类型**
+ **置放群组**
+ **EC2 密钥对**
+ **EC2 配置**
+ **启动模板**
+ **子网**
+ **安全组**
1. 选择**保存更改**。
1. 监控计算环境状态。环境将在更新过程中显示 `UPDATING` 状态。
------
#### [ Performing infrastructure updates using the AWS CLI ]
使用 **update-compute-environment** 命令并更改一项或多项[要求使用基础设施更新的设置](#infrastructure-updates-triggers)。以下三个示例是常见的基础设施操作。
+ 此示例会更新实例类型并配置更新策略：
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ 此示例会更新 VPC 子网和安全组：
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ 此示例会自动更新到最新版本的 Amazon ECS 优化型 AMI：
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## 监控基础设施更新
使用 AWS Batch 控制台监控您的基础设施更新，以观察计算环境状态的变化`UPDATING`，监控实例替换进度，并检查是否有任何失败的更新。一旦计算环境状态变为 `VAILD`，即表示更新成功。您还可以使用 CloudWatch 来跟踪实例终止事件和监控更新期间的任务状态。使用 AWS CLI，使用**describe-compute-environments**命令来检查状态和监控实例生命周期事件。
# 为计算环境执行 blue/green 更新
blue/green 更新是一种更新策略，它通过在现有计算环境（蓝色）的同时创建新的计算环境（绿色）来减少停机时间和风险。这种方法允许您在保持现有环境正常运行的同时，逐步将工作负载转移到新环境。 Blue/green 更新提供了最安全的更新路径，并且适用于任何服务角色类型或分配策略。
## 概述
蓝绿更新具有多项优势，使其非常适用于生产环境。在更新过程中，您的工作负载会继续运行，从而实现*零停机时间*。这种方法支持*轻松回滚*功能，让您能够在出现问题时快速恢复到原始环境。您可以实施*逐步转移*策略，在生产工作负载完全切换过去之前，先验证新环境的性能。使用这种方法时，原始环境将保持不变并可以正常运行，直到您选择将其移除为止，因此还具有极佳的*风险缓解*作用。
### 何时需要 blue/green 更新
在以下情况下，您必须使用 blue/green 更新：
+ 当您的计算环境使用 `BEST_FIT` 分配策略时（不支持基础设施更新）
+ 当您的计算环境不使用*AWSServiceRoleForBatch*服务相关角色时
+ 当您需要在不同的服务角色类型之间转换时
### 何时建议 blue/green 更新
Blue/green updates are particularly recommended for production environments where zero downtime is critical for your workloads. This approach works well when you need to test new configurations before transitioning production workloads, ensuring that changes meet your performance and reliability requirements. Choose blue/green在快速回滚功能对您的操作很重要时进行更新，尤其是在您要更新 AMIs 带有重大更改的自定义功能时。当您想在完全提交更改之前验证性能特征和行为，确保更新过程顺畅无误时，也非常适合使用此方法。
### 先决条件
在执行 blue/green 更新之前，请确保：
+ 具有创建和管理计算环境所需的适当 [IAM 权限](IAM_policies.md#IAM_policies.title)
+ 具有查看和修改作业队列设置的访问权限
+ 为您的作业定义配置了作业重试策略，用于处理转移期间可能出现的作业失败。有关更多信息，请参阅 [自动作业重试](job_retries.md)。
+ 拥有新计算环境的 AMI ID。您可以指定：
+ 最近批准的 Amazon ECS 优化型 AMI 版本（默认使用）
+ 符合 Amazon ECS 容器实例 AMI 规范的自定义 AMI。您可以通过以下方式之一来指定自定义 AMI：
+ 使用 EC2 配置中的**映像 ID 覆盖**字段
+ 在启动模板中指定
有关创建自定义的更多信息 AMIs，请参阅[教程：创建计算资源 AMI](create-batch-ami.md)。
在创建新环境之前，您需要记录现有计算环境的配置。您可以使用 AWS 管理控制台 或来执行此操作 AWS CLI。
**注意**
以下过程详细介绍了如何执行仅更改 AMI 的 blue/green 更新。您可以更新新环境的其他设置。
**重要**
当您移除旧（蓝色）计算环境时，所有当前正在这些实例上运行的作业都将失败，因为这些实例将被终止。在作业定义中配置作业重试策略以自动处理这些失败。有关更多信息，请参阅 [自动作业重试](job_retries.md)。
确信新环境能够正常运行后：
编辑作业队列以移除旧计算环境。
等待旧环境中所有仍在运行的作业完成运行。
删除旧的计算环境。
------
#### [ Performing blue/green updates using the AWS 管理控制台 ]
1. 克隆当前计算环境
1. 打开 AWS Batch 控制台，网址为[https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)。
1. 选择您现有的计算环境。
1. 选择**操作**，然后选择**克隆**。
1. 对于**名称**，输入新计算环境的唯一名称。
1. 选择**下一步**。
1. 在**实例配置**部分中，更新 AMI 设置：
1. 展开**其他配置**。
1. 对于 **EC2 配置**，请在**映像类型**中指定新的 AMI 类型，并在**映像 ID 覆盖**字段中指定 AMI ID。
1. 选择**下一步**。
1. 对于**网络配置**，请选择**下一步**。
1. 检查从现有环境中自动复制的其他设置。
1. 选择**创建计算环境**。
1. 等待新计算环境的状态变为 `VALID`。
1. 更改作业队列顺序
1. 在导航窗格中，选择 **作业队列**。
1. 选择与您的现有计算环境关联的作业队列。
1. 选择**编辑**。
1. 在**已连接的计算环境**下，添加新的计算环境：
+ 为新计算环境添加一个比现有环境更高的顺序号以转移工作负载。
+ 验证新环境能够正常运行后，可以通过为新环境提供一个更低的顺序号，从而使其成为主环境。
1. 选择**更新作业队列**。
1. 清理
1. 监控新环境中的作业执行情况，确保一切按预期运行。
1. 确信新环境能够正常运行后：
1. 编辑作业队列以移除旧计算环境。
1. 等待旧环境中所有仍在运行的作业完成运行。
1. 删除旧的计算环境。
------
#### [ Performing blue/green updates using the AWS CLI ]
1. 要使用获取配置 AWS CLI，请使用以下命令：
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
保存输出以备在创建新环境时参考。
1. 使用现有环境中的配置创建新计算环境，不过要使用新的 AMI。示例命令结构如下：
将示例值替换为上一步中的实际配置：
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. 等待新环境的状态变为可用：
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. 将新计算环境添加到您的作业队列：
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. 完成验证后，再次更新以使新环境成为主环境：
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
旧环境中的所有作业完成后禁用旧环境，然后将其删除：
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------