Amazon Linux 2 End of Life (June 30, 2026): Is There Extended Support, What Still Gets Patched, the EKS, ECS, Beanstalk and Lambda Deadlines, and How to Upgrade to Amazon Linux 2023

Amazon Linux 2 reached its end of life on June 30, 2026. The official term is end of support: AL2 no longer receives standard security updates, there is no paid extended support plan, and the advice is to move to Amazon Linux 2023, which is supported until June 30, 2029. Your AL2 servers did not stop on July 1, though. They still boot, yum still reaches the repositories, and here is the surprise: between July 1 and October 23, 2026, AWS still published 320 security advisories for Amazon Linux 2, 7 of them Critical. Some fixes keep arriving. What ended is the promise that the next one will.

Jake's shop keeps its stock database on a small EC2 server that Ethan set up years ago and nobody has touched since. When the PHP security scare made Ethan log in to everything, that server greeted him with Amazon Linux release 2 (Karoo). "Is that bad?" Jake asked. "It's not on fire," Ethan said. "But it's living on borrowed time, and the landlord stopped promising to fix the roof."

This guide is for anyone who still has Amazon Linux 2 somewhere: an old EC2 server, an EKS node group, an ECS cluster, an Elastic Beanstalk environment or a Lambda function. It explains what end of life really changed, what still gets patched and why you should not count on it, how to find every AL2 machine you own, and how to move to Amazon Linux 2023 without the surprises that catch most people in the first hour.

What Amazon Linux 2 is, and why it says "Karoo"

Amazon Linux 2 (AL2) is the Linux operating system AWS built for EC2 and released in 2017, and for years it was the default choice in the EC2 launch wizard. It is based on an older generation of the Red Hat and CentOS family, uses the yum package manager and the amazon-linux-extras tool for newer software, and ships Python 2.7 as its system Python. It was AWS's long-term support (LTS) release, which is why it lasted nine years, and if you run it, you will recognize its codename, Karoo, named after the semi-desert in South Africa. Every AL2 server identifies itself like this:

$ cat /etc/system-release
Amazon Linux release 2 (Karoo)

Its successor, Amazon Linux 2023 (AL2023), came out in March 2023. It is a different design rather than a newer version of the same thing: it uses dnf, includes components from Fedora 34, 35 and 36 (some closer to CentOS Stream 9) while following its own release lifecycle, has no amazon-linux-extras, no Python 2 and a new release model. That is why moving from one to the other is a migration, not an upgrade. If you came across the older Amazon Linux AMI (the original Amazon Linux, often seen as version 2018.03), that is a third, even older system: anything still running it is further past its end than AL2.

Jake: "So Karoo is the old house."

Ethan: "And 2023 is the new one. Same street, different plumbing."

Amazon Linux 2 end of life date, and what it actually changed

So, to answer the question as people type it: is Amazon Linux 2 end of life? Yes, since June 30, 2026. "End of life" and "end of support" mean the same thing here; AWS's pages use "end of support". For you, in practice, it changed four things and left four alone:

The last row of the left column is often what forces your decision. Your auditors and security scanners flag an end-of-life operating system by name, whether or not a particular fix happened to arrive, and checks for supported software will keep turning red on every AL2 machine you own.

The surprise: 320 AL2 security advisories after end of support

If you expect "end of support" to mean "silence", the Amazon Linux security center tells a different story. Its list of Amazon Linux 2 advisories shows 320 advisories released between July 1 and October 23, 2026, almost four months after the end date:

The packages patched most often were the kernel (32 advisories), containerd (13), Docker (10), unbound (9), and PHP and the SSM Agent (4 each). Critical ones included the PHP 8.2 Extras package in August, the SSM Agent on October 1, unbound in September and FreeIPA and 389 Directory Server in early September. Most recently, PHP 8.2 from Extras got its fix for the PHP2Shell flaws on October 22, while AL2's built-in PHP 5.4 is marked "No Fix Planned" for the same flaws.

So you are looking at two facts that seem to clash. Officially, AL2 no longer receives standard security updates. In practice, fixes are still being published, and nobody has said which packages will keep getting them or for how long. One documented reason for some of this work: Lambda's AL2-based runtimes (Java 8, 11 and 17 on AL2, Python 3.10 and 3.11, and provided.al2) keep receiving "patches for critical and selected important Amazon Linux 2 security issues" until their own deprecation dates in 2026 and 2027. Fixes built for those runtimes can land in the shared AL2 repositories, but nothing promises your EC2 server the next one.

That is the honest answer to "is AL2 still getting patched?": some of it, sometimes, with no guarantee. The PHP2Shell case shows how that plays out. A server on Extras PHP 8.2 got a fix within a day; a server on the built-in PHP got none, on the same operating system, in the same week. You cannot plan security on a pattern like that, which is why the advice does not change: keep patching AL2 with sudo yum update while you have it, and move.

Is there Amazon Linux 2 extended support?

Not from AWS, for EC2. Several AWS services sell extended support for old versions, such as RDS for old database engines and EKS for old Kubernetes versions, but Amazon Linux 2 has no such option. The official recommendation is to migrate to Amazon Linux 2023 now rather than waiting for a future version. The partial exceptions are inside AWS services that still use AL2 under the hood:

• Lambda AL2 runtimes get critical and selected important AL2 security fixes until each runtime's deprecation date (next section). That protects the runtime AWS manages, not your EC2 servers.
• Existing Elastic Beanstalk environments on retired AL2 platform branches keep running, but get no more platform updates.
• EKS node groups on AL2 AMIs keep working on Kubernetes 1.32 and earlier, but EKS publishes no updates to those AMIs.

Outside AWS, some Linux support companies sell paid extended patching for end-of-life distributions. If a vendor offers it for AL2, treat it as a bridge for a planned migration, check exactly which packages it covers, and confirm it satisfies your auditors before you rely on it.

Jake: "So nobody is selling us a longer lease."

Ethan: "Not one worth paying for. The move costs us a Saturday."

AL2 deadlines for EKS, ECS, Elastic Beanstalk and Lambda

Amazon Linux 2 often hides inside managed services, so "we don't use AL2" can be true for your own servers and false for your clusters and functions. Here is where it lives and the deadline for each:

Two of these need care. On EKS, AL2023 nodes use cgroup v2, require IMDSv2 by default and run SELinux in permissive mode, so test DaemonSets and anything that reads instance metadata before you swap a node group. On Lambda, moving from provided.al2 to provided.al2023 usually means rebuilding your binary on AL2023, because of the newer glibc. For Lambda deadlines in general, "the runtime is no longer supported" explains what the block dates do.

How to find every Amazon Linux 2 server you own

On a single server, one command answers it:

cat /etc/system-release      # AL2: Amazon Linux release 2 (Karoo)
cat /etc/os-release | head -3  # AL2: NAME="Amazon Linux" VERSION="2"

Amazon Linux 2023 prints a dated release instead, such as Amazon Linux release 2023.12.20261021 (Amazon Linux). Across an account, start from the images your instances were launched from. AL2 AMIs are named amzn2-ami-... (for example amzn2-ami-kernel-5.10-hvm-...), and AL2023 AMIs al2023-ami-.... This lists the running instances in one Region whose AMI is AL2:

IDS=$(aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].ImageId' --output text | tr '\t' '\n' | sort -u)
aws ec2 describe-images --image-ids $IDS \
  --query "Images[?starts_with(Name, 'amzn2-ami')].[ImageId,Name]" --output table

Repeat it in every Region you use. It misses instances launched from your own custom AMIs built on AL2, and AMIs that have since been deregistered, so for a complete answer ask the servers themselves. If they run the SSM Agent (most AWS-provided AMIs do), Systems Manager can run the first command on all of them at once: in the Systems Manager console, choose Run Command, the AWS-RunShellScript document, target all instances, and enter cat /etc/system-release. The output page then shows, server by server, which ones answer "Karoo". For what Systems Manager is and costs, see what Systems Manager is (Run Command is free).

For clusters, check the node group's AMI type in the EKS console (AL2_x86_64 means AL2), the AMI of your ECS container instances, the platform name of each Elastic Beanstalk environment, and the runtime column in the Lambda console's function list.

Amazon Linux 2 vs Amazon Linux 2023: what changes

Most of your AL2 applications will run on AL2023 unchanged. The trouble comes from the tools around them. This table compares a current AL2 server with a current AL2023 one, side by side:

Two rows cause most of the support tickets. The update row: on AL2023, sudo dnf update only looks inside the release your server launched from, so an old server can say "Nothing to do" while fixes exist; Amazon Linux 2023 updates explains the --releasever option that fixes it. And the Python row: scripts that start with #!/usr/bin/python or call python stop working, and installing newer Pythons the wrong way can break dnf itself; Python on Amazon Linux 2023 covers the safe way.

The glibc row is the good news. AL2's old glibc 2.26 is why newer Node.js and Python builds fail there with GLIBC_2.28 not found; that error simply disappears on AL2023.

How to upgrade Amazon Linux 2 to 2023: a migration, step by step

There is no in-place upgrade: AWS documents no command that turns an AL2 server into AL2023, and every AWS migration guide, the EKS and ECS ones included, replaces the instances. Your plan is to build a new AL2023 server next to the old one, move your application, and switch over. Here is the order that keeps you safe:

1. Snapshot the old server. In the EC2 console, select the instance and create an image (AMI) or snapshot its volumes. That is your way back.
2. Write down what it runs. systemctl list-units --type=service --state=running, crontab -l for every user, amazon-linux-extras list | grep enabled, yum list installed, open ports (sudo ss -tlnp), and the folders your application and its data live in. This list is the migration.
3. Launch an AL2023 instance in the same subnet with the same security groups and instance role. Choose the latest AL2023 AMI in the launch wizard, or look it up with the public parameter /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 (use arm64 at the end for Graviton).
4. Install the same software the AL2023 way. Replace each amazon-linux-extras install X with sudo dnf install and the AL2023 package name: docker, nginx, php8.4, python3.13, java-21-amazon-corretto and so on. Anything that came from EPEL needs a different source: a dnf package, the vendor's own repository, a container, or a build from source.
5. Recreate scheduled jobs. Either sudo dnf install cronie and sudo systemctl enable --now crond, then copy the crontabs, or turn them into systemd timers.
6. Copy the application and its data with rsync or from S3, then fix paths that changed (log files that used to land in /var/log/messages are now in journalctl).
7. Test on the new server while the old one still serves traffic: start the services, check logs with journalctl -u yourservice, and run a real request through it.
8. Switch over: move the Elastic IP, swap the target in the load balancer's target group, or change the DNS record. Keep the old instance stopped (not terminated) for a week or two.
9. Retire the old server once nothing has needed it, keeping the AMI from step 1 for as long as your retention rules require.

Step 4 is where most of the time goes, so here are the amazon-linux-extras topics a current AL2 server offers and what to install on Amazon Linux 2023 instead, with the versions in the October 21, 2026 release:

One trap in that last row: a plain sudo dnf install nodejs on AL2023 installs Node.js 18, which is past its own end of life, so name the version (nodejs22 or nodejs24) instead.

For servers created by an Auto Scaling group, the same idea is simpler: update the launch template to the AL2023 AMI with an AL2023 user-data script, then start an instance refresh. For EKS, create a new AL2023 node group, move workloads with kubectl drain on the old nodes, and delete the old group. For Elastic Beanstalk, create a new environment on the AL2023 platform branch, deploy, test, and swap the environment URLs.

Ethan did Jake's stock server on a Saturday morning: a snapshot, a fresh AL2023 instance, MariaDB and the small PHP app reinstalled with dnf, the database copied over, the Elastic IP moved. The only thing that broke was the nightly backup, a cron job on a server that no longer had cron.

Errors you will meet in the first hour on AL2023

These are the messages your fresh AL2023 server prints when it meets your AL2 habits, each with its fix:

bash: amazon-linux-extras: command not found
The extras tool does not exist on AL2023. Install the software directly: sudo dnf install nginx, sudo dnf install php8.4, sudo dnf install docker. Search with dnf search or dnf list --available 'python3*'.

bash: crontab: command not found
cron is not installed by default. sudo dnf install cronie, then sudo systemctl enable --now crond. Your old crontab lines work unchanged.

bash: python: command not found
AL2023 has only python3 (3.9). Change the script to call python3, or install a newer one such as python3.13. Python 2 code has to be converted to Python 3; AL2023 has no Python 2.

Error: Unable to find a match: epel-release
AL2023 does not support EPEL. Look for the package in the AL2023 repositories first, then the vendor's own repository, or run the tool in a container.

package curl-minimal-... conflicts with curl provided by curl-..., ending with (try to add '--allowerasing' to command line to replace conflicting packages ...)
AL2023 ships curl-minimal. If you need the full curl, for example for protocols the minimal one leaves out, run sudo dnf install --allowerasing curl, which swaps one for the other.

/var/log/messages: No such file or directory
AL2023 logs to the systemd journal. Use journalctl, journalctl -f to follow, or journalctl -u nginx for one service. Install rsyslog only if another tool insists on the file.

An application that read instance metadata now gets HTTP 401
AL2023 AMIs require IMDSv2, which needs a session token. Update the AWS SDK or CLI (current versions handle it), or change scripts that call curl http://169.254.169.254/... to fetch a token first.

sudo dnf update says "Nothing to do" weeks later
That is the release lock, not a missing fix. sudo dnf upgrade --releasever=latest moves the server to the newest release.

Amazon Linux 2 and 2023 release notes: what changed, and how to check

Both versions publish release notes, but they read very differently, and the difference is a good summary of where each one stands.

Amazon Linux 2 release notes are a single table of dated releases, each one "includes updated packages for this release". It is still growing after end of support: there were 19 AL2 releases between July 7 and October 21, 2026, the latest being 2.0.20261021.0 on October 21, 2026. That fits the advisories section above: packages still move, but there is no promise about which fixes arrive, so a new release is not the same as support. On an AL2 server, the useful command is not the release notes but the advisory list:

sudo yum updateinfo list security    # what is waiting for this server
sudo yum update --security           # apply only security updates

Amazon Linux 2023 release notes are organized by minor version, from 2023.0 to the current 2023.12, with a page for every dated release inside each. Because AL2023 locks each server to the release it was launched with, the release notes tell you what you would get by moving, and the server can tell you itself:

$ sudo dnf check-release-update
WARNING:
  A newer release of "Amazon Linux" is available.

  Available Versions:

  Version 2023.12.20261012:
    Run the following command to upgrade to 2023.12.20261012:

      dnf upgrade --releasever=2023.12.20261012

    Release notes:
     https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.12.20261012.html

That output came from a server still on 2023.12.20260930.0; it lists every newer release with the exact upgrade command and its release notes page. If the command is missing (minimal and container images do not include it), install the plugin that provides it with sudo dnf install 'dnf-command(check-release-update)', which pulls in dnf-plugin-release-notification. Reading those notes before each --releasever jump is the closest thing to a changelog for your own servers.

If you have to stay on AL2 for a while: how to update Amazon Linux 2

Sometimes your vendor application only supports AL2, or your migration has to wait for a release window. While you still run AL2, a few habits keep your risk down:

• Keep updating anyway. sudo yum update still installs whatever fixes are published, and sudo yum update --security limits it to security fixes if you want a smaller change; 320 advisories in four months are worth having. Reboot afterwards if the kernel was updated.
• Prefer Extras packages over the old built-in versions where an Extras topic exists, as the PHP2Shell case showed: Extras PHP 8.2 was fixed, built-in PHP 5.4 was not.
• Shrink what the server exposes. Close every port the security group does not need, put web traffic behind a load balancer or CloudFront with AWS WAF, and use Systems Manager Session Manager instead of open SSH.
• Write the exception down with an end date. "We stay on AL2 until March 31 for vendor X" survives an audit far better than an AL2 server nobody can explain.

Jake: "And if we'd just left it?"

Ethan: "It would have kept working right up until the day it didn't, and on that day nobody would have been coming."

When does Amazon Linux 2023 reach end of life (EOL)?

Amazon Linux 2023 has a fixed, published lifecycle, which is one of the reasons to move to it rather than to another stopgap. Standard support, with quarterly minor releases, runs until June 30, 2027. After that, maintenance support with security updates and critical bug fixes runs until June 30, 2029, its end of life. Core packages such as glibc, OpenSSL, OpenSSH and dnf are supported for that whole lifetime. If you move now rather than waiting for the next major version, a migration done in 2026 gives you almost three years before you have to think about the next one.

Amazon Linux 2023 and Amazon Linux 2 download: VM images, containers, and why there is no ISO

People search for an Amazon Linux "ISO" to install on a laptop or a server, and do not find one, because there is no installer. Amazon Linux comes as ready-made disk images for virtual machines and as container images, all from cdn.amazonlinux.com. Here is what the latest builds offer, as listed on October 23, 2026:

Two surprises in that table. First, AL2023 has no VirtualBox image, so on a Windows or Mac laptop the practical routes are Hyper-V (Windows), a KVM-compatible tool, VMware, or simply a container. Second, the file people find when they search for the AL2 ISO is that 366 KB seed.iso, which contains only first-boot settings.

Running a VM image takes one extra step, because there is no setup wizard and no default password. The images use cloud-init, and for machines outside AWS the recommended source is the NoCloud data source: a small disk labeled cidata that holds two files, meta-data and user-data, attached on first boot:

# meta-data
instance-id: al2023-lab-01
local-hostname: al2023-lab

# user-data
#cloud-config
password: choose-a-long-password
chpasswd: { expire: False }
ssh_pwauth: True

genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data

Attach seed.iso as a CD drive next to the downloaded disk, boot, and log in as the image's default user, ec2-user, with that password. For anything beyond a lab, use an SSH key in user-data instead of a password. Note that AL2023 images are configured differently from AL2 ones, so an AL2 on-premises setup needs adapting rather than copying.

The quickest way to try Amazon Linux on any machine is a container, no download page needed:

podman run -it --rm public.ecr.aws/amazonlinux/amazonlinux:2023 bash
# or: docker run -it --rm amazonlinux:2023 bash

A container shares your machine's kernel, so it is right for testing packages, scripts and builds against AL2023, and wrong for testing kernel or boot behavior; use a VM image for that.

Amazon Linux 2023 vs Ubuntu and Debian: the differences that matter

"Is Amazon Linux 2023 based on Red Hat, Ubuntu or Debian?" None of them directly. AL2023 is an RPM-based system that took components from Fedora 34, 35 and 36; some are the same as Fedora's, some are modified, and others more closely resemble CentOS Stream 9 or were developed independently. Its kernel comes from the long-term support kernels on kernel.org (6.1 in the current images), chosen independently of Fedora, and it keeps its own release and support schedule. So it feels like Fedora or RHEL at the command line (dnf, rpm, systemd), but it is not binary-compatible with RHEL and shares nothing with Debian or Ubuntu's apt world.

The number that decides most "will my software run?" questions is the C library version, glibc. Here it is for each system, read from the official container images:

Read it from the bottom up to see the AL2 problem: many prebuilt programs now need glibc 2.28 or newer, and AL2's 2.26 is older than every other system in the table, which is where GLIBC_2.28 not found comes from. AL2023's 2.34 sits between Ubuntu 20.04 and 22.04, so a binary built on Ubuntu 22.04 or 24.04 can still fail on AL2023 with GLIBC_2.35 not found or GLIBC_2.38 not found; build on the oldest system you deploy to, or build inside an AL2023 container. To check any machine, run ldd --version.

Choosing between them comes down to fit rather than quality. Pick AL2023 when you run on AWS and want the AWS-maintained OS with a long, fixed support window (to June 30, 2029), RPM packages and locked, reproducible releases. Pick Ubuntu or Debian when your software, your vendor or your team expects apt and Debian packages, or a vendor certifies only Ubuntu. Both are common on EC2, and moving a web app between them is mostly a matter of package names.

Installing Python and pip on Amazon Linux 2023

The python3 on AL2023 is 3.9 (3.9.25 on the 2023.12 release), and pip is not installed by default. Newer Pythons are ordinary packages, each with its own pip package:

$ dnf list --available 'python3.1[0-9]' 'python3.1[0-9]-pip'
python3.11.x86_64        3.11.16-1.amzn2023.0.1
python3.11-pip.noarch    22.3.1-2.amzn2023.0.15
python3.12.x86_64        3.12.14-2.amzn2023.0.1
python3.12-pip.noarch    23.2.1-4.amzn2023.0.12
python3.13.x86_64        3.13.15-1.amzn2023.0.1
python3.13-pip.noarch    24.2-259.amzn2023.0.9
python3.14.x86_64        3.14.7-1.amzn2023.0.1
python3.14-pip.noarch    26.1.1-1.amzn2023.0.4

1. For the system Python: sudo dnf install python3-pip, which gives pip 21.3.1 ... (python 3.9).
2. For a newer Python: sudo dnf install python3.13 python3.13-pip, then call it by its full name, python3.13.
3. Make a virtual environment for your app: python3.13 -m venv ~/app-venv, then source ~/app-venv/bin/activate and pip install ... inside it.
4. Do not repoint python3 to the newer version with alternatives or a symlink. dnf itself is a Python 3.9 program (its first line is #!/usr/bin/python3), and changing what python3 means can break package management.
5. Avoid sudo pip install into the system Python; use a virtual environment or pip install --user, so dnf-managed packages are never overwritten.

Ethan's rule for Jake's servers: "System Python belongs to dnf. Your app gets its own Python and its own venv." It has saved them one broken package manager already.

The Amazon Linux 2 end-of-life checklist

1. Find every AL2 machine: cat /etc/system-release through Systems Manager, plus amzn2-ami AMIs in every Region.
2. Check the hidden ones: EKS node groups, ECS container instances, Beanstalk platforms, Lambda runtimes.
3. Keep running sudo yum update on AL2 until each server is gone.
4. For each server: snapshot, list services, cron jobs and extras, launch AL2023, reinstall with dnf, copy data, test, switch.
5. Expect the five first-hour errors: extras, crontab, python, EPEL, curl-minimal.
6. On AL2023, remember the release lock: dnf upgrade --releasever=latest from time to time.
7. Put June 30, 2027 and June 30, 2029 in the calendar now.

Frequently asked questions

Two weeks later the old AL2 server was gone, its AMI kept in a corner of the account in case the auditors ever ask. The new one runs the same stock database and the same little PHP app, and its nightly backup runs from a systemd timer that Ethan swears is better than cron. "Did anything get faster?" Jake asked. "Not that you'd notice," Ethan said. "It just has a future now."

Revision note. Written October 23, 2026, with the Amazon Linux 2 advisory list, the EKS, ECS, Elastic Beanstalk and Lambda deadlines, and current AL2 and AL2023 systems as they stood on that date. "Don't wait for the roof to leak before you fix it," the saying goes, and AL2's roof is now nobody's job.