Amazon Linux 2 Is EOL: a Migration Checklist for Batch, ECS, and Lambda

The security scan flagged eleven CVEs on the ECS instances. There was nothing to patch with—Amazon Linux 2 went end-of-life on June 30, 2026, and the fixes simply stopped coming. The AMI had been “temporary” for two years.

EOL announcements feel like vendor noise until the week your instance launches start failing or your scanner goes red with no remediation path. This post is the migration checklist I’d hand to a teammate: what still runs AL2, what breaks on AL2023, and how to move ECS, Batch, and Lambda without a weekend incident. It is not an AL2023 feature tour.

Step 1: inventory what is actually AL2

You have more of it than the Terraform repo suggests:

• ECS: every service, task, and instance using an AL2-based ECS-optimized AMI (check the SSM parameter path or AMI name in launch templates).
• AWS Batch: compute environments created before January 2026—Batch switched its default ECS AMI to an AL2023-based one, and AL2-based defaults are deprecated with new launches blocked after the cutover.
• Lambda: runtimes built on AL2 (the older Node and Python lines) — each has a published deprecation timeline ending in blocked creates, then blocked updates.
• Stragglers: bastions, build runners, that one data-sync EC2 box, custom AMIs baked from AL2 sources, and anything launched from old launch templates.
• Containers are mostly immune (they carry their own userspace) — but host-level agents, kernel behavior, and anything building --platform images against the host still cares.

Write the list down with owners and dates. “Everything” is not an inventory.

The AL2023 breakage list

Test against these before touching production:

ECS checklist

• New launch templates point at the AL2023 ECS-optimized AMI via SSM path (…/amazon-linux-2023/…, not …/amazon-linux-2/…).
• Instance user-data audited: yum → dnf, no amazon-linux-extras stanzas.
• Custom AMI pipelines rebuilt on AL2023 base; the AL2 pipeline produces nothing now anyway.
• Canary: one service, one instance, one burn-in week—before fleet-wide ASI/AMI rollouts.
• Container insights/agents validated against cgroups v2.

AWS Batch checklist

• Audit compute environments for deprecated AL2 defaults (the Batch checklist covers where AMIs hide).
• Re-create/update environments on AL2023-based defaults—verify jobs reach RUNNING, not just that terraform apply succeeded.
• Job images that install packages at runtime rebuilt for dnf.
• Spot fleets and launch templates swept with the same audit.

Lambda checklist

• List functions per runtime; mark AL2-based ones with their published deprecation dates.
• Upgrade runtimes in order of deprecation date, not alphabetical convenience.
• Test the honest way: invoke with production-shaped payloads; native-dependency behavior can shift with the runtime OS.

Terraform angle

Pin AMIs and runtimes in shared modules so this never repeats: one variable, one SSM path, no hand-edited AMI IDs per environment. A repo grep for amazon-linux-2 and old SSM paths should come up empty before you call this done.

If you only do one thing: run the inventory this week—ECS AMIs, Batch environments, Lambda runtimes, stray EC2—and put an owner and date next to each line. The migration itself is boring; not knowing your exposure is what turns EOL into an incident.

Next week: Phase 2 of the lab-to-cloud story begins with the ALCOA+ field guide for platform engineers.

Related platform-notes: AWS Batch checklist, Terraform module layout, Hybrid go-live and recovery.