Amazon Web Services (AWS) has opened the public preview of Amazon Linux 2027 (AL2027), the next generation of its Linux distribution for servers and cloud workloads. The move from Amazon Linux 2023 brings changes that directly affect system administrators: Linux kernel 7.1, SELinux in enforcing mode by default, DNF5, systemd 260, GCC 16.1, Python 3.14, and a major refresh of the cryptographic stack. It is not yet intended for production, but sysadmins can already start testing migrations, automation, and custom images.
Amazon Linux 2027 for sysadmins: the key points in 30 seconds
- AL2027 is available as a public preview for x86-64 and ARM64.
- The default kernel moves to Linux 7.1, while SELinux changes from
permissivetoenforcing. - DNF5 replaces DNF4, RPM moves to version 6, and systemd is upgraded to version 260.
- AWS also updates GCC, glibc, Python, and much of the development toolchain.
- Before migrating, administrators should review SELinux policies, automation scripts, repositories, and internally compiled software.
For a system administrator, the fact that Amazon Linux 2027 has a newer kernel version than other distributions is probably not the most important part of the announcement. The more useful question is: what could stop working when an instance based on Amazon Linux 2023 is rebuilt on AL2027?
There is quite a lot to check.
Amazon Linux remains a distribution closely tied to AWS. It uses RPM packages, DNF as its package manager, and technologies commonly found in enterprise Linux environments, but Amazon controls its release cycle, repositories, kernels, and integration with its own services.
AWS also explains that AL2027 incorporates components from Fedora 44 and Fedora 45, but it should not be considered a rebuild of any specific Fedora release. Nor is it intended to be binary-compatible with Red Hat Enterprise Linux (RHEL), unlike distributions specifically designed around that objective.
SELinux enforcing may be the change that creates the most work
Linux 7.1 makes for a good headline, but SELinux probably deserves more attention during a real migration.
Amazon Linux 2023 uses SELinux in permissive mode by default. In this configuration, operations that violate security policies are logged, but the system does not actually block them.
Amazon Linux 2027 changes the default behavior to:
SELinux status: enabled
Current mode: enforcingThis means that an internal application, legacy service, or configuration accumulated over the years could encounter a denial that previously only appeared in the logs.
The change strengthens the system’s default security posture, but it also requires testing.
Before migrating a workload, administrators should review SELinux events generated by existing applications, particularly on servers running custom software, using non-standard directories, NFS mounts, customized web services, or processes that need access to resources with different SELinux contexts.
Administrators can check the current status with:
sestatusand search for denials with tools such as ausearch:
ausearch -m AVC,USER_AVC -ts recentPermanently switching back to permissive just to make an application work may hide the immediate problem, but it also removes much of the protection AWS intends to provide with this change. For production environments, identifying the denial and adjusting contexts or policies where appropriate is generally the better approach.
DNF5, RPM 6, and systemd 260 mean automation needs testing
Amazon is also refreshing several components that tend to sit underneath deployment scripts, machine images, and configuration management systems.
The comparison with Amazon Linux 2023 shows how extensive the changes are:
| Component | Amazon Linux 2023 | Amazon Linux 2027 Preview |
|---|---|---|
| Default kernel | 6.1 | 7.1 |
| SELinux | Permissive | Enforcing |
| DNF | 4.14 | DNF5 5.4 |
| RPM | 4.16 | 6.0 |
| systemd | 252 | 260 |
| GCC | 11.5 | 16.1 |
| glibc | 2.34 | 2.44 |
| LLVM/Clang | 15/18/19 | 22 |
| Default Python | 3.9 | 3.14 |
| PCRE | PCRE1 and PCRE2 | PCRE2 only |
| zlib | 1.2.11 | zlib-ng 2.3 |
DNF5 replaces DNF4 as the default implementation. The familiar commands:
dnfand
yumremain available, so the transition should not be particularly disruptive for basic package administration.
Problems may arise in automation that relies on DNF internals. The python3-dnf Python API used with DNF4 is no longer available in AL2027, meaning applications that depend directly on it will need to move to python3-libdnf5.
That makes it worth reviewing custom Python scripts, internal tools, and older automation before assuming that an Ansible collection, bootstrap process, or image-building workflow will continue to work unchanged.
Something similar applies to systemd. AL2027 uses systemd 260 and drops compatibility with old System V service scripts. A modern server may not use them at all, but a business application installed years ago could still have an init.d script that nobody remembers.
A lab AMI is a much better place to discover that than a production deployment.
Python 3.14 and GCC 16.1: watch your in-house software
Another area that deserves particular attention from administrators maintaining internal applications is the development environment.
Amazon Linux 2027 uses Python 3.14 as its default version, compared with Python 3.9 in AL2023. It also moves from GCC 11.5 to GCC 16.1 and from glibc 2.34 to glibc 2.44.
That does not automatically mean applications compiled for AL2023 will stop working. AWS expects to maintain a significant degree of compatibility for existing applications.
Recompiling software is a different matter.
GCC 16 introduces changes to standards, checks, and default behavior. A project that has compiled without problems for years may begin producing warnings or errors that did not previously appear.
Python scripts require an even more obvious review. A script beginning with #!/usr/bin/python3 may end up running on a very different interpreter from the one used on the original server.
For Python applications, it is generally safer to avoid unnecessary dependencies on the system interpreter and use virtual environments or equivalent mechanisms:
python3 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activateAL2027 also removes PCRE1 and retains PCRE2 only, another detail that could affect legacy software compiled against the older library.
Amazon Linux, Ubuntu, Debian, or Rocky for a new server?
Amazon Linux 2027 makes the most sense when infrastructure is closely tied to AWS.
There is no universally best Linux distribution. For a sysadmin, the lifecycle, supported applications, and deployment environment matter far more.
| Scenario | Distribution to consider | Main advantage |
|---|---|---|
| Infrastructure almost entirely on AWS | Amazon Linux | Direct AWS integration |
| EC2 on Graviton | Amazon Linux | Strong ARM64 integration with AWS |
| Inferentia/Trainium | Amazon Linux | AWS Neuron and native accelerators |
| General-purpose Linux server | Debian | Stability and portability |
| Cloud/multicloud | Ubuntu LTS | Broad cloud and commercial support |
| Environment migrating from RHEL | Rocky/AlmaLinux | Compatibility with the RHEL ecosystem |
| On-premises + cloud | Debian/Ubuntu/Rocky/AlmaLinux | Less dependence on a single provider |
| Containers on AWS | Amazon Linux | Official images and AWS environment |
There is an important conceptual difference.
An administrator can deploy Debian, Ubuntu, Rocky Linux, or AlmaLinux on almost any hypervisor, physical server, or cloud provider and retain a broadly similar platform. Amazon Linux can be used outside EC2 in certain scenarios, but its value proposition is clearly built around AWS.
That can be an advantage rather than a drawback.
For a company using EC2, Graviton, Auto Scaling, AWS Systems Manager, ECR, and other AWS components, reducing differences between the operating system and the underlying infrastructure may simplify operations.
For an organization running AWS, Azure, its own infrastructure, and several hosting providers, standardizing on Ubuntu, Debian, or a RHEL-family distribution may provide greater consistency.
A quick comparison for system administrators
| Feature | AL2027 | Ubuntu 26.04 LTS | Debian 13 | Rocky/Alma 10 |
|---|---|---|---|---|
| Package format | RPM | DEB | DEB | RPM |
| Package manager | DNF5 | APT | APT | DNF |
| SELinux | Yes, enforcing | Not by default | Available | Yes |
| AppArmor | Not primary | Yes | Available | Not primary |
| AWS optimized | Yes | AWS images available | AWS images available | AWS images available |
| Multicloud | Possible | Very common | Very common | Very common |
| RHEL compatibility | No | No | No | Yes |
| ARM64 | Yes | Yes | Yes | Yes |
| AWS Neuron | Direct integration | Available depending on stack | Depends on environment | Depends on environment |
| AL2027 production use today | Not yet recommended | Yes | Yes | Yes |
The final row is currently the most important one.
AL2027 remains a public preview. AWS is providing it so customers can test applications, build trial images, identify incompatibilities, and report issues before general availability.
This is not yet the time to replace AL2023 production instances indiscriminately.
What sysadmins should test before considering AL2027
The preview does, however, provide an opportunity to prepare early. In organizations running dozens or hundreds of Amazon Linux instances, waiting until general availability to discover incompatibilities can move all that work into the migration project itself.
A first lab AMI can already be used to check:
- Application startup and systemd services.
- Denials caused by SELinux
enforcing. - Scripts dependent on Python 3.9.
- Automation tied to DNF4.
- Custom RPM packages and internal repositories.
- Software compiled against older glibc or PCRE versions.
- Monitoring, EDR, and backup agents.
- External kernel modules.
- Cloud-init and automated instance provisioning.
- Ansible playbooks, recipes, and AMI-building pipelines.
Third-party software also deserves testing. An application working technically on an RPM-based distribution does not mean its vendor will immediately certify Amazon Linux 2027.
For administrators, that distinction matters. Software can work perfectly while still falling outside the vendor’s official support matrix.
AWS provides preview AL2027 AMIs across its commercial regions for both x86-64 and ARM64, along with base container images through Amazon Elastic Container Registry (ECR) Public.
Accelerator integration is another area receiving attention. Amazon highlights support for AWS Neuron drivers, the SDK used with its Trainium and Inferentia accelerators for artificial intelligence and machine learning workloads.
The planned AL2027 lifecycle extends to 2032, although the conditions applying to the current preview are different and AWS may change components before general availability.
For that reason, the preview is more valuable as a testing platform than as a new production server. Linux 7.1 will attract much of the attention, but for the people who actually have to administer the platform, SELinux enforcing, DNF5, systemd 260, Python 3.14, and the library changes are likely to determine how much work the move from AL2023 to AL2027 will really involve.