Amazon Linux 2027 has gone into public preview, so I tried launching it on EC2 to check it out

Amazon Linux 2027 has gone into public preview, so I tried launching it on EC2 to check it out

Amazon Linux 2027, the successor to Amazon Linux 2023, was released as a public preview on September 3, 2026. Since the preview AMI is available in all commercial regions, I launched it as an EC2 instance in the Tokyo region and checked the contents of the OS via Session Manager.
2026.09.04

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.

https://aws.amazon.com/about-aws/whats-new/2026/09/announcing-amazon-linux-2027/

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.

Four al2027 public images displayed in the EC2 console AMI list

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.

Share this article

AWSのお困り事はクラスメソッドへ