Amazon Linux 2 EOL: Patching Options and Migrating to AL2023

Amazon Linux 2 (AL2) has been the default EC2 workhorse since 2017, and AWS extended its end-of-support date twice — most recently to June 30, 2026. Because there is no in-place upgrade path from AL2 to Amazon Linux 2023 (AL2023), every remaining AL2 instance in your account has to be replaced, not upgraded in place.

Meanwhile, teams that have already started launching AL2023 instances often hit a second surprise: AL2023’s deterministic versioned repositories mean a cron job or playbook that runs a plain dnf upgrade never picks up new repository releases unless --releasever is advanced explicitly.

This guide covers what still works on AL2 today, how to audit your remaining AL2 fleet, the six breaking changes that trip up AL2-to-AL2023 migrations, and how to run dnf on AL2023 so security advisories actually land.

Your options for remaining Amazon Linux 2 hosts

Step 1: Inventory every AL2 instance and its enabled extras repos

Before planning migrations, find out what is actually installed on your remaining AL2 hosts. On AL2, core packages come from amzn2-core, while newer runtimes, databases, and kernels (kernel-5.10, docker, nginx1, postgresql14, python3.8, epel) come from amazon-linux-extras topics.

# Confirm OS release and running kernel (4.14 vs 5.10)
cat /etc/os-release
uname -r

# List enabled yum repositories and active amazon-linux-extras topics
sudo yum repolist
amazon-linux-extras list | grep enabled

# List pending ALAS2 security advisories right now
sudo yum clean expire-cache
sudo yum updateinfo summary
sudo yum updateinfo list security

A common blind spot on AL2 is a host where someone installed a package from an extras topic and later disabled the repository file under /etc/yum.repos.d/amzn2-extras.repo. That package stays frozen at its old version and never shows up in yum updateinfo list security.

Step 2: Keep remaining AL2 hosts patched while you migrate

Until an AL2 instance is terminated, keep its ALAS2 advisories current:

# Apply all published ALAS2 security updates
sudo yum update --security -y

# Or patch a single CVE ahead of the maintenance window
sudo yum updateinfo info --cve CVE-2026-12345
sudo yum update --cve CVE-2026-12345 -y

# Check whether the kernel, glibc, or systemd update requires a reboot
sudo needs-restarting -r ; echo "exit: $?"

# List services still running against deleted shared libraries
sudo needs-restarting -s

If needs-restarting -r exits with 1, the host is still running its previous kernel or glibc in memory. For EC2 instances that cannot reboot until a monthly window, AWS provides kernel live patching on AL2 x86_64 hosts running kernel 4.14 or 5.10:

sudo yum install -y yum-plugin-kernel-livepatch kpatch-runtime
sudo yum kernel-livepatch enable -y
sudo systemctl enable --now kpatch.service
sudo yum update --security -y
sudo kpatch list

Step 3: Six breaking changes when moving from AL2 to AL2023

Because you cannot run an in-place upgrade from AL2 to AL2023, migration means booting a new AL2023 AMI and running your provisioning scripts (Ansible, Terraform user_data, Packer, or Chef) against it. These six differences break AL2 playbooks most often:

1. No amazon-linux-extras. The amazon-linux-extras command does not exist on AL2023. Packages that lived in extras on AL2 (nginx, docker, postgresql15, redis6) are normal packages in the main amazonlinux repository, installed with sudo dnf install -y.
2. No EPEL support. EPEL7 and EPEL8/9 are not compatible with AL2023’s Fedora-derived userland (glibc 2.34). If your workload depends on EPEL-only packages, verify whether they exist natively in AL2023 (dnf search <pkg>) before migrating, or consider Rocky Linux or Ubuntu if you rely heavily on EPEL.
3. Deterministic versioned repositories (releasever). On AL2, yum update always pulls the latest packages published up to that minute. On AL2023, dnf is locked to the AMI’s release version (--releasever=2023.x.YYYYMMDD) until you tell it to advance.
4. cron and rsyslog are not installed by default. AL2023 uses systemd timers instead of cronie and systemd-journald instead of /var/log/messages via rsyslog. If your scripts drop files into /etc/cron.d/ or ship /var/log/messages, either migrate them to systemd timers and journald or explicitly run sudo dnf install -y cronie rsyslog && sudo systemctl enable --now crond rsyslog.
5. Stricter SSH and TLS crypto policy (DEFAULT). AL2023 uses OpenSSL 3.0 and system-wide crypto-policies that reject legacy ssh-rsa (SHA-1) keys and old TLS 1.0/1.1 ciphers. Old deploy keys or jump hosts still presenting ssh-rsa without rsa-sha2-256/512 will fail to connect until replaced with ed25519 or modern RSA keys.
6. IMDSv2 required by default. Official AL2023 AMIs default to Instance Metadata Service v2 (token-required, hop limit 1). Scripts that run a bare curl http://169.254.169.254/latest/meta-data/ without fetching an X-aws-ec2-metadata-token first will get 401 Unauthorized.

Step 4: Patching Amazon Linux 2023 without falling into the releasever trap

Once a workload runs on AL2023, your patching commands must account for /etc/dnf/vars/releasever. Every time AWS publishes a new AL2023 repository release (roughly every two to three weeks, or immediately for urgent ALAS2023 advisories), dnf prints a notice via its releasever-adapter plugin, but it does not switch your host to that new release automatically.

Here is the complete AL2023 patching sequence:

# 1. See which repository version this instance is locked to
cat /etc/dnf/vars/releasever

# 2. Check whether newer repository releases (and ALAS2023 advisories) exist
sudo dnf check-release-update

# 3. List pending security advisories against the latest repository snapshot
sudo dnf updateinfo list --security --releasever=latest

# 4. Apply security updates from the latest snapshot
sudo dnf upgrade --security --releasever=latest -y

# 5. Or advance the pinned releasever permanently for all future dnf runs
echo "latest" | sudo tee /etc/dnf/vars/releasever
# (Or pin a specific tested version across staging and prod, e.g. 2023.6.20241010)

# 6. Check whether a reboot is required
sudo dnf needs-restarting -r ; echo "exit: $?"

The same dnf flags used in RHEL patching step by step apply on AL2023: --cve CVE-YYYY-NNNNN patches a single CVE, --advisory ALAS2023-YYYY-NNN targets one advisory, and dnf history undo <id> rolls back a transaction within the pinned repository version.

Managing AL2 and AL2023 alongside the rest of your Linux fleet

During an AL2 migration, most teams run a mixed fleet for months: old AL2 nodes waiting for cutover, new AL2023 instances, and often Ubuntu, Debian, or RHEL hosts in the same environment.

SysWard’s Amazon Linux patch management integration inventories every installed package across AL2 and AL2023, matches versions against live CVE feeds, flags hosts waiting for a reboot (needs-restarting -r), and logs every patch rollout for SOC 2 and PCI DSS compliance.

To see every remaining AL2 instance and its unpatched CVEs in one view while you migrate, start free with 5 agents, no credit card required.