Amazon Linux 2027 has gone into public preview, so I tried launching it on EC2 to check it out
This page has been translated by machine translation. View original
Introduction
On September 3, 2026, the public preview of Amazon Linux 2027 (AL2027) began. AL2027 is the successor to Amazon Linux 2023 (AL2023), and according to the user guide, support will continue until 2032.
In this article, I launched an EC2 instance from the AL2027 preview AMI in the Tokyo region and checked the OS state using Session Manager and Run Command. I'll walk through how the SELinux operating mode, kernel, and package management appear on a freshly launched instance.
Verification Details
All measured values in this article were confirmed using AMIs of the 2027.0.20260903.0 generation released as a public preview.
Checking the AMI
First, I searched from the management console. By displaying public images in the AMI list on the EC2 console and filtering by owner and AMI name, four AL2027 preview AMIs appear.

Using the AWS CLI's describe-images and filtering public images by name al2027-preview-ami-* returned the same four results. The standard and minimal versions are each available for arm64 and x86_64.
| Name | ImageId | Arch | BootMode |
|---|---|---|---|
| al2027-preview-ami-2027.0.20260903.0-kernel-7.1-arm64 | ami-0905bb8a006ab0c19 | arm64 | uefi |
| al2027-preview-ami-2027.0.20260903.0-kernel-7.1-x86_64 | ami-0f5feb3d6c72d5f47 | x86_64 | uefi-preferred |
| al2027-preview-ami-minimal-2027.0.20260903.0-kernel-7.1-arm64 | ami-0d2f76b7d2121f993 | arm64 | uefi |
| al2027-preview-ami-minimal-2027.0.20260903.0-kernel-7.1-x86_64 | ami-06aea6df44d334ce7 | x86_64 | uefi-preferred |
The creation timestamps for all four were 2026-09-02T22:42:20.000Z. The AMI IDs shown in the console also matched the results from this CLI query.
AMI IDs can also be retrieved from SSM public parameters.
aws ssm get-parameters-by-path \
--path /aws/service/ami-amazon-linux-latest \
--query "Parameters[?contains(Name,'al2027')].[Name,Value]" --output text
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-kernel-7.1-arm64 ami-0905bb8a006ab0c19
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-kernel-7.1-x86_64 ami-0f5feb3d6c72d5f47
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-kernel-default-arm64 ami-0905bb8a006ab0c19
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-kernel-default-x86_64 ami-0f5feb3d6c72d5f47
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-minimal-kernel-7.1-arm64 ami-0d2f76b7d2121f993
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-minimal-kernel-7.1-x86_64 ami-06aea6df44d334ce7
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-minimal-kernel-default-arm64 ami-0d2f76b7d2121f993
/aws/service/ami-amazon-linux-latest/al2027-preview-ami-minimal-kernel-default-x86_64 ami-06aea6df44d334ce7
Parameter names come in two variants: ones that include the kernel version and ones using kernel-default. At this time, both variants return the same AMI ID when the architecture and edition (standard/minimal) are the same.
Launching and Connecting via SSM
I specified the AMI ID obtained from the above parameters and launched one arm64 standard instance. The instance type was t4g.small, and the network was a public subnet in the default VPC. The security group has no inbound rules open. For the IAM instance profile, I specified an existing role with AmazonSSMManagedInstanceCore to connect via Session Manager.
aws ec2 run-instances \
--image-id ami-0905bb8a006ab0c19 \
--instance-type t4g.small \
--iam-instance-profile Name=ec2-ssm-core \
--subnet-id subnet-xxxxxxxxxxxxxxxxx \
--security-group-ids sg-xxxxxxxxxxxxxxxxx \
--metadata-options 'HttpTokens=required' \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=al2027-preview-check}]'
After launching, I polled until it was registered as an SSM managed instance.
2026-09-03T17:31:23Z None
2026-09-03T17:31:38Z None
2026-09-03T17:31:54Z None
2026-09-03T17:32:09Z Online Amazon Linux 2027 3.3.5226.0
Registration took 52 seconds. The starting point was the launch time of 17:31:17Z, and the endpoint was 17:32:09Z, when PingStatus was first observed as Online. Since the preceding poll at 17:31:54Z showed it as unregistered, the switch to Online occurred after 17:31:54Z and before 17:32:09Z. The platform reported by SSM was Amazon Linux 2027, and the SSM Agent version was 3.3.5226.0.
After confirming registration, I used both interactive sessions and non-interactive execution. All OS-side output shown in this article was obtained via Run Command.
# Interactive session
aws ssm start-session --target i-xxxxxxxxxxxxxxxxx
# Non-interactive execution (output in this article was obtained this way)
aws ssm send-command --instance-ids i-xxxxxxxxxxxxxxxxx \
--document-name AWS-RunShellScript \
--parameters commands='["cat /etc/os-release"]'
OS Information and SELinux
The OS identification is shown in os-release.
NAME="Amazon Linux"
VERSION="2027"
ID="amzn"
ID_LIKE="fedora"
VERSION_ID="2027"
VARIANT="Public Preview"
VARIANT_ID="preview"
PLATFORM_ID="platform:al2027"
PRETTY_NAME="Amazon Linux 2027.0.20260903"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2027:2027.0.20260903"
HOME_URL="https://aws.amazon.com/linux/"
DOCUMENTATION_URL="https://docs.aws.amazon.com/linux/"
SUPPORT_URL="https://aws.amazon.com/premiumsupport/"
BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2027"
VENDOR_NAME="AWS"
VENDOR_URL="https://aws.amazon.com/"
SUPPORT_END="2026-12-31"
VARIANT and VARIANT_ID indicate that the launched image is a preview version.
The system release notation and kernel are as follows.
$ cat /etc/system-release
Amazon Linux release 2027.0.20260903 (Amazon Linux)
$ uname -r
7.1.0-88.111.amzn2027.aarch64
The kernel package name is kernel7.1, not kernel. Searching the installed packages returns kernel7.1-7.1.0-88.111.amzn2027.aarch64, and kernel7.1-tools is also installed.
SELinux was running in enforcing mode by default.
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 35
The configuration file side was also enforcing, and there were 426 loaded policy modules. Searching the audit log for recent AVCs returned no results, and the same was true after re-checking following the addition of gcc and compilation described later.
Package Management
Let's look at what appears to have changed from AL2023. The versions of major components immediately after launch are as follows.
| Component | Measured Value |
|---|---|
| kernel | kernel7.1-7.1.0-88.111.amzn2027.aarch64 |
| glibc | glibc-2.44-2.amzn2027.0.2 (ldd shows GNU libc 2.44) |
| systemd | systemd 260 (260.1-11.amzn2027.0.6) |
| RPM | RPM version 6.0.0 |
| DNF | dnf5 5.4.2.1 (libdnf5 5.4.2.1) |
| Python | Python 3.14.7 (/usr/bin/python3 is a link to python3.14) |
| OpenSSL | OpenSSL 3.5.7 9 Jun 2026 |
| AWS-LC | aws-lc-libs-5.2.0-2.amzn2027 |
| zlib | zlib-ng-compat-2.3.3-1.amzn2027 (zlib itself is absent) |
| PCRE | pcre2-10.47-1.amzn2027.0.1 (PCRE1 is absent) |
| cloud-init | cloud-init-26.1-250.amzn2027.0.5 |
| SSM Agent | amazon-ssm-agent-3.3.5226.0-1.amzn2027 |
| AWS CLI | awscli-2-2.36.2-1.amzn2027.0.1 |
| bash | bash-5.3.0-2.amzn2027 |
| curl | curl 8.18.0 (linked against OpenSSL 3.5.7 and zlib-ng) |
There were 335 installed packages. The standard AMI does not include a build environment, and no language runtimes other than Python were installed. gcc, binutils, git, perl, ruby, node, java, go, rustc, php, and dotnet were all not installed.
Package management has moved to DNF5. dnf and yum are symbolic links to dnf5.
$ ls -l /usr/bin/dnf /usr/bin/yum /usr/bin/dnf5
lrwxrwxrwx. 1 root root 4 Aug 31 00:00 /usr/bin/dnf -> dnf5
-rwxr-xr-x. 1 root root 1541400 Aug 31 00:00 /usr/bin/dnf5
lrwxrwxrwx. 1 root root 4 Aug 31 00:00 /usr/bin/yum -> dnf5
$ python3 -c "import dnf"
Traceback (most recent call last):
File "<string>", line 1, in <module>
import dnf
ModuleNotFoundError: No module named 'dnf'
Since python3-dnf, the DNF4 Python API, is not installed, importing dnf from Python fails. python3-libdnf5 on the DNF5 side was also not installed by default.
The scope of support during the preview period can be confirmed from dnf subcommands.
$ dnf supportinfo --pkg glibc
Name : glibc
Version : 2.44-2.amzn2027.0.2
State : installed
Current Status : Supported
Patch Priority : Full Support
Support Level Description : Full security and bug fix support for all severities
Covered Severities : Low, Medium, Important, Critical
Origin : Amazon Linux 2027 Core
Support Timeline : from 2026-09-03 : supported (Low, Medium, Important, Critical)
: from 2027-03-31 : unsupported
Package Note : Amazon Linux will support this package until the end of the AL2027 public preview period
The display shows unsupported from 2027-03-31 onwards, and the package note also states that the condition is until the end of the public preview period. The kernel also becomes unsupported on the same date, and all rows in the list of installed packages showed the same date and note.
Only one repository was enabled, and all automatic update timers were disabled.
Repository definition and automatic update status
[amazonlinux]
name=Amazon Linux 2027 repository
mirrorlist=https://al2027-repos-$awsregion-7f9a3b4e.s3$dualstack.$awsregion.$awsdomain/core/mirrors/$releasever/$basearch/$mirrorlist
priority=10
enabled=1
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2027
report_instanceid=1
The source and debuginfo repositories are disabled. Version locking is handled by the amazon-linux-repo-s3-2027.0.20260903-0.amzn2027 package, and no releasever variable file is placed.
When checking for updates immediately after launch, no candidates were returned. The AMI and repository versions are in sync. dnf-makecache.timer, systemd-sysupdate.timer, and update-motd.timer, which are related to automatic updates, were all disabled.
Since no build environment is included, you'll need to install the compiler yourself. The gcc installed additionally was version 16.1.1, and the default C standard was C23.
Additional gcc installation and GCC 16 defaults
When checking package information before installation, gcc was 16.1.1-1.amzn2027.0.1 and binutils was 2.46-3.amzn2027.0.1. The installation downloaded 10 packages totaling 62.1 MiB, and in this run it completed in 10.126 seconds.
$ gcc --version
gcc (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1)
$ echo | gcc -dM -E -x c - | grep -E "__STDC_VERSION__|__GNUC__ "
#define __GNUC__ 16
#define __STDC_VERSION__ 202311L
The default target values in the arm64 environment were -mabi=lp64 and -march=armv8.2-a+crypto. Compiling and running a hello world also succeeded, with the output being hello AL2027 16.1.1 20260501 (Red Hat 16.1.1-1).
systemd and SSH
No trace of SysV compatibility mechanisms remained. The systemd-sysv-generator was absent from the list of systemd generators; only the cloud-init generator, SELinux auto-relabeling, various standard systemd generators, and the zram generator were present. The /etc/rc.d directory for runlevels, chkconfig, and service were all not found. Network management had systemd-networkd enabled, while NetworkManager showed as not-found.
The default SSH configuration is structured using drop-ins. Four files were placed in /etc/ssh/sshd_config.d/. 10-amazon-hardening.conf is Amazon's hardening configuration, and 40-redhat-crypto-policies.conf is Red Hat-derived crypto policy integration. 50-cloud-init.conf is for cloud-init, and 50-redhat.conf contains Red Hat default settings.
# /etc/ssh/sshd_config.d/10-amazon-hardening.conf (excluding comment lines)
PermitRootLogin no
X11Forwarding no
GSSAPIAuthentication no
KerberosAuthentication no
IgnoreRhosts yes
HostbasedAuthentication no
RekeyLimit 512M 1h
The comments in 10-amazon-hardening.conf reference AL-PDR "AL2027: Harden SSH and login security defaults" as the reference name. An explanation is also included stating that it is designed to take precedence over subsequent drop-ins by leveraging sshd's behavior of using the first value it encounters.
In the effective configuration, the only enabled authentication method was public key authentication. Root login, password authentication, and keyboard-interactive authentication were all disabled. Reverse DNS lookup was not performed, and the login grace time was 120 seconds. The first three key exchange algorithms were hybrid post-quantum cryptography methods: mlkem768x25519-sha256, mlkem768nistp256-sha256, and mlkem1024nistp384-sha384.
Note that the update-crypto-policies command itself for switching crypto policies is not installed. However, 40-redhat-crypto-policies.conf does Include /etc/crypto-policies/back-ends/opensshserver.config.
I also checked the default target.
$ systemctl get-default
graphical.target
It was graphical.target. The AL2023 difference table in the AL2027 documentation does not mention the default target, and I did not measure the AL2023 side in this article.
Boot time was 43.442 seconds in total, broken down as: firmware 1.578 seconds, loader 2.990 seconds, kernel 247 milliseconds, initrd 6.840 seconds, userspace 31.787 seconds. The unit that took the most time was the EBS volume device unit at 20.170 seconds. There were no errors at boot, and both error-priority journal entries and failed units were zero.
cloud-init reached done status, but the state was degraded.
$ cloud-init status --long
status: done
extended_status: degraded done
boot_status_code: enabled-by-generator
last_update: Thu, 01 Jan 1970 00:00:33 +0000
detail: DataSourceEc2
errors: []
recoverable_errors:
WARNING:
- Failed loading yaml blob. Invalid format at line 7 column 2: "while scanning for the next token found character '%' that cannot start any token in "<unicode string>", line 7, column 2: {% set meta_data = (ds | default( ... ^"
There were no fatal errors, and 4 WARNING entries of the same content were recorded as recoverable warnings (the output above is an excerpt of 1 out of 4). The last update time is displayed as January 1, 1970. Aggregating cloud-init processing time shows a total of 2.438 seconds for one boot record.
After completing the verification, I terminated the instance.
aws ec2 terminate-instances --instance-ids i-xxxxxxxxxxxxxxxxx
I confirmed it went from running through shutting-down to terminated approximately 80 seconds later. The root EBS volume had the delete-on-termination option enabled so it was gone, and searching for volumes associated with the instance returned zero results. The IAM role, VPC, and security group were existing resources, so they remain.
Summary
AL2027, the first major version in four years, has been released as a public preview. It can be launched as an EC2 instance in the Tokyo region, and changes such as the absence of SysV compatibility features and updates to major packages like GCC and the kernel can be verified in development environments and similar settings.
Since it is currently a public preview, it is not suitable for production use, but I look forward to watching how AL2027, the successor to AL2023, continues to develop.
