If you run anything on AWS, there’s a good chance a box you forgot about is running Amazon Linux 2. ECS-optimized AMIs, that bastion host from 2021, a CI runner, the Lambda layer someone baked three jobs ago. AL2 quietly became the default Linux of a lot of AWS shops, and now it’s hitting the wall: Amazon Linux 2 reaches end of life on June 30, 2026. That’s 19 days from when I’m writing this.
After that date AWS stops shipping security patches and bug fixes for AL2 core packages. The instances keep booting — nothing dramatically explodes at midnight — but every new CVE that lands afterward goes unpatched on your fleet. For an OS sitting under your production workloads, that’s not a “we’ll get to it” problem.
Here’s the part that catches teams off guard: the move to Amazon Linux 2023 is not an in-place upgrade. There’s no do-release-upgrade equivalent that flips AL2 to AL2023 and hands you back a working box. AWS designed AL2023 to be rebuilt into, not upgraded into. So this is a re-bake project, not a dnf upgrade. Here’s what actually changes and how to do it without melting a weekend.
The deadline, and why there’s no soft landing
The date is firm. AWS already extended AL2’s life once — it was originally slated to end in 2025 — and pushed it to June 30, 2026. There’s no signal of another extension, and the release notes and FAQs all point at the same date. Until then AL2 still gets critical security updates and bug fixes for core packages. After it, nothing.
The thing people assume exists but doesn’t: AWS-provided extended support for AL2. RDS gives you paid extended support for old engine versions. AL2 has no equivalent. When June 30 passes, the AWS-maintained patch stream stops, full stop. If you genuinely can’t finish in time, your only patch source is a third party (more on that at the end), and that’s a stopgap, not a plan.
For comparison, AL2023’s own support window runs to June 2029. So migrating now buys you three years before the next OS migration conversation. Worth pricing that in when you scope the work — you’re not doing this again next year.
What actually changes from AL2 to AL2023
AL2023 isn’t AL2 with a newer coat of paint. It’s a meaningfully different distro, closer in spirit to current Fedora than to the old Amazon Linux lineage. The big-ticket changes:
Kernel jumps generations. AL2 shipped kernel 4.14, later 5.10. AL2023 launched on 6.1 and now offers newer LTS streams alongside it. For most application code this is invisible, but if you have out-of-tree kernel modules, custom eBPF, or hardware-adjacent tooling, that’s the first thing to test. AL2023 also changes the kernel update model — it ships deterministic, versioned releases rather than rolling you forward silently.
yum is now dnf. AL2023 uses dnf as the package manager. Your yum install commands still work because yum is aliased to dnf, but the resolver behaves differently and some flags changed. Scripts that parse yum output or depend on its exact dependency-resolution quirks are the ones that’ll surprise you.
Versioned, deterministic repos. AL2023 pins you to a specific package set per release and lets you lock to a version so two instances launched a month apart get identical packages. Nice for reproducibility, but it means “just install the latest” habits need rethinking.
SELinux ships enabled in permissive mode. This is the one I want to correct, because a lot of migration writeups (including the outline I started from) say AL2023 is “enforcing by default.” It isn’t. AL2023 ships SELinux permissive by default — it logs what would be denied without blocking it. You can flip it to enforcing with setenforce or via cloud-init userdata, and you probably should eventually, but out of the box it won’t break your app on day one. Still, check your audit logs before you switch it on.
cgroup v2 by default. Matters mostly for container runtimes and anything that reads cgroup paths directly. Modern Docker and containerd are fine; older tooling and some monitoring agents that hardcode cgroup v1 paths are not.
The amazon-linux-extras trap
This is where AL2 shops lose the most time. AL2 had amazon-linux-extras — a curated set of “topics” you enabled to get newer versions of nginx, PHP, PostgreSQL, Docker, and so on, without leaving the AWS-supported package set. It was genuinely convenient.
It’s gone in AL2023. There is no amazon-linux-extras command. The whole mechanism doesn’t exist.
The good news is that most of what lived in extras moved into the AL2023 core repos at current versions. So an amazon-linux-extras install nginx1 on AL2 usually becomes a plain dnf install nginx on AL2023, and you get a newer build than the extras topic gave you. PHP, PostgreSQL client libs, Docker, Redis — check the core repo first, because the version is probably right there.
Where it bites: software that was only available through an extras topic, or that you pinned to a specific extras version your app was tested against. Those need a real decision — accept the newer core version, pull it from elsewhere, or build it. Audit every amazon-linux-extras call in your provisioning scripts before you cut over. Grep your Ansible, your user-data, your Dockerfiles. That list is your migration checklist’s spine.
EPEL is not supported — and the SPAL escape hatch
AL2 let you wire up EPEL (Extra Packages for Enterprise Linux) and pull from a huge catalog of community RPMs. AL2023 does not support EPEL. If your fleet quietly depends on a handful of EPEL packages — and a lot of fleets do, often without anyone remembering — those installs will simply fail on AL2023.
A few ways out, roughly in order of how much I’d reach for them:
- SPAL. AWS now points migrators at SPAL, a repository of thousands of EPEL9-derived packages rebuilt for AL2023. It’s the closest thing to “turn EPEL back on,” and it exists specifically to smooth AL2-to-AL2023 moves without building from source. Check here first for your missing packages.
- Fedora COPR. Many maintainers publish AL2023/EL9-compatible builds in COPR. Hit or miss, but often has the niche tool you need.
- Build from source / vendored RPMs. The fallback when nothing else has it. Bake it into your AMI build so you’re not compiling on every launch.
The 32-bit (i686) package situation also tightened up. If anything in your stack still drags along 32-bit dependencies, flag it early — that’s a deeper rabbit hole than a missing EPEL package.
Migration paths that actually work
Because there’s no in-place upgrade, every path starts from the same premise: stand up a fresh AL2023 instance and move your workload onto it. AWS’s own guidance is rebuild, not upgrade, and they recommend testing your app on a clean AL2023 install before you touch production.
Plain EC2 / custom AMIs. Update your Packer or image-build pipeline to source from the AL2023 base AMI, re-run your provisioning against it, fix what breaks (the extras and EPEL audit above), and bake a new golden AMI. Then update the AMI ID in your Terraform launch templates / ASGs and roll it out the way you’d roll any AMI change. If you pin AMI IDs in Terraform — and you should — this is a data source swap plus a terraform apply, instance refresh, done. The work is in the bake, not the rollout.
ECS. AWS has a documented transition from the AL2 ECS-optimized AMI to the AL2023 one. Swap the AMI in your capacity provider / launch template, validate your task definitions still run (watch for anything assuming the old Docker version or cgroup v1), and roll the cluster. Tasks themselves usually don’t care what the host OS is — it’s the agent and runtime layer to validate.
EKS. This one may already be forcing your hand. For newer Kubernetes versions, AL2023 is the required node OS — the AL2 EKS-optimized AMIs aren’t an option past a certain K8s version. If you’re upgrading EKS anyway, the node OS migration comes along for the ride. Update your managed node groups / launch templates to the AL2023 EKS AMI and let the node group do a rolling replace.
Lambda. Custom runtimes and layers built against AL2’s userland should be rebuilt against AL2023’s. The newer glibc and OpenSSL are the usual culprits for “worked in test, broke in prod.”
The pre-cutover testing checklist
Don’t cut over on faith. The failures here are boringly predictable, which means they’re catchable:
- Dependency audit. Every
amazon-linux-extrasand EPEL reference in your provisioning. Resolve each to a core package, SPAL, COPR, or a built RPM. - OpenSSL 3. AL2023 ships OpenSSL 3.x. Apps built against 1.1.1 that link OpenSSL directly, or that trip over OpenSSL 3’s stricter defaults (legacy ciphers, smaller key sizes), will fail in ways that look like network bugs. Test TLS-heavy paths explicitly.
- Python. Python 2 is gone. The system Python is 3.9+. Anything still calling
pythonexpecting Python 2, or pinned to an old 3.x, needs fixing. - systemd unit diffs. Service files behave the same conceptually, but default paths, users, and a few directives shifted. Diff your units on a test box.
- glibc behavior. The jump in glibc version occasionally surfaces locale and DNS-resolution differences. Check anything that does hostname resolution or assumes a specific locale.
- SELinux audit logs. Even in permissive mode, read
/var/log/audit/audit.logto see what would be denied before you ever consider flipping to enforcing. - Monitoring agents. cgroup v2 and the newer kernel can trip older Datadog/New Relic/CloudWatch agent versions. Update them as part of the bake.
Run a real workload against the AL2023 image in staging for a few days, not a smoke test for five minutes. The OpenSSL and glibc surprises tend to hide in edge-case traffic.
If you genuinely can’t finish in time
Sometimes the audit turns up a load-bearing dependency that won’t move by June 30, or you’ve got a fleet of hundreds and not enough hands. Be honest about it rather than running unpatched and hoping.
The realistic stopgap is third-party extended support. Vendors like TuxCare offer extended security updates for AL2 past the AWS EOL date — they keep shipping patches for critical CVEs so your AL2 boxes don’t go fully dark while you finish the migration. It’s a paid bridge, and it’s a bridge, not a destination. Buy yourself a quarter or two, not a culture of staying on AL2 forever.
Running unpatched with no support at all is the option I’d argue hardest against. Backup and infrastructure hosts are exactly what ransomware crews probe for known-CVE footholds, and an unpatched EOL OS under production is the kind of thing that turns into an incident review with your name in it. If you go that route anyway, at minimum isolate those instances at the network layer, lock down access, and put them at the top of the migration queue.
And keep a rollback plan. Because the migration is AMI-swap-shaped — new launch template, instance refresh — rollback is mostly “point the ASG back at the old AMI.” Keep the AL2 golden AMI around until the AL2023 fleet has soaked under real traffic for a week. Cheap insurance.
If you only do one thing this week, grep your entire provisioning estate for amazon-linux-extras and EPEL repo references. That single list tells you whether this is a quiet afternoon or a three-sprint project — and you’d much rather find out on June 11 than June 29.