Which strategy should I use for AWS Batch New AL2 Environment Creation Blocked?
Batch operators should choose an AL2023 path for future-safe ECS-backed compute environments because AWS Batch changes what can be created after June 30, 2026, even though existing AL2-backed environments continue running afterward.
Blockers
- package/ecs_al2 — EOL 2026-06-30
- AWS Batch switched the default AMI for new Amazon ECS compute environments from AL2 to AL2023.
- replaces: runtime/amazon-linux-2023 → runtime/amazon-linux-2
- package/ecs_al2023 incompatible with capability/a1-instance-type
- package/ecs_al2023_nvidia incompatible with capability/p3-instance-type
- package/ecs_al2023_nvidia incompatible with capability/g3-instance-type
Who this is for
- cost-sensitive
- enterprise
Candidates
Switch managed Batch compute environments to Batch-provided ECS_AL2023
Use the AWS-supported default path for new ECS-backed Batch compute environments. AWS Batch switched the default AMI for new Amazon ECS compute environments from AL2 to AL2023 on January 12, 2026, and blocks new Batch-provided AL2 environment creation after June 30, 2026.
When to choose
Use this when you rely on Batch-managed ECS AMIs and want the least custom infrastructure to own. It is the default path if your compute environments are not tied to a custom AMI strategy and you want to stay on AWS-supported images.
Tradeoffs
Lowest operational overhead and aligns with the AWS-supported default. The tradeoff is that you must validate AL2023 behavior changes in bootstrap scripts, OS tooling, and instance compatibility before rollout.
Cautions
Verified migration caveats include `dnf` replacing `yum`, IMDSv2 being enabled by default, and AL2023 repository/version behavior differing from AL2. In Batch image types, `ECS_AL2023` does not support `A1` instances, and `ECS_AL2023_NVIDIA` does not support `p3` or `g3` instance types.
Use a customer-provided AL2023-compatible AMI via launch template or ImageIdOverride
Use this when you need tighter control over image contents or hardening. As of 2026-04-10, AWS Batch documents that after June 30, 2026, new Amazon ECS compute environments can still be created with Amazon Linux 2023 or customer-provided AMIs, but AMI updates and compatibility remain your responsibility when you use a launch template or `ImageIdOverride`.
When to choose
Use this when you already standardize on custom AMIs, must embed security or observability tooling at the image layer, or need launch-template-driven control. It is the better fit when the managed `ECS_AL2023` image is too restrictive for your operational baseline.
Tradeoffs
Gives maximum control over image contents and rollout timing. The cost is more image lifecycle ownership, more testing burden, and more room for drift or stale AMIs.
Cautions
AWS Batch warns that `ImageType` must match the AMI specified in `ImageIdOverride`, or the compute environment may not function properly. If the AMI comes from a launch template, updating the compute environment does not automatically swap the AMI unless the relevant image update settings and launch template version behavior are handled explicitly; check official docs before rollout.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for AWS Batch New AL2 Environment Creation Blocked?"