# Compute resource AMIs By default, AWS Batch managed compute environments use a recent, approved version of the Amazon ECS optimized AMI for compute resources. However, you might want to create your own AMI to use for your managed and unmanaged compute environments. If you require any of the following, we recommend you create your own AMI: + Increasing the storage size of your AMI root or data volumes. + Adding instance storage volumes for supported Amazon EC2 instance types. + Customizing the Amazon ECS container agent. + Customizing Docker + Configuring a GPU workload AMI to allow containers to access GPU hardware on supported Amazon EC2 instance types **Note** After a compute environment is created, AWS Batch doesn't upgrade the AMIs in the compute environment. AWS Batch also doesn't update the AMIs in your compute environment when a newer version of the Amazon ECS optimized AMI is available. You're responsible for the management of the guest operating system. This includes any updates and security patches. You're also responsible for any additional application software or utilities that you install on the compute resources. To use a new AMI for your AWS Batch jobs, do the following: Create a new compute environment with the new AMI. Add the compute environment to an existing job queue. Remove the earlier compute environment from your job queue. Delete the earlier compute environment. In April 2022, AWS Batch added enhanced support for updating compute environments. For more information, see [Update a compute environment in AWS Batch](updating-compute-environments.md). To use the enhanced updating of compute environments to update AMIs, follow these rules: Either don't set the service role ([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole)) parameter or set it to the **AWSServiceRoleForBatch** service-linked role. Set the allocation strategy ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) parameter to `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED`, or `SPOT_PRICE_CAPACITY_OPTIMIZED`. Set the update to latest image version ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) parameter to `true`. Don't specify an AMI ID in [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId), [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride) (in [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)), or in the launch template ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)). When you don't specify an AMI ID, AWS Batch selects the latest Amazon ECS optimized AMI that AWS Batch supports at the time the infrastructure update is initiated. Alternatively, you can specify the AMI ID in the `imageId` or `imageIdOverride` parameters. Or, you can specify the launch template that's identified by the `LaunchTemplate` properties. Changing any of these properties starts an infrastructure update. If the AMI ID is specified in the launch template, the AMI ID can't be replaced by specifying an AMI ID in either the `imageId` or `imageIdOverride` parameters. The AMI ID can only be replaced by specifying a different launch template. If the launch template version is set to `$Default` or `$Latest`, the AMI ID can be replaced by setting either a new default version for the launch template (if `$Default`) or by adding a new version to the launch template (if `$Latest`). If these rules are followed, any update that starts an infrastructure update causes the AMI ID to be re-selected. If the [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version) setting in the launch template ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) is set to `$Latest` or `$Default`, the latest or default version of the launch template is evaluated up at the time of the infrastructure update, even if the [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate) wasn't updated. **Topics** + [Compute resource AMI specification](batch-ami-spec.md) + [AMI selection order](ami-selection-order.md) + [Managing AMI versions in compute environments](managing-ami-versions.md) + [Tutorial: Create a compute resource AMI](create-batch-ami.md) + [Use a GPU workload AMI](batch-gpu-ami.md) + [Amazon Linux deprecation](al1-ami-deprecation.md) + [Amazon EKS Amazon Linux 2 AMI deprecation](eks-al2-ami-deprecation.md) + [Amazon ECS Amazon Linux 2 AMI deprecation](ecs-al2-ami-deprecation.md) # Compute resource AMI specification The basic AWS Batch compute resource AMI specification consists of the following: Required + A modern Linux distribution that's running at least version 3.10 of the Linux kernel on an HVM virtualization type AMI. Windows containers aren't supported. **Important** Multi-node parallel jobs can only run on compute resources that were launched on an Amazon Linux instance with the `ecs-init` package installed. We recommend that you use the default Amazon ECS optimized AMI when you create your compute environment. You can do this by not specifying a custom AMI. For more information, see [Multi-node parallel jobs](multi-node-parallel-jobs.md). + The Amazon ECS container agent. We recommend that you use the latest version. For more information, see [Installing the Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) in the *Amazon Elastic Container Service Developer Guide*. + The `awslogs` log driver must be specified as an available log driver with the `ECS_AVAILABLE_LOGGING_DRIVERS` environment variable when the Amazon ECS container agent is started. For more information, see [Amazon ECS Container Agent Configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) in the *Amazon Elastic Container Service Developer Guide*. + A Docker daemon that's running at least version 1.9, and any Docker runtime dependencies. For more information, see [Check runtime dependencies](https://docs.docker.com/engine/installation/binaries/#check-runtime-dependencies) in the Docker documentation. **Note** We recommend the Docker version that ships with and is tested with the corresponding Amazon ECS agent version that you're using. Amazon ECS provides a changelog for the Linux variant of the Amazon ECS-optimized AMI on GitHub. For more information, see [Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md). Recommended + An initialization and nanny process to run and monitor the Amazon ECS agent. The Amazon ECS optimized AMI uses the `ecs-init` upstart process, and other operating systems might use `systemd`. For more information and examples, see [Example container instance User Data Configuration Scripts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) in the *Amazon Elastic Container Service Developer Guide*. For more information about `ecs-init`, see the [`ecs-init` project](https://github.com/aws/amazon-ecs-init) on GitHub. At a minimum, managed compute environments require the Amazon ECS agent to start at boot. If the Amazon ECS agent isn't running on your compute resource, then it can't accept jobs from AWS Batch. The Amazon ECS optimized AMI is preconfigured with these requirements and recommendations. We recommend that you use the Amazon ECS optimized AMI or an Amazon Linux AMI with the `ecs-init` package that's installed for your compute resources. Choose another AMI if your application requires a specific operating system or a Docker version that's not yet available in those AMIs. For more information, see [Amazon ECS-Optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) in the *Amazon Elastic Container Service Developer Guide*. # AMI selection order AWS Batch determines the Amazon Machine Image (AMI) for compute resources using the following priority order. Understanding this order helps you understand why AWS Batch chose a particular AMI for your compute environment: 1. **Launch template override AMI** - If a launch template override for the launched instance has an image, then its image is used. 1. **Compute resources image ID (deprecated)** - If set, this compute environment AMI is used. *Note: Deprecated field; use ec2Configuration.imageIdOverride instead.* 1. **EC2 configuration image ID override** - If specified, the image in this field is used. 1. **Launch template AMI** - If the compute environment has an associated launch template with an image, then this image will be used. 1. **AWS default AMI** - If none of the above are configured, AWS Batch selects a default AMI based on the specified imageType in the ec2Configuration. **Note** The ec2Configuration parameter is optional. When omitted, AWS Batch automatically selects an appropriate ec2Configuration and default AMI based on the instance types launched in the compute environment. **Note** This AMI selection order does not apply to Fargate compute environments. ## AMI selection order from highest to lowest priority 1. **Launch template override AMI** (highest precedence) **API field:** `overrides[].launchTemplateId` with target instance types **Reference:** [LaunchTemplateSpecification](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html) Override templates target specific instance types and provide more granular control than the default launch template. They take precedence over all other AMI specifications for matching instance types. ``` { "computeResources": { "launchTemplate": { "launchTemplateId": "lt-default", "overrides": [ { "launchTemplateId": "lt-gpu-optimized", "targetInstanceTypes": ["p3.2xlarge", "g4dn.xlarge"] } ] } } } ``` 1. **Compute resources image ID** **API field:** `computeResources.imageId` **Reference:** [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) You can specify an AMI directly at the compute environment level. This takes precedence over EC2 configuration overrides and launch templates (except override templates). In a compute environment with multiple EC2 configurations (e.g. for `ECS_AL2023` and `ECS_AL2023_NVIDIA`), the AMI ID specified here is used for all EC2 configurations. **Important** The `imageId` field is deprecated. Please use `ec2Configuration.imageIdOverride` instead. ``` { "computeResources": { "imageId": "ami-12345678", "instanceTypes": ["m5.large", "m5.xlarge"] } } ``` 1. **EC2 configuration image ID override** **API field:** `computeResources.ec2Configuration[].imageIdOverride` **Reference:** [Ec2Configuration](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html) EC2 configuration provides image type-specific overrides. This setting overrides the default AMI selection and launch template AMI for the specified image type. ``` { "computeResources": { "ec2Configuration": [ { "imageType": "ECS_AL2", "imageIdOverride": "ami-87654321" } ] } } ``` 1. **Launch template AMI** **API field:** `ImageId` in the Amazon EC2 launch template **Reference:** [Use Amazon EC2 launch templates with AWS Batch](launch-templates.md) When you specify an AMI in the launch template, it takes precedence over the default AMI selection but is overridden by higher precedence settings. ``` // EC2 Launch Template content { "LaunchTemplateName": "my-batch-template", "LaunchTemplateData": { "ImageId": "ami-12345678" } } ``` Referenced by the AWS Batch launch template: ``` // Batch Launch Template content { "computeResources": { "launchTemplate": { "launchTemplateName": "my-batch-template", "version": "$Latest" } } } ``` 1. **AWS default AMI** (lowest precedence) **API field:** Determined by `computeResources.ec2Configuration[].imageType` **Reference:** [Ec2Configuration imageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html) When no custom AMI is specified, AWS Batch automatically selects the latest approved Amazon Amazon ECS-optimized AMI based on the image type. **Note** The `ec2Configuration` is optional. AWS Batch will select an appropriate default AMI if no `ec2Configuration` is specified. ``` { "computeResources": { "ec2Configuration": [ { "imageType": "ECS_AL2023" } ] } } ``` # Managing AMI versions in compute environments AWS Batch provides visibility into the Amazon Machine Images (AMIs) that your compute environments use. ## Viewing AMI status You can view the status of AMIs used in your compute environments through the AWS Batch console or by using [describe-compute-environments](https://docs.aws.amazon.com/cli/latest/reference/batch/describe-compute-environments.html) command. ------ #### [ Console ] In the AWS Batch console, AMI status information appears in two locations with the following status values: + **Latest** – Using the most recent AMI supported by AWS Batch. + **Update available** – An update is available. **Note** AMI status information appears only for AWS Batch-managed AMIs. The status does not appear when images are specified in `imageId` (deprecated), `imageIdOverride`, or in the default launch template. The status does not appear when the compute environment has a launch template override. For more information on AMI selection, see [AMI selection order](ami-selection-order.md). The compute environments page displays a **Batch image status** column that shows the overall `batchImageStatus` for each compute environment. If a compute environment has multiple AMIs and any one AMI has **Update available**, the console shows **Update available** for the entire compute environment. **Note** The status appears after the compute environment has started scaling for any **Image type**. On the compute environment detail page, the **Ec2 configuration** section of the **Compute resources** tab shows the **Batch image status** for each **Image type** in the compute environment. If an **Image type** has multiple AMIs and any one AMI has **Update available**, the console shows **Update available** for that **Image type**. **Note** The status appears for each **Image type** only after the compute environment has begun scaling instances for that specific **Image type**. ------ #### [ CLI ] When you call [describe-compute-environments](https://docs.aws.amazon.com/cli/latest/reference/batch/describe-compute-environments.html), the response includes the `batchImageStatus` field that provides AMI visibility with the following values: + `LATEST` – Using the most recent AMI supported by AWS Batch. + `UPDATE_AVAILABLE` – An update is available. **Note** The `batchImageStatus` field appears only for AWS Batch-managed AMIs. It does not appear when custom AMIs are specified in `imageId` (deprecated), `imageIdOverride`, or in the default launch template. The status does not appear when the compute environment has a launch template override. For more information about how AWS Batch selects AMIs, see [AMI selection order](ami-selection-order.md). The field appears independently for each `Ec2Configuration` and only after the compute environment has begun scaling instances using that `imageType`. ``` { "computeEnvironments": [ { "computeEnvironmentName": "my-compute-environment", "computeResources": { "ec2Configuration": [ { "imageType": "ECS_AL2023" }, { "imageType": "ECS_AL2023_NVIDIA", "batchImageStatus": "UPDATE_AVAILABLE" } ] } } ] } ``` ------ ## Updating AMI versions When AWS Batch indicates that an AMI update is available, you can update your compute environment to use the newer AMIs by updating the compute environment with **Update AMI to latest version** set to true. You don't need to specify new AMI IDs – AWS Batch automatically selects the latest supported AMIs when you set **Update AMI to latest version**. **Important** Updating AMIs triggers an [infrastructure update](infrastructure-updates.md), not a scaling update. This means AWS Batch replaces existing instances with new instances that use the updated AMI. The update process takes longer than a scaling update and may interrupt running jobs depending on your update policy configuration. **Important** If your allocation strategy is `BEST_FIT` then you have to perform a [blue/green update](blue-green-updates.md). ------ #### [ Console ] To update AMIs using the AWS Batch console: 1. Open the AWS Batch console at [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/). 1. In the navigation pane, choose **Environments**. 1. Select the compute environment that shows an AMI status with an update. 1. Choose **Update now** (by the AMI status) or **Actions** > **Edit** to open the update modal. 1. In the AMI update modal, review the current AMI versions and their statuses. 1. Choose **Confirm** or **Save** to begin the infrastructure update. The compute environment status changes to `UPDATING` during the infrastructure update. You can monitor the progress in the console. ------ #### [ CLI ] To update AMIs using the AWS CLI, use the `update-compute-environment` command. ``` aws batch update-compute-environment \ --compute-environment my-compute-environment \ --compute-resources updateToLatestImageVersion=true ``` This command triggers an infrastructure update that replaces instances with new instances using the latest AWS Batch-supported AMIs. ------ ## Custom AMI considerations If your compute environment uses custom AMIs, i.e. AMIs specified in `ComputeResources.imageId` (deprecated), `Ec2Configuration.imageIdOverride`, the default launch template or the launch template overrides, AWS Batch cannot provide status information for these AMIs. + **Status visibility** – Custom AMIs show "**-**" for their **Batch image status** in the console and do not include the `batchImageStatus` field in API responses. + **Manual management** – You are responsible for maintaining and updating custom AMIs. Stay informed of security and software patches from your AMI provider and update your custom AMIs accordingly. + **EC2 management** – Use the Amazon EC2 console or APIs to manage custom AMI lifecycle, including creating new versions and deprecating old ones. For more information about managing custom AMIs, see [Compute resource AMIs](compute_resource_AMIs.md). ## Best practices for AMI updates This section applies to both custom and default AMIs. + **Regular monitoring** – Regularly check the AMI status of your compute environments to identify when updates are available. For default AMIs, the `batchImageStatus` will show when an update is available. For custom AMIs, you'll need to use other resources like AWS security bulletins. + **Maintenance windows** – Schedule AMI updates during maintenance windows when job interruption is acceptable, as infrastructure updates replace existing instances. + **Job retry strategy** – Configure job retry strategies to handle jobs that may be interrupted during infrastructure updates. For more information, see [Automated job retries](job_retries.md). + **Update policy configuration** – Configure appropriate update policies to control how running jobs are handled during infrastructure updates. For more information, see [Perform infrastructure updates](infrastructure-updates.md). + **Testing** – Test AMI updates in development environments before applying them to production compute environments. # Tutorial: Create a compute resource AMI You can create your own custom compute resource AMI to use for your managed and unmanaged compute environments. For instructions, see the [Compute resource AMI specification](batch-ami-spec.md). Then, after you created a custom AMI, you can create a compute environment that uses that AMI that you can associate a job queue with. Last, start submitting jobs to that queue. **To create a custom compute resource AMI** 1. Choose a base AMI to start from. The base AMI must use HVM virtualization. The base AMI can't be a Windows AMI. **Note** The AMI that you choose for a compute environment must match the architecture of the instance types that you intend to use for that compute environment. For example, if your compute environment uses A1 instance types, the compute resource AMI that you choose must support ARM instances. Amazon ECS vends both x86 and ARM versions of the Amazon ECS optimized Amazon Linux 2 AMI. For more information, see [Amazon ECS optimized Amazon Linux 2 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) in the *Amazon Elastic Container Service Developer Guide*. The Amazon ECS optimized Amazon Linux 2 AMI is the default AMI for compute resources in managed compute environments. The Amazon ECS optimized Amazon Linux 2 AMI is preconfigured and tested on AWS Batch by AWS engineers. It's a minimal AMI that you can get started with and to get your compute resources that are running on AWS quickly. For more information, see [Amazon ECS Optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) in the *Amazon Elastic Container Service Developer Guide*. Alternatively, you can choose another Amazon Linux 2 variant and install the `ecs-init` package with the following commands. For more information, see [Installing the Amazon ECS container agent on an Amazon Linux 2 EC2 instance ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html#ecs-agent-install-al2) in the *Amazon Elastic Container Service Developer Guide*: ``` $ sudo amazon-linux-extras disable docker $ sudo amazon-linux-extras install ecs-init ``` For example, if you want to run GPU workloads on your AWS Batch compute resources, you can start with the [Amazon Linux Deep Learning AMI](https://aws.amazon.com/marketplace/pp/B01M0AXXQB). Then, configure the AMI to run AWS Batch jobs. For more information, see [Use a GPU workload AMI](batch-gpu-ami.md). **Important** You can choose a base AMI that doesn't support the `ecs-init` package. However, if you do, you must configure a way to start the Amazon ECS agent at boot and keep it running. You can also view several example user data configuration scripts that use `systemd` to start and monitor the Amazon ECS container agent. For more information, see [Example container instance user data configuration scripts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) in the *Amazon Elastic Container Service Developer Guide*. 1. Launch an instance from your selected base AMI with the appropriate storage options for your AMI. You can configure the size and number of attached Amazon EBS volumes, or instance storage volumes if the instance type you selected supports them. For more information, see [Launching an Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html) and [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) in the *Amazon EC2 User Guide*. 1. Connect to your instance with SSH and perform any necessary configuration tasks. This might include any or all of the following steps: + Installing the Amazon ECS container agent. For more information, see [Installing the Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) in the *Amazon Elastic Container Service Developer Guide*. + Configuring a script to format instance store volumes. + Adding instance store volume or Amazon EFS file systems to the `/etc/fstab` file so that they're mounted at boot. + Configuring Docker options, such as enabling debugging or adjusting base image size. + Installing packages or copying files. For more information, see [Connecting to Your Linux Instance Using SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html) in the *Amazon EC2 User Guide*. 1. If you started the Amazon ECS container agent on your instance, you must stop it and remove any persistent data checkpoint files before creating your AMI. Otherwise, if you don't do this, the agent doesn't start on instances that are launched from your AMI. 1. Stop the Amazon ECS container agent. + Amazon ECS-optimized Amazon Linux 2 AMI: ``` sudo systemctl stop ecs ``` + Amazon ECS-optimized Amazon Linux AMI: ``` sudo stop ecs ``` 1. Remove the persistent data checkpoint files. By default, these files are located in the `/var/lib/ecs/data/` directory. Use the following command to remove these files, if there are any. ``` sudo rm -rf /var/lib/ecs/data/* ``` 1. Create a new AMI from your running instance. For more information, see [Creating an Amazon EBS Backed Linux AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) in the *Amazon EC2 User Guide* guide. **To use your new AMI with AWS Batch** 1. After the new AMI is created, create a compute environment with the new AMI. To do this,choose the image type and enter the custom AMI ID in the **Image ID override** box when you create the AWS Batch compute environment. For more information, see [Tutorial: Create a managed compute environment using Amazon EC2 resources](create-compute-environment-managed-ec2.md). **Note** The AMI that you choose for a compute environment must match the architecture of the instance types that you intend to use for that compute environment. For example, if your compute environment uses A1 instance types, the compute resource AMI that you choose must support ARM instances. Amazon ECS vends both x86 and ARM versions of the Amazon ECS optimized Amazon Linux 2 AMI. For more information, see [Amazon ECS optimized Amazon Linux 2 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) in the *Amazon Elastic Container Service Developer Guide*. 1. Create a job queue and associate your new compute environment. For more information, see [Create a job queue](create-job-queue.md). **Note** All compute environments that are associated with a job queue must share the same architecture. AWS Batch doesn't support mixing compute environment architecture types in a single job queue. 1. (Optional) Submit a sample job to your new job queue. For more information, see [Job definition examples](example-job-definitions.md), [Create a single-node job definition](create-job-definition.md), and [Tutorial: submit a job](submit_job.md). # Use a GPU workload AMI To run GPU workloads on your AWS Batch compute resources, you must use an AMI with GPU support. For more information, see [Working with GPUs on Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) and [Amazon ECS-optimized AMIs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) in *Amazon Elastic Container Service Developer Guide*. In managed compute environments, if the compute environment specifies any `p3`, `p4`, `p5`, `p6`, `g3`, `g3s`, `g4`, `g5`, or `g6` instance types or instance families, then AWS Batch uses an Amazon ECS GPU optimized AMI. In unmanaged compute environments, an Amazon ECS GPU-optimized AMI is recommended. You can use the AWS Command Line Interface or AWS Systems Manager Parameter Store [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html), [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html), and [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html) operations to retrieve the metadata for the recommended Amazon ECS GPU-optimized AMIs. **Note** The `p5` instance family is only supported on versions equal or later than `20230912` of the Amazon ECS GPU-optimized AMI and they are incompatible with `p2` and `g2` instance types. If you need to use `p5` instances, ensure that your compute environment doesn't contain `p2` or `g2` instances and uses the latest default Batch AMI. Creating a new compute environment will use the latest AMI but If you are updating your compute environment to include `p5`, you can ensure you are using the latest AMI by setting [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion) to `true` in `ComputeResource` properties. For more information on AMI compatibility with GPU instances, see [Working with GPUs on Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) in *Amazon Elastic Container Service Developer Guide*. The following examples show how to use the [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) command. ------ #### [ AWS CLI ] ``` $ aws ssm get-parameter --name /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \ --region us-east-2 --output json ``` The output includes the AMI information in the `Value` parameter. ``` { "Parameter": { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended", "LastModifiedDate": 1555434128.664, "Value": "{\"schema_version\":1,\"image_name\":\"amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs\",\"image_id\":\"ami-083c800fe4211192f\",\"os\":\"Amazon Linux 2\",\"ecs_runtime_version\":\"Docker version 18.06.1-ce\",\"ecs_agent_version\":\"1.27.0\"}", "Version": 9, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended" } } ``` ------ #### [ Python ] ``` from __future__ import print_function import json import boto3 ssm = boto3.client('ssm', 'us-east-2') response = ssm.get_parameter(Name='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended') jsonVal = json.loads(response['Parameter']['Value']) print("image_id = " + jsonVal['image_id']) print("image_name = " + jsonVal['image_name']) ``` The output only includes the AMI ID and AMI name: ``` image_id = ami-083c800fe4211192f image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs ``` ------ The following examples demonstrate the use of [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html). ------ #### [ AWS CLI ] ``` $ aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name \ /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id \ --region us-east-2 --output json ``` The output includes the full metadata for each of the parameters: ``` { "InvalidParameters": [], "Parameters": [ { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id", "LastModifiedDate": 1555434128.749, "Value": "ami-083c800fe4211192f", "Version": 9, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name", "LastModifiedDate": 1555434128.712, "Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs", "Version": 9, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name" } ] } ``` ------ #### [ Python ] ``` from __future__ import print_function import boto3 ssm = boto3.client('ssm', 'us-east-2') response = ssm.get_parameters( Names=['/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name', '/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id']) for parameter in response['Parameters']: print(parameter['Name'] + " = " + parameter['Value']) ``` The output includes the AMI ID and AMI name, using the full path for the names. ``` /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs ``` ------ The following examples show how to use the [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html) command. ------ #### [ AWS CLI ] ``` $ aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \ --region us-east-2 --output json ``` The output includes the full metadata for all of the parameters under the specified path. ``` { "Parameters": [ { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version", "LastModifiedDate": 1555434128.801, "Value": "1.27.0", "Version": 8, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version", "LastModifiedDate": 1548368308.213, "Value": "Docker version 18.06.1-ce", "Version": 1, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id", "LastModifiedDate": 1555434128.749, "Value": "ami-083c800fe4211192f", "Version": 9, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name", "LastModifiedDate": 1555434128.712, "Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs", "Version": 9, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os", "LastModifiedDate": 1548368308.143, "Value": "Amazon Linux 2", "Version": 1, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os" }, { "Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version", "LastModifiedDate": 1548368307.914, "Value": "1", "Version": 1, "Type": "String", "ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version" } ] } ``` ------ #### [ Python ] ``` from __future__ import print_function import boto3 ssm = boto3.client('ssm', 'us-east-2') response = ssm.get_parameters_by_path(Path='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended') for parameter in response['Parameters']: print(parameter['Name'] + " = " + parameter['Value']) ``` The output includes the values of all the parameter names at the specified path, using the full path for the names. ``` /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version = 1.27.0 /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version = Docker version 18.06.1-ce /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os = Amazon Linux 2 /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version = 1 ``` ------ For more information, see [Retrieving Amazon ECS-Optimized AMI Metadata](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html) in the *Amazon Elastic Container Service Developer Guide*. # Amazon Linux deprecation The Amazon Linux AMI (also called Amazon Linux 1) reached its end of life on December 31, 2023. AWS Batch has ended support for Amazon Linux AMI as it will not receive any security updates or bug fixes starting January 1, 2024. For more information about the Amazon Linux end-of-life, see [AL FAQ](https://aws.amazon.com/amazon-linux-ami/faqs/). We recommend that you update existing Amazon Linux based compute environments to Amazon Linux 2023 to prevent unforeseen workload interruptions, and continue to receive security and other updates. Your compute environments using the Amazon Linux AMI may continue functioning beyond the December 31, 2023 end-of-life date. However, these compute environments will no longer receive any new software updates, security patches, or bug fixes from AWS. It is your responsibility to maintain these compute environments on the Amazon Linux AMI after end-of-life. We recommend migrating AWS Batch compute environments to Amazon Linux 2023 or Amazon Linux 2 to maintain optimal performance and security. For help migrating AWS Batch from the Amazon Linux AMI to Amazon Linux 2023 or Amazon Linux 2, see [Updating compute environments - AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/updating-compute-environments.html). # Amazon EKS Amazon Linux 2 AMI deprecation AWS ended support for Amazon EKS optimized Amazon Linux 2 AMIs on November 26, 2025. On October 27, 2025, AWS Batch changed the default AMI for new Amazon EKS compute environments to Amazon Linux 2023. Amazon EKS optimized Amazon Linux 2 AMIs no longer receive software updates, security patches, or bug fixes from AWS. **Important** If you have AWS Batch Amazon EKS compute environments still using Amazon Linux 2, we strongly recommend migrating to Amazon Linux 2023. It is your responsibility to maintain Amazon EKS optimized Amazon Linux 2 compute environments after end-of-life. For more information about the Amazon EKS AL2 end-of-life, see [Amazon EKS AMI deprecation FAQs](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) in the *Amazon EKS User Guide*. For help migrating AWS Batch Amazon EKS compute environments from Amazon Linux 2 to Amazon Linux 2023, see [How to upgrade from EKS AL2 to EKS AL2023](eks-migration-2023.md). # Amazon ECS Amazon Linux 2 AMI deprecation AWS is ending support for Amazon ECS Amazon Linux 2-optimized and accelerated AMIs on June 30, 2026. On January 12, 2026, AWS Batch changed the default AMI for new Amazon ECS compute environments from Amazon Linux 2 to Amazon Linux 2023. Effective June 30, 2026, AWS Batch will block creation of new Amazon ECS compute environments using Batch-provided Amazon Linux 2 AMIs. After this date, you can only create new Amazon ECS compute environments using Amazon Linux 2023 or customer-provided AMIs. **Important** We strongly recommend migrating your existing AWS Batch Amazon ECS compute environments to Amazon Linux 2023 prior to June 30, 2026. Existing compute environments will continue to operate after this date, but will no longer receive software updates, security patches, or bug fixes from AWS. It is your responsibility to maintain Amazon Linux 2 compute environments after end-of-life. You can track the migration status of your affected Amazon ECS compute environments using AWS Health planned lifecycle events. For more information, see [AWS Health Planned lifecycle events](batch-planned-lifecycle-events.md). For more information about the Amazon Linux 2 end-of-life, see [Amazon Linux 2 FAQs](https://aws.amazon.com/amazon-linux-2/faqs/). For information about differences between Amazon Linux 2 and Amazon Linux 2023, see [Compare Amazon Linux 2023 and Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) in the *Amazon Linux 2023 User Guide*. For information about changes in Amazon Linux 2023 for Amazon ECS-optimized AMI, see [Migrating from an Amazon Linux 2 to an Amazon Linux 2023 Amazon ECS-optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html) in the *Amazon ECS User Guide*. For help migrating AWS Batch Amazon ECS compute environments from Amazon Linux 2 to Amazon Linux 2023, see [How to migrate from ECS AL2 to ECS AL2023](ecs-migration-2023.md).