AWSは2026年9月3日、Amazon Linux 2027 (AL2027) パブリックプレビューを発表しました。Amazon Linuxは、EC2やコンテナのようにAWS上で実行されるワークロードのためにAWSが直接構築・維持するLinuxディストリビューションです。今回の発表の核心は、名前の年が変わったことだけではありません。セキュリティのデフォルト設定、CPUベースライン、パッケージマネージャー、開発ツールチェーンが一斉に現代化されました。
ただし、今すぐダウンロードできるという事実と、運用環境に投入してもよいという意味は異なります。AWSは現在のバージョンを評価とテスト用のプレビューとして明記しており、本番環境での使用は推奨していません。今すべきことは、サーバーをすぐに交換することではなく、AL2023ワークロードが新しいデフォルト設定でどこで問題を起こすかを非運用環境で事前に見つけることです。
現代的なAWSクラウドサーバー基盤の上にセキュリティシールドと2種類のCPUパスが配置されたAmazon Linux 2027への移行シーン
発表で確認された主要な変更点
AL2027はAL2023の基盤を引き継ぎますが、Linuxカーネル7.1以上、SELinux enforcingデフォルト、DNF5、OpenSSL 3.5とAWS-LC、最新の言語ランタイムとコンパイラを提供します。x86-64とArm64 AMIはすべての商用AWSリージョンでプレビューとして提供され、コンテナベースイメージはAmazon ECR Publicから入手できます。
| 項目 | AL2023で慣れ親しんだ基準 | AL2027プレビューでの変更 | まず確認すべきこと |
| — | — | — | — |
| SELinux | デフォルト permissive | デフォルト enforcing | アプリケーション・エージェントのAVC denial |
| パッケージ管理 | DNFベース | DNF5 | 自動化スクリプトとプラグインの互換性 |
| x86ベースライン | x86-64-v2 | x86-64-v3 | 古いインスタンス・オンプレミスCPU |
| Armベースライン | 64ビットArm | ARMv8.2+crypto, Graviton2以上 | A1と旧型ボードの除外有無 |
| 暗号化 | 既存のシステムポリシー | PQCデフォルト有効化, OpenSSL 3.5, AWS-LC | TLS・SSH相互運用性 |
| 開発ツール | GCC 11系デフォルト | GCC 16.1, LLVM/Clang 22 | 警告・コンパイルエラーと言語標準の変化 |
AWS製品ページにはGCC 16.2という表記も見られますが、現在の詳細なユーザーガイドとパッケージドキュメントはGCC 16.1を基準に説明しています。プレビュー期間中はパッケージと構成が変わる可能性があるため、実際のAMIでgcc --versionとリリースノートを一緒に確認する方が安全です。
最大の運用上の変更はSELinux enforcingです
AL2023はSELinuxがポリシー違反を記録するもののブロックしないpermissiveがデフォルトでした。AL2027はenforcingがデフォルトであるため、ポリシーで許可されていないファイルアクセス、ポートバインディング、プロセス動作が実際にブロックされます。セキュリティの観点からはより安全な出発点ですが、これまでpermissiveログを無視していたアプリケーションは、起動後に正常に見えても特定の機能で失敗する可能性があります。
プレビューインスタンスではまず以下を確認します。
cat /etc/os-release
getenforce
sudo ausearch -m AVC,USER_AVC -ts recent
sudo journalctl -t setroubleshoot --since todayブロックが発生したからといってすぐにSELinuxを無効にするのは、良い移行テストではありません。サービスが実際に必要とするアクセスであるかを確認し、ファイルコンテキスト・Boolean・ポリシーモジュールの中で最も狭い方法で許可する必要があります。
x86-64-v3は性能の機会であり、互換性の境界です
AL2027のx86-64パッケージは、AVX、AVX2、BMI1・2、FMAなどの機能を含むx86-64-v3基準でビルドされます。おおよそ2015年以降のCPUに対応しますが、すべての古いEC2タイプやオンプレミス仮想化ホストが条件を満たすわけではありません。条件に合わない場合、アプリケーションエラーではなく、起動初期にillegal instructionで失敗する可能性があります。
Arm64はARMv8.2とCryptography Extensionを要求し、AWSではGraviton2以上をサポートします。A1インスタンスとRaspberry Pi 5以前のモデルは対象ではありません。AMIを交換する前に、現在のインスタンスタイプとカスタムイメージビルドマシンのCPU機能をまず検査する必要があります。
量子耐性暗号とSSH強化がデフォルトで導入されます
AL2027はシステム暗号化ポリシーでPost-Quantum Cryptography(PQC)をデフォルトで有効にします。OpenSSHはPQC鍵交換を使用し、OpenSSL 3.5・GnuTLS・NSSにはML-KEMハイブリッド鍵交換と新しい署名アルゴリズムのサポートが含まれます。これは既存のRSA・ECDSA証明書がすぐに使えなくなるという意味ではありません。実際の点検対象は、古いTLS機器、プロキシ、ライブラリ、SSHクライアントが新しいネゴシエーションの組み合わせを適切に処理できるかです。
OpenSSH 9.9p1の強化設定も確認する必要があります。DSAはもはやサポートされず、2048ビットより短いRSA鍵はデフォルトで許可されません。古い自動化アカウントや機器がDSA鍵や短いRSA鍵を使用している場合、AL2027への移行前にEd25519、ECDSA、または十分な長さのRSA鍵に交換する必要があります。
開発環境とイメージパイプラインも再度テストする必要があります
DNF5は既存のDNFの単純なバージョン変更ではなく、新しい実装です。一般的なインストールコマンドは慣れていますが、出力解析、プラグイン、キャッシュ、自動化動作が異なる可能性があります。Packer、EC2 Image Builder、cloud-init、ブートストラップスクリプトがdnfの出力や内部ディレクトリに依存している場合、テストが必要です。
コンパイラのデフォルト値も変更されます。GCC 16.1はC23とC++20をデフォルト標準として使用します。AL2023で静かに通過していたソースが新しい警告やエラーを出す可能性があるため、ビルドが失敗したからといってパッケージだけを固定するのではなく、コードと-std=オプションを明示的に検討する方が良いでしょう。
AI・MLワークロードにはTrainiumとInferentiaのためのAWS Neuronドライバーサポートが含まれます。しかし、NVIDIA CUDAや特定のフレームワークの組み合わせまで自動的に互換性があるという意味ではありません。使用するアクセラレータ、カーネルモジュール、コンテナランタイム、フレームワークのバージョンを個別のマトリックスで検証する必要があります。
今できる安全なプレビュー検証
プレビューAMIはAWSコンソール、CLI、SSM公開パラメータを通じて見つけることができます。正確なパラメータとAMI IDはリージョンとリリースによって変わる可能性があるため、ドキュメントの最新値を使用します。運用アカウントではなく、別途サンドボックスアカウントや隔離されたVPCで開始し、実際のデータや長期資格情報を入れないでください。
検証順序は単純に設定できます。まず、同じアプリケーションをAL2023とAL2027にそれぞれデプロイします。起動、パッケージインストール、サービス開始、正常なリクエストを比較します。次に、SELinux denial、SSH接続、TLS連携、ログ・モニタリングエージェント、バックアップを確認します。最後に、AMIビルドとロールバックを自動化し、既存の運用環境に影響を与えないか検証します。
uname -r
rpm -E '%{fedora}' 2>/dev/null || true
dnf --version
openssl version
ssh -V
gcc --versionプレビュー結果には、使用したAMI ID、リージョン、アーキテクチャ、リリースバージョンを必ず残します。プレビューがアップデートされたら、同じテストを再度実行して結果を比較できるようにします。
GAまでの判断基準
AWSはAL2027がGAになった後、5年間の標準サポートを提供する計画だと発表しました。また、GA時点で最新のLTSカーネルを提供し、その後毎年新しいカーネルをリリースし、各カーネルを4年間サポートする方向性を説明しています。しかし、GAの日付と最終的なパッケージ構成が確定したと解釈すべきではありません。2026年11月に案内されたプレビュー第2段階では、SPALパッケージ、DCVサポート、EKS最適化AMIレシピが追加される予定です。
今AL2027を見る最も現実的な観点は、「新しいOSにすぐに切り替えるべきか？」ではなく、「私たちのシステムは2027年型のセキュリティデフォルトを受け入れる準備ができているか？」です。特にSELinux enforcing、CPUベースライン、DNF5、SSH、暗号化ポリシーはアプリケーションコードの外で障害を引き起こす可能性があります。プレビュー期間中にこれら4つの境界を自動テストに組み込んでおけば、GA後の移行ははるかに予測可能になります。
コメントを残す