「Amazon Linux 2027」のパブリックプレビューが遂に開始！次期OSへの備えと注意点

こんにちは。

今年の6月・7月に、Amazon Linux 2（AL2）のサポート終了対策として、AL2023への移行と、その先を見据えた長期ロードマップについて2本の記事を書きました。

後編の記事では、次世代のAmazon Linuxについて「AL2027（仮）」と呼び、

2027年前後に公開される可能性があるため、日々のアップデートを続けながら備えましょう

とお伝えしていました。

そして今回。

ついに、その「AL2027」が正式に姿を現しました。

2026年9月3日、AWSより 「Amazon Linux 2027（AL2027）」のパブリックプレビュー開始 が発表されました。

Amazon Linux 2027 is now available in public preview（AWS公式）

AL2027は、AL2023をベースラインとして、セキュリティ、パフォーマンス、ハードウェアサポート、開発環境などをさらに強化した次世代のAmazon Linuxです。

今回は、このAL2027プレビュー版で何が変わるのか、そして現在AL2023を利用している環境は、これからどう備えていけばよいのかを整理してみます。

Amazon Linux 2027とは？

まず、AL2027はAL2023の後継となる次世代のAmazon Linuxです。

AWSによると、AL2027はAWS上のクラウドネイティブワークロードをターゲットとしており、Webアプリケーション、データベース、コンテナ、AI/ML、大規模インフラなどを想定しています。

今回のパブリックプレビューでは、EC2向けのAMIがx86-64とARM（Graviton）向けに提供されており、コンテナ用のベースイメージもAmazon ECR Public Galleryから利用できます。

ただし、ここは重要です。

現時点ではあくまで「Public Preview」です。

AWSのドキュメントでも、AL2027 Previewは評価・テスト用途を想定しており、本番ワークロードへの利用は推奨されていません。

そのため、今すぐ本番環境をAL2027へ移行するという話ではありません。

AL2027で何が変わる？

ここからは、AL2023を利用しているエンジニアにとって特に気になるポイントを見ていきます。

1. SELinuxが「Enforcing」に

今回、個人的に最も注目している変更がこれです。

AL2023ではSELinuxのデフォルトモードは「Permissive」でした。

一方、AL2027ではSELinuxがデフォルトで「Enforcing」 になります。

Permissiveでは、SELinuxによるアクセス制御違反が発生しても基本的にはログを記録するだけですが、Enforcingでは実際にアクセスが拒否されます。

そのため、

Webサーバーから特定ディレクトリへアクセスする
アプリケーションからファイルを読み書きする
特定のポートを利用する
独自にインストールしたミドルウェアを動かす
独自のサービスやデーモンを起動する

といった処理で、これまで問題なく動いていたものが、AL2027ではSELinuxポリシーによって拒否される可能性があります。

AL2027への移行を考えるのであれば、SELinuxを前提としたアプリケーション・ミドルウェアの検証が重要になりそうです。

AWSもAL2027のプレビューで、SELinux Enforcing環境におけるWebアプリケーションやアプリケーションサーバーの動作確認を推奨しています。

2. Linux Kernel 7.1+

AL2027では、Public Preview時点で Linux Kernel 7.1+ が採用されています。

AL2023ではKernel 6.1がデフォルトでしたが、その後6.12や6.18などのカーネルも利用可能になっています。

AL2027では、さらに新しいカーネルをベースとして、最新ハードウェアへの対応やパフォーマンス、セキュリティ面の改善が進められています。

特にAWSの新しいインスタンスタイプやGravitonなどを積極的に利用している環境では、OSだけでなくカーネルとハードウェアの組み合わせも確認しておきたいところです。

3. AWS-LCとOpenSSL 3.5

暗号化周りも強化されています。

AL2027では、OpenSSL 3.5に加えて、AWSが開発する暗号ライブラリ AWS-LC が提供されます。

AWSによると、AWS-LCは暗号処理のパフォーマンス向上を狙ったもので、特に暗号化処理を多く利用するワークロードでは検証する価値がありそうです。

TLS通信を大量に処理するWebサービスなどでは、今後チェックしておきたいポイントです。

4. DNF5への変更

これも実運用ではかなり重要な変更です。

AL2023ではDNF 4が利用されていますが、AL2027では DNF5 が標準のパッケージ管理ツールになります。

一方で、日常的な操作については、

sudo dnf install package
sudo dnf search package
sudo dnf remove package
sudo dnf upgrade

のように、これまでと大きく変わらない形で利用できます。

また、yum と dnf のコマンドについても互換性が考慮されています。

ただし、

独自のシェルスクリプト
パッケージ管理を利用した自動化
DNFプラグイン
CI/CD
AMI作成処理
Ansibleなどの構成管理

などで、DNF4固有の挙動に依存している場合は注意が必要です。

AWSもDNF5移行時にスクリプトやツールへ影響する変更があることを案内しています。

「dnfコマンドが使えるから問題ない」と考えず、既存の自動化処理まで含めて検証する必要があります。

5. 最新のツールチェーン・言語ランタイム

AL2027では、GCCなどのツールチェーンや、Python、Java、Node.js、PHP、Go、Rustなどの言語ランタイムも新しいバージョンが提供されます。

AL2からAL2023への移行でも、PHPやPythonなどのバージョン差によってアプリケーション側の修正が必要になったケースがありました。

そのため、

OSのバージョンアップ＝OSだけの問題ではない

という点は、AL2027でも変わりません。

アプリケーションが利用している、

PHP
Python
Node.js
Java
Go
Ruby
Rust
GCC / glibc
OpenSSL

などについて、事前に互換性を確認しておくことが重要です。

6. AI/MLワークロードへの対応

AL2027では、AI/MLワークロードへの対応も強化されています。

AWS Neuronドライバーを含むアクセラレータドライバーへの対応が提供され、TrainiumやInferentiaなどのAWSアクセラレータを利用するワークロードも意識されたOSになっています。

今すぐすべてのシステムに関係する話ではありませんが、今後AI/ML基盤をAWS上に構築する場合には、OSレイヤーも選択肢の一つになりそうです。

そして、意外と重要な「CPU要件」

AL2027への移行を考える際には、アプリケーションだけでなくEC2インスタンスタイプそのものにも注意が必要です。

AL2027のx86-64向けバイナリは x86-64-v3 を前提としてビルドされています。

そのため、古い世代のEC2インスタンスタイプの一部ではAL2027を利用できません。

ARMについても、Graviton2以降が対象となり、A1インスタンスはサポートされません。

つまり、

「今AL2023が動いているEC2なら、AL2027もそのまま動くだろう」

とは限りません。

既存環境を棚卸しするときには、

OSだけでなく、EC2インスタンスタイプまで確認する

ことをおすすめします。

AL2023はどうなる？すぐAL2027へ移行すべき？

ここが今回の記事で一番お伝えしたいポイントです。

結論から言うと、

今すぐAL2027へ移行する必要はありません。

AL2023は2029年6月30日までサポートされます。

ただし、サポートには段階があり、標準サポートは2027年6月30日に終了し、その後はメンテナンスフェーズとしてセキュリティアップデートと重要なバグ修正が中心となります。

つまり、ざっくり整理すると以下のイメージです。

OS	状況	今後の対応
Amazon Linux 2	2026/6/30 EOS	まだなら早急に移行
Amazon Linux 2023	2029/6/30までサポート	当面はこちらを安定運用
Amazon Linux 2027	Public Preview	非本番環境で検証開始

AL2については、すでに2026年6月30日にサポート終了を迎えています。AWSも現在はAL2からAL2023への移行を推奨しています。

したがって、

AL2 → AL2023は「今やるべき移行」

一方で、

AL2023 → AL2027は「今から準備しておく移行」

と考えるのがよいでしょう。

今からやっておきたいこと

では、AL2027がPublic Previewになった今、具体的に何をしておけばよいのでしょうか。

1. まずはAL2023への移行を完了する

まだAL2が残っている場合、まず優先すべきなのはAL2023への移行です。

AL2027が出たからといって、

「どうせAL2027が出たなら、AL2023を飛ばして待とう」

と考えるのはおすすめしません。

AL2027はまだPreviewです。

まずは現在の環境をサポート対象であるAL2023へ移行し、そのうえで次のOSへの準備を進めるのが現実的です。

2. AL2027を検証環境で触ってみる

Public Previewの最大のメリットは、GA前に実際のアプリケーションを動かして検証できることです。

AWSではAL2027のPreview AMIを、x86-64およびARM向けに提供しています。また、Amazon ECR Public Galleryからコンテナベースイメージも利用できます。

まずは検証環境を1台作って、

アプリケーション起動
Webサーバー
DB接続
外部API通信
ファイル読み書き
cron / systemd
Docker / containerd
CI/CD
AMI作成
Terraform / CloudFormation / CDK
Ansibleなどの自動化
DNFを利用したスクリプト

などを確認してみるとよいでしょう。

特に優先したいのは、

SELinux Enforcing

と

DNF5

です。

この2つは、既存環境からの移行時にアプリケーションや運用自動化へ影響する可能性があります。

3. 「OSアップデートに強い環境」を作っておく

今回のAL2027登場を見て、改めて重要だと感じるのが、

OSのアップデートを特別なイベントにしない

ことです。

AL2からAL2023への移行では、OSのメジャーバージョンアップに伴って、アプリケーションやミドルウェアの互換性確認が必要になりました。

そして、AL2023からAL2027でも、

SELinux
Kernel
glibc
OpenSSL
DNF
言語ランタイム
コンパイラ
CPU要件

など、さまざまな差分が発生します。

だからこそ、

Infrastructure as Code
AMIの自動ビルド
CI/CD
自動テスト
定期的なOSアップデート
ミドルウェアのバージョン管理

といった仕組みを普段から整えておくことが重要です。

AL2027への移行を見据えたロードマップ

今回のAL2027 Public Previewを踏まえると、今後は次のようなロードマップで考えるとよさそうです。

2026年

AL2 → AL2023を完了

↓

AL2023環境を安定運用

↓

AL2027 Previewを検証環境で試す

↓

2027年

AL2027のGAや仕様変更を確認

↓

アプリケーション・ミドルウェアの互換性検証

↓

本番移行計画を具体化

↓

2027年後半以降

AL2027への段階的な移行を検討

↓

2029年

AL2023 EOS

このように考えておけば、AL2023のサポート終了直前になって慌てて移行する必要はありません。

まとめ

以前の記事で「AL2027（仮）」として書いていた次世代Amazon Linuxが、ついに正式に姿を現しました。

AL2027は、AL2023をベースに、

SELinux Enforcing
Kernel 7.1+
AWS-LC
OpenSSL 3.5
DNF5
最新のツールチェーン・言語ランタイム
AI/ML向けアクセラレータ対応
x86-64-v3など新しいハードウェア要件

といった変更・強化が行われています。

特に、SELinux EnforcingとDNF5は、既存のアプリケーションや運用自動化に影響する可能性があるため、早めに検証しておきたいポイントです。

ただし、現時点ではまだPublic Preview。

「AL2027が出たから、すぐにAL2027へ移行しなければならない」という状況ではありません。

むしろ今重要なのは、

AL2を利用しているなら、まずAL2023への移行を完了する。

そして、

AL2023を利用しているなら、AL2027を少しずつ検証しておく。

この2段階で考えることです。

AL2027はGA前の今だからこそ、実際のアプリケーションを動かして問題点を洗い出せます。

次回のOS移行で慌てないためにも、まずは検証環境からAL2027を触ってみてはいかがでしょうか。

「OSは一度構築したら終わり」ではなく、次のOSへ無理なく移行できる環境を日頃から作っておくこと。

今回のAL2027 Public Previewは、その重要性を改めて考える良いタイミングなのかもしれません。