AWS Batch queues, compute environments and AMIs
AWS Batch queues created using the CloudFormation templates provided by QIAGEN are each mapped to an individual compute environment. Each compute environment is configured to use the latest Amazon ECS-optimized AMI available at the time it is established. Thus, in a CLC Genomics Cloud setup, all jobs sent to a given AWS Batch queue will use the same AMI version.
AWS Batch does not upgrade the AMIs in existing compute environments. Thus, compute environments established at different times may contain different AMI versions. An example where this could happen in a CLC Genomics Cloud context would be where a new AWS Batch queue is created some time after the initial infrastructure was set up, and there had been an AMI update released in the meantime.
We generally do not expect performance issues using supported, older AMI versions. From a security perspective, AWS Batch compute environments established using the CloudFormation templates provided by QIAGEN are placed in a security group that rejects incoming traffic that was not initiated from the EC2 host.
Which AMI is being used?
The image ID for the AMI used for a job is recorded near the top of the CloudWatch log (aka Execution Log). Information about that public image, such as the Amazon Linux AMI version and the deprecation time for that AMI can be found via the AWS Console:
Console | EC2 | Images | AMIs
See the changelog at AWS for details of each AMI release: https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md
Accessing a newer AMI
To update the AMI being used, a new compute environment is needed. An easy way to achieve this is to create a new AWS Batch queue, as described in Adding more AWS Batch queues for CLC jobs. Queues that are no longer needed can be deleted, as described in Deleting or redeploying CLC Genomics Cloud infrastructure on AWS.