Amazon Linux 2027 Public Preview: What’s Changed and What to Test Now

AWS announced the Amazon Linux 2027 (AL2027) Public Preview on September 3, 2026. Amazon Linux is a Linux distribution built and maintained by AWS for workloads running on AWS, such as EC2 and containers. The core of this announcement is not just the change in the year in the name. Security defaults, CPU baselines, package managers, and development toolchains have all been modernized at once.

However, the fact that it can be downloaded now does not mean it is ready for production environments. AWS explicitly states that the current version is a preview for evaluation and testing, and does not recommend it for production use. The task now is not to immediately replace servers, but to proactively identify where AL2023 workloads might break with the new defaults in non-production environments.

Amazon Linux 2027 transition scene with security shields and two types of CPU paths on a modern AWS cloud server base.

Key Changes Identified in the Announcement

AL2027 builds upon AL2023 but offers Linux kernel 7.1 or later, SELinux enforcing by default, DNF5, OpenSSL 3.5 and AWS-LC, and the latest language runtimes and compilers. x86-64 and Arm64 AMIs are available as a preview in all commercial AWS regions, and container base images can be obtained from Amazon ECR Public.

Item Familiar Standard in AL2023 Changes in AL2027 Preview What to Check First
— — — —
SELinux Default permissive Default enforcing AVC denials for applications/agents
Package Management DNF-based DNF5 Automation scripts and plugin compatibility
x86 Baseline x86-64-v2 x86-64-v3 Older instances/on-premise CPUs
Arm Baseline 64-bit Arm ARMv8.2+crypto, Graviton2 or later Exclusion of A1 and older boards
Cryptography Existing system policy PQC enabled by default, OpenSSL 3.5, AWS-LC TLS/SSH interoperability
Development Tools GCC 11 series default GCC 16.1, LLVM/Clang 22 Warnings/compile errors and language standard changes

While AWS product pages may mention GCC 16.2, the current detailed user guide and package documentation describe GCC 16.1 as the standard. During the preview period, packages and configurations may change, so it is safer to verify with gcc --version on the actual AMI and check the release notes.

The Biggest Operational Change is SELinux Enforcing

AL2023 defaulted to permissive SELinux, which logged policy violations but did not block them. AL2027 defaults to enforcing, meaning file access, port binding, and process actions not allowed by policy will actually be blocked. While this is a safer starting point from a security perspective, applications that previously ignored permissive logs might fail in specific functions even if they appear normal after booting.

On preview instances, first check the following:

cat /etc/os-release
getenforce
sudo ausearch -m AVC,USER_AVC -ts recent
sudo journalctl -t setroubleshoot --since today

Immediately disabling SELinux upon encountering blocks is not a good migration test. You should verify if the service genuinely requires the access and allow it using the narrowest possible method among file contexts, Booleans, or policy modules.

x86-64-v3 is a Performance Opportunity and a Compatibility Boundary

AL2027’s x86-64 packages are built to the x86-64-v3 baseline, which includes features like AVX, AVX2, BMI1/2, and FMA. While this generally corresponds to CPUs from 2015 onwards, not all older EC2 instance types or on-premise virtualization hosts will meet the requirements. If the conditions are not met, it may result in an illegal instruction failure early in boot, rather than an application error.

Arm64 requires ARMv8.2 and Cryptography Extension, and AWS supports Graviton2 or later. A1 instances and models older than Raspberry Pi 5 are not targeted. Before simply replacing the AMI, you should inspect the CPU capabilities of your current instance types and custom image build machines.

Post-Quantum Cryptography and SSH Hardening Become Defaults

AL2027 enables Post-Quantum Cryptography (PQC) by default in its system crypto policies. OpenSSH uses PQC key exchange, and OpenSSL 3.5, GnuTLS, and NSS include support for ML-KEM hybrid key exchange and new signature algorithms. This does not mean existing RSA/ECDSA certificates will immediately become unusable. The actual check involves ensuring that older TLS equipment, proxies, libraries, and SSH clients properly handle the new negotiation combinations.

Hardened settings in OpenSSH 9.9p1 also need to be reviewed. DSA is no longer supported, and RSA keys shorter than 2048 bits are not allowed by default. If older automation accounts and equipment use DSA keys or short RSA keys, they should be replaced with Ed25519, ECDSA, or sufficiently long RSA keys before transitioning to AL2027.

Development Environments and Image Pipelines Also Need Retesting

DNF5 is not merely a version change of the existing DNF but a new implementation. While common installation commands are familiar, output parsing, plugins, caching, and automation behavior may differ. If Packer, EC2 Image Builder, cloud-init, and bootstrap scripts rely on dnf output or internal directories, testing is required.

Compiler defaults also change. GCC 16.1 uses C23 and C++20 as default standards. Source code that quietly passed in AL2023 might produce new warnings or errors, so rather than just pinning packages if a build fails, it’s better to explicitly review the code and -std= options.

AI/ML workloads include AWS Neuron driver support for Trainium and Inferentia. However, this does not automatically imply compatibility with NVIDIA CUDA or specific framework combinations. You must verify the accelerator, kernel modules, container runtime, and framework versions you use in a separate matrix.

Safe Preview Validation You Can Do Now

Preview AMIs can be found via the AWS console, CLI, and SSM public parameters. Since exact parameters and AMI IDs may vary by region and release, use the latest values from the documentation. Start in a separate sandbox account or isolated VPC instead of your operational account, and do not include actual data or long-term credentials.

The validation sequence can be kept simple. First, deploy the same application to both AL2023 and AL2027. Compare booting, package installation, service startup, and normal requests. Then, check SELinux denials, SSH connectivity, TLS integration, log/monitoring agents, and backups. Finally, automate AMI building and rollback to verify that it does not affect the existing operational environment.

uname -r
rpm -E '%{fedora}' 2>/dev/null || true
dnf --version
openssl version
ssh -V
gcc --version

Be sure to record the AMI ID, region, architecture, and release version used in your preview results. If the preview is updated, you must re-run the same tests to compare results.

Criteria for Judgment Before GA

AWS has stated its plan to provide 5 years of standard support after AL2027 reaches GA. It also describes a direction to provide the latest LTS kernel at GA, and then release new kernels annually, supporting each kernel for 4 years. However, this should not be interpreted as the GA date and final package configuration being confirmed. Preview Phase 2, announced for November 2026, is expected to add SPAL packages, DCV support, and EKS optimized AMI recipes.

The most realistic perspective on AL2027 now is not ‘Should we switch to the new OS immediately?’ but rather ‘Is our system ready to accept the 2027 security defaults?’ In particular, SELinux enforcing, CPU baselines, DNF5, SSH, and encryption policies can cause failures outside of application code. By converting these four boundaries into automated tests during the preview, migration after GA will become much more predictable.

Official References


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *