Amazon Web Services opened the public preview of Amazon Linux 2027 (AL2027) on September 3, 2026, the next generation of its distribution for EC2 and containers. The first build is named 2027.0.20260903, and AWS repeats it on every documentation page: it is for evaluation and testing, not for production workloads. There are AMIs in every commercial region, for x86-64 and ARM64, plus container base images on ECR Public.
The headline is the Linux 7.1 kernel, but for anyone running machines the real work sits elsewhere: SELinux moves from permissive to enforcing, DNF5 replaces DNF4, RPM jumps to the 6 branch, systemd goes up to 260 and some pieces that old scripts depend on disappear. If you run fleets on Amazon Linux 2023, the preview exists precisely so you find that out now rather than when the final release lands.
What changes compared with AL2023
AWS documentation publishes the comparison piece by piece. This is the part that matters:
| Component | Amazon Linux 2023 | Amazon Linux 2027 (preview) |
|---|---|---|
| Default kernel | 6.1 (6.12 and 6.18 optional) | 7.1 (kernel7.1 package) |
| SELinux | Permissive | Enforcing |
| DNF | 4.14 | DNF5 5.4 |
| RPM | 4.16 | 6.0 (signatures via rpm-sequoia) |
| systemd | 252 | 260, no System V scripts |
| GCC | 11.5 | 16.1 |
| glibc | 2.34 | 2.44 |
| binutils | 2.41 | 2.46 |
| LLVM/Clang | 15, 18 and 19 | 22 (single SRPM) |
| Default Python | 3.9 | 3.14 |
| zlib | 1.2.11 | zlib-ng 2.3 |
| PCRE | PCRE 8.x and PCRE2 | PCRE2 only |
Kernel packages carry the version in their name, as they already did in AL2023, and AWS will add newer kernels over time. According to Phoronix, x86-64 packages are now built for the x86-64-v3 level (AVX and AVX2 assumed) and with LTO enabled, so do not expect AL2027 to boot on very old x86 hardware.
AL2027 is based in part on Fedora 44 and 45, but AWS is explicit that it is neither a derivative nor a rebuild of any particular Fedora release, and that the kernel is picked straight from kernel.org regardless of what Fedora ships. It does not aim for binary compatibility with RHEL either; that is Rocky and AlmaLinux territory.
SELinux enforcing is the first thing to test
In AL2023 SELinux shipped in permissive mode: it logged what it would have blocked, but blocked nothing. In AL2027 the default is enforcing, and the distribution’s main applications come with preconfigured policies.
That means an internal application that has worked for years, a service writing to an unusual directory, an NFS mount or a process reading files with the wrong context will hit a real denial where before there was only a line in the log. It is a good change for system hardening, but you have to go through it before migrating anything.
The sensible move is to look today, on the AL2023 machines you already have, at what SELinux is leaving in the logs:
sestatus
ausearch -m AVC,USER_AVC -ts recentEverything showing up there as a warning becomes a block on AL2027. Switching the whole system to permissive so an application starts hides the problem and throws away the protection AWS wants to provide with this change; the right fix is adjusting contexts or policies case by case.
DNF5, RPM 6 and systemd 260: review what you have automated
The dnf and yum commands still exist and run DNF5 underneath, so day-to-day administration by hand barely changes. The problem is whatever uses DNF from Python: the DNF4 python3-dnf API is not in AL2027 and you have to move to python3-libdnf5. Any in-house script, Ansible collection or image-building process that touches it will fail.
RPM 6.0 verifies OpenPGP signatures with the rpm-sequoia implementation. If you maintain your own spec files or internal repositories, check that they still build and sign the same way.
With systemd 260, compatibility with System V service scripts is gone. A recently built server does not use them, but an enterprise application installed years ago may still hide an init.d nobody remembers, and that is better discovered on a lab AMI.
Python 3.14, GCC 16 and what you compile yourself
The system python3 interpreter goes from 3.9 to 3.14. AWS says code compiled on AL2023 generally runs on AL2027, but recompiling is another story: GCC 16 has stricter defaults and a project that has compiled cleanly for years may start throwing warnings and errors. The same goes for anything linked against PCRE1, which no longer exists, or against classic zlib, now zlib-ng through the zlib-ng-compat package.
For your own Python software the usual advice matters more than ever: do not depend on the system interpreter, use a virtual environment.
python3 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activateThere is a new detail that affects deployments: AL2027 turns on dependency cooldowns for npm and pip by default. They delay installing freshly published packages to give time to spot malicious ones before they reach your machines. AL2023 had this since late 2023, but it had to be configured by hand.
AWS-LC alongside OpenSSL
AL2027 adds AWS-LC, the AWS cryptographic library derived from BoringSSL and OpenSSL, with formally verified portions and FIPS 140-validated cryptography. It does not replace OpenSSL: OpenSSL 3.5 remains the system library and most packages link against it. But the preview already has a growing list of packages built against AWS-LC instead, including httpd, haproxy, rsync, socat, wget1, libpq, python3.14, python-cryptography and the TPM2 tools. For nginx there is a separate package, nginx-awslc.
The two libraries do not cover exactly the same ground in both directions, so if you have software relying on specific OpenSSL functions, check which package it ends up linked against.
Dates, and what to do with AL2023
AWS says AL2027 will be supported until 2032, with the same model as AL2023: a standard phase with quarterly minor releases and a maintenance phase with security and critical fixes only. During the preview, dnf supportinfo only shows dates up to the end of the test period; the real ones arrive with general availability.
There is no rush on the other side. According to the data on the Amazon Linux page, AL2023 remains supported until 2029. Anyone still running instances on Amazon Linux 2, on the other hand, is already late: its lifecycle ended on June 30, 2026.
What does make sense now, on a test AMI, is a short list: service startup, SELinux denials, scripts tied to Python 3.9 or the DNF4 API, your own RPM packages, software linked against old glibc or PCRE, monitoring and backup agents, out-of-tree kernel modules, cloud-init and the pipelines that build your AMIs. And checking with each third-party software vendor whether they will certify AL2027, because working is not the same as being inside their support matrix.
If your infrastructure does not live on AWS, this release matters little to you. Amazon Linux is designed around EC2, Graviton, ECR and friends, and its advantage is exactly that integration (including AWS Neuron drivers for Trainium and Inferentia). For a general-purpose server or for working across providers, Debian, Ubuntu LTS or the RHEL family still give you a more uniform platform anywhere.
Sources: Amazon Linux 2027 preview announcement, Comparing AL2023 and AL2027, Release cadence and Relationship to Fedora in the AWS documentation; amazon-linux-2027 repository on GitHub; Amazon Linux 2027 Now in Preview, on Phoronix; Amazon Linux 2027 llega con kernel 7.1: qué cambia para los administradores, on Administración de Sistemas.