AWS has opened the public preview of Amazon Linux 2027, and one change stands out immediately: SELinux ships in enforcing mode by default. The distribution builds on the AL2023 baseline, moves to kernel 7.1, adopts DNF5, and enables link-time optimization. For teams running EC2 workloads, the SELinux switch alone is reason to start testing now — applications that pass on AL2023’s permissive mode may simply fail under AL2027.
TL;DR: AWS has released Amazon Linux 2027 in public preview, built on the AL2023 baseline with kernel 7.1, DNF5, and SELinux in enforcing mode by default. Applications that pass on AL2023’s permissive SELinux mode may fail under AL2027, so teams running EC2 workloads should start validating early (InfoQ, September 2026).
What Is Amazon Linux 2027 and Why Did AWS Open a Public Preview?
Amazon Linux 2027 (AL2027) is the next generation of AWS’s server-focused Linux distribution, released in public preview in September 2026. It builds directly on the AL2023 baseline, so the package ecosystem, tooling philosophy, and release model teams already know carry forward (InfoQ, September 2026). A public preview means anyone running EC2 instances can boot the distribution today, long before general availability.
The headline changes are four: kernel 7.1, the DNF5 package manager, link-time optimization (LTO) for built packages, and SELinux switched to enforcing mode out of the box. Each affects different layers of the stack — kernel, packaging, compiler behavior, and mandatory access control respectively.
Why open a preview this early? Amazon Linux has a fixed, predictable cadence. The Amazon Linux family dates back to the original Amazon Linux AMI announced in 2010, which reached end of life at the close of 2023, followed by Amazon Linux 2 and AL2023 (hidekazu-konishi.com). A preview aligned with the two-year rhythm gives administrators a long runway.
That runway matters. Instance fleets, container images, and automation all depend on the distribution. Finding incompatibilities during a preview — especially SELinux denials that only appear in enforcing mode — is far cheaper than discovering them in production after migration.
Why Does SELinux Enforcing Mode by Default Matter for EC2 Workloads?
This is the change most likely to break running applications. On AL2023, SELinux operates in permissive mode — the kernel logs policy violations but does not block them. AL2027 flips that default to enforcing, meaning the kernel actively denies any action not explicitly allowed by policy (InfoQ, September 2026).
What does that mean in practice? An application writing to an unexpected path, binding a nonstandard port, or spawning a helper binary in a way the policy doesn’t anticipate will now get EACCES or EPERM errors instead of silent success with an audit log entry. Code that has “worked fine” on AL2023 may have been relying on permissive behavior all along without anyone noticing.
The blast radius is broad:
- Daemons that write logs or caches outside standard labeled directories
- Custom systemd services with unexpected file contexts
- Applications binding ports not defined in policy
- Installer scripts that relabel or create files in system paths
- Container runtimes interacting with host mounts
- Third-party agents (monitoring, backup, security) built against permissive assumptions
The diagnostic workflow is familiar to anyone who has run RHEL or Fedora in enforcing mode: watch /var/log/audit/audit.log for AVC denials, then fix labels or write targeted policy modules. The semanage fcontext and audit2allow tooling flow applies here too.
The smart migration step is simple: take your AL2023 workloads, run them on the AL2027 preview in enforcing mode, and collect denials now. Fixing a file label during preview costs minutes. Debugging the same denial in a production incident costs a lot more.
What Does the Jump to Kernel 7.1 Change for Developers?
AL2027 ships with kernel 7.1, a major version jump from the kernel line used by AL2023. For developers, the kernel is where hardware support, filesystem behavior, networking features, and security hardening all land (administraciondesistemas.com).
Two audiences care most here. First, teams that build kernel modules or use out-of-tree drivers — network agents, storage filters, GPU tooling — must verify their code compiles and passes validation against the 7.1 headers. Kernel internal APIs change between major versions, and a module that built cleanly on the AL2023 kernel may need source updates.
Second, everyone else benefits without touching code. Newer kernels carry accumulated improvements in scheduling, memory management, and filesystem performance, plus support for newer hardware classes on the newest EC2 instance families. Administrators tracking the change note that kernel version jumps are among the most consequential updates in an Amazon Linux generation precisely because everything above the kernel inherits its behavior (administraciondesistemas.com).
There is also a security angle. A current kernel receives fixes and hardening features that older long-term branches gradually stop getting, and AL2027 pairs kernel 7.1 with enforcing SELinux — the two changes reinforce each other at the system level.
The practical advice: rebuild container base images and machine images against the AL2027 preview now, and run your existing test suites. Kernel upgrades rarely break userland applications directly, but they do break assumptions embedded in monitoring agents and low-level tooling.
How Does DNF5 Affect Package Management on AL2027?
AL2027 adopts DNF5 as its package manager, the next major iteration of the DNF tooling that RPM-based distributions have standardized on. Command syntax for the common operations — dnf install, dnf update, dnf remove — remains the same, so day-to-day usage feels familiar (byteiota).
What changes is the engine underneath. DNF5 is a rewrite designed around a cleaner architecture, faster dependency resolution, and more consistent behavior across commands. For CI/CD pipelines that run dnf hundreds of times a day inside image builds, resolution speed is not cosmetic — it directly affects build times.
For administrators, the migration checklist looks like this:
- Audit scripts and CloudInit user data for any output-parsing of
dnfcommands, since output formats can differ between major versions - Check any tooling that imports DNF’s Python API — DNF5’s extension interface differs from the old one
- Verify repository configuration files and custom repos resolve correctly under the new dependency solver
- Re-run automated image builds and compare installed package sets against your AL2023 baseline
The good news is that because AL2027 continues the AL2023 lineage, most existing repo definitions, RPMs, and build automation should carry over with minimal edits. The preview exists precisely so those assumptions get tested rather than trusted.
If your pipeline includes custom RPM builds, rebuild and reinstall them on the preview early. Packaging problems surface as dependency conflicts, and catching those now keeps the eventual migration boring — which is exactly what you want from an OS upgrade.
What Is Link-Time Optimization (LTO) and What Should You Expect From It?
AL2027 builds its packages with link-time optimization enabled. LTO lets the compiler perform optimizations across translation-unit boundaries — instead of optimizing each source file in isolation, the compiler sees and optimizes the whole program at link time (byteiota).
The practical results are typically better inlining, dead-code elimination across library boundaries, and generally tighter binaries. For a server distribution, that means packages compiled with LTO can squeeze more performance from the same hardware, which compounds across thousands of EC2 instances.
But LTO also changes build behavior, and that’s what developers building their own software on AL2027 should prepare for:
- Builds consume more memory and time during the link phase, which matters for constrained CI runners
- Some code patterns that compiled before may trigger new warnings or errors under LTO
- Debugging experiences can differ, since inlining across units changes what symbols and frames appear in stack traces
- Static libraries built without LTO may interact differently when linked into LTO-enabled builds
None of this is a blocker — it is a known trade-off that distribution maintainers accept when they enable LTO, trading longer builds for faster runtime binaries. Teams that compile performance-sensitive software (databases, proxies, codecs) directly on Amazon Linux should benchmark both the build process and the resulting binaries on the AL2027 preview.
The broader pattern across kernel 7.1, DNF5, LTO, and enforcing SELinux is clear: AL2027 is a security- and performance-focused refresh of a familiar baseline. The components are new; the ecosystem is not.
How Does AL2027 Fit Into the Amazon Linux Release and Support Timeline?
Amazon Linux 2027 is the fourth generation in the distribution’s history, following the original Amazon Linux AMI, Amazon Linux 2, and AL2023. The timeline is well documented: Amazon Linux AMI was announced in 2010 and reached end of life at the close of 2023, Amazon Linux 2 carried the platform through the 2018–2023 era, and AL2023 introduced the two-year major release cadence that AL2027 now continues. Each generation received a fixed, publicly documented support window.
The rhythm matters for planning. AWS publishes end-of-life dates years in advance so teams can schedule migrations instead of reacting to deadlines. AL2023’s lifecycle and the transition paths between generations are covered in AWS’s official documentation, and the same approach is expected for AL2027.
What makes AL2027 unusual is not the cadence but the size of the jump. A new kernel generation, a new package manager, and a default security posture change all arriving at once is rare for this distribution. Teams that skipped migrations between minor AL2023 patches will feel the difference. The hidekazu-konishi.com timeline is a useful reference because it builds its overview only from officially published dates, avoiding speculation about unsupported windows.
Which generations came before? Four, each with its own clock.
Which Applications Are Most Likely to Break During Migration?
The short answer: anything that ran fine on AL2023 only because SELinux was permissive. AL2023 ships with SELinux in permissive mode, which logs policy violations without blocking them. AL2027 switches to enforcing mode by default, so applications that silently violated policy can now be actively denied access to files, ports, or devices.
The failure mode is deceptive. Nothing warns you during development on AL2023 because the violation was never enforced — it only appeared in audit logs most teams never read. On AL2027, the same behavior produces permission denied errors, failed socket bindings, or services that refuse to start.
Categories most exposed:
- Custom daemons writing to non-standard directories like
/optor/srv/data - Applications binding unusual network ports not defined in the target SELinux policy
- Services spawning helper processes with unexpected file contexts
- Containers or runtimes mounting host paths with incorrect labels
- Monitoring agents reading system logs outside their allowed context
- Legacy binaries compiled without any SELinux awareness
- Scripts that relabel files at runtime, tripping policy checks
The migration guidance from InfoQ and byteiota is consistent: audit your AL2023 audit logs now. Every AVC denial recorded in permissive mode is a future production incident on AL2027.
How do you find these before they find you? Read the logs. They already contain the answer.
How Should Teams Prepare Their AL2023 Environments for the Move?
Preparation starts with treating AL2023’s permissive SELinux mode as a diagnostic tool, not a footnote. The audit logs on your current instances contain a complete inventory of policy violations — and each one predicts a failure on AL2027. The byteiota analysis argues this audit is the single most valuable action teams can take before the general availability release.
A practical preparation sequence:
- Enable and centralize auditd log collection across AL2023 fleets
- Grep for
AVC deniedentries and group them by service and path - Classify each violation as expected (needing a policy module) or accidental (needing a code fix)
- Write or install SELinux policy modules for legitimate violations
- Test critical workloads on the AL2027 public preview in a staging environment
- Validate package workflows against DNF5, since syntax and behavior differ from the older DNF
- Rebuild locally with Link-Time Optimization enabled to catch compiler-related regressions early
- Document kernel 7.1 dependencies, especially for out-of-tree modules or custom drivers
The DNF5 migration deserves its own testing cycle. Package manager changes break CI pipelines in unglamorous ways: changed command output, different plugin behavior, and altered transaction semantics. Teams that automate AMI builds should run those pipelines against preview images now, not after GA.
Start small. One staging workload tells you more than a hundred planning documents.
How Does AL2027 Compare to Previous Amazon Linux Generations?
Each Amazon Linux generation reflected the era it shipped in. Amazon Linux AMI (2010) was a yum-based distribution tuned for early EC2. Amazon Linux 2 modernized the base and introduced long-term support with systemd. AL2023 brought a two-year release cadence, immutable release notes, and a deterministic support lifecycle. AL2027 continues the cadence but pushes the platform further than any predecessor.
| Generation | Era | SELinux Default | Notable Shift |
|---|---|---|---|
| Amazon Linux AMI | 2010–2023 | Not enforcing | First EC2-tuned distribution |
| Amazon Linux 2 | 2017 onward | Permissive | systemd, long-term support |
| AL2023 | 2022 onward | Permissive | Two-year cadence, DNF |
| AL2027 (preview) | 2026 onward | Enforcing | Kernel 7.1, DNF5, LTO |
The SELinux column tells the story. Earlier generations treated mandatory access control as opt-in; AL2027 makes it the default state of the operating system. Combined with the jump to kernel 7.1 and DNF5 replacing the older DNF, AL2027 represents one of the larger platform shifts in the distribution’s history — comparable in scope to the Amazon Linux 2 transition, but with security posture as the headline change.
For administrators, the comparison frame is simple: AL2023 was an incremental update to a familiar model. AL2027 changes the model. The Spanish-language analysis at administraciondesistemas.com frames it the same way — a release that changes what administrators must verify, not just what they can optionally enable.
When Will Amazon Linux 2027 Reach General Availability?
AWS has not published a specific general availability date for AL2027. What is confirmed: the public preview opened in September 2026, and the release follows the two-year cadence established by AL2023, which points to a 2027 window consistent with the distribution’s naming.
AWS’s pattern with previous generations suggests how the road to GA will look. AL2023 went through extended preview and release candidate phases before its final launch, with lifecycle and end-of-support dates published as part of the release documentation. The same fixed-date approach is expected here — the hidekazu-konishi.com timeline emphasizes that every Amazon Linux generation has had its end of life announced years ahead.
For teams, the preview period is the migration runway. Applications validated on the preview with SELinux enforcing enabled will move to GA with minimal friction. Applications validated only on AL2023 will carry hidden SELinux violations straight into production. The practical advice from the byteiota coverage is blunt about this: treat the preview as mandatory testing time for anything running on EC2 with AL2023 today.
No date yet. But the clock is already running for anyone who waits.
Frequently Asked Questions
Is Amazon Linux 2027 available now?
Yes. AWS opened AL2027 to public preview in September 2026, built on the AL2023 baseline with kernel 7.1 and SELinux in enforcing mode by default. It is intended for testing and validation, not production workloads.
Why might applications that run on AL2023 fail on AL2027?
AL2023 ships with SELinux in permissive mode, which logs violations without blocking them. AL2027 switches to enforcing mode by default, so applications that silently violated policy on AL2023 can be actively denied on AL2027.
What is new in the AL2027 kernel?
AL2027 moves to kernel 7.1, a major step up from the kernel generation used in AL2023. Combined with DNF5 as the package manager and Link-Time Optimization in builds, it marks one of the larger platform shifts in the distribution’s history.
How long will Amazon Linux 2027 be supported?
AWS publishes fixed lifecycle dates for each Amazon Linux generation, similar to the schedules documented for Amazon Linux AMI, Amazon Linux 2, and AL2023. Exact AL2027 end-of-life dates should be confirmed against AWS’s official documentation as the release matures.
Summary
Amazon Linux 2027’s public preview is more than a routine version bump. The key takeaways:
- SELinux enforcing by default is the headline change. Applications that pass on AL2023’s permissive mode may fail outright, making audit-log review the most urgent pre-migration task.
- Kernel 7.1, DNF5, and LTO arrive together. This is one of the largest platform shifts in Amazon Linux history, affecting CI pipelines, package workflows, and local builds.
- The two-year cadence holds. AL2027 follows the lifecycle model established by AL2023, with fixed dates to be confirmed in AWS documentation.
- The preview period is the migration window. Teams that test on preview images in September 2026 and beyond will reach GA without surprises.
If you run workloads on AL2023, start reading your audit logs today — and spin up a preview instance this week. Share your migration findings in the comments below.