2026.09.20 インフラ

Amazon Linux 2027とは｜AL2023との違いとSELinux既定化で詰まる箇所

Amazon Linux 2027とは｜AL2023との違いとSELinux既定化で詰まる箇所

Amazon Linux 2027（AL2027）は、Amazon Linux 2023（AL2023）の後継にあたるAWS製のLinuxディストリビューションです。2026年9月3日にパブリックプレビューとして公開され、全商用リージョンでプレビューAMIが引けるようになりました。目を引くのはSELinuxがenforcingモードで出荷される点ですが、移行計画に効くのはそこだけではありません。カーネルは6.1系から7.1へ、GCCは11.5から16.1へ、dnfコマンドの実体はDNF5へ入れ替わり、cronやkshやSystem V initスクリプトは消えます。この記事では、AL2023との差分、SELinuxの切り替え手順、プレビューAMIの起動コマンド、CPU要件で弾かれるインスタンス、移行前に棚卸しすべき削除済み機能を公式ドキュメントで押さえます。

まとめ：AL2027を本番に入れない判断とプレビューで先に潰す3点

結論から書くと、いまAL2027を本番ワークロードに載せる理由はありません。公式ドキュメントが「評価とテスト専用で本番ワークロードには推奨しない」と明記しており、プレビューのインスタンスは既定で重要なセキュリティ更新すら自動受信しないためです。AL2023のサポートは2029年6月30日まで続くので、慌てて移す必要もありません。

一方で、プレビューのうちに潰す価値がある確認は3つあります。第1にSELinuxのenforcing既定で、AL2023では警告だけ出て通っていた処理が拒否へ変わること。第2にx86-64-v3というCPU要件で、c1・c3・i2・m1・m2・m3・r3・t1といった旧世代インスタンスが起動しないこと。第3にDNF5への入れ替えとSystem V initスクリプトの削除で、自作のプロビジョニングスクリプトが書き換え対象になることです。

この3点はGAを待ってから着手すると移行期間を食い潰します。プレビューAMIを1台立てて既存のミドルウェア構成を流し、拒否ログとパッケージ管理の差分だけ先に洗い出す。数日で終わる作業量です。

Amazon Linux 2027がパブリックプレビューで公開された範囲と時期

AL2027はAL2023の系譜を継ぐ次世代のAmazon Linuxで、追加料金なしで提供されます。AL2023のリリースが2023年3月なので、約3年半ぶりのメジャー更新です。

2026年9月3日の公開とAMI・コンテナイメージの提供形態

公開はAWSのWhat’s Newに「Posted on: Sep 3, 2026」として掲載されました。この発表によると、プレビューAMIは全商用リージョンのコンソールから引け、x86-64とArmの両方が用意されています。コンテナのベースイメージはAmazon ECR Public Galleryで配布され、オンプレミス向けVMイメージ（Hyper-V・KVM・VMware）は初期プレビューに含まれません。

押さえておく前提が1つあります。AL2027のインスタンスは、既定では重要度の高いセキュリティ更新を含めて自動更新を一切受け取りません。更新はdnf updateを手で回す運用です。

移行の締め切りはAL2023の標準サポート終了2027年6月30日

移行時期を決めるのはAL2027側ではなくAL2023側の日付です。AL2023のリリースサイクルには、四半期ごとのマイナー更新が入る標準サポートが2027年6月30日に終わり、セキュリティ更新と重大なバグ修正だけのメンテナンスフェーズが2029年6月30日で終了するとあります。AL2027側は2032年までサポートされると明記され、GA日は未公表です。

ここから逆算すると、新機能が載らなくなる2027年7月が現実的な境界になります。2027年前半までに動くシステムの新規構築ならAL2023のままで足り、2027年後半以降も改修が続く案件はGAを待って移行枠を確保しておく。プレビューでの検証は、その移行枠の見積もりを取る作業だと位置づけます。個別パッケージのサポート期限は次のコマンドで引けます。

$ sudo dnf supportinfo --pkg {{packagename}}

# 導入済みパッケージをまとめて確認する
$ sudo dnf supportinfo --show installed

ただしプレビュー期間中は、返る期限がプレビュー終了時点までしか出ません。

AL2023からAL2027で入れ替わるコンポーネントの版と影響

AL2027はAL2023を土台に組み直したもので、上流はFedoraです。公式の比較表に主要コンポーネントの版差分が並んでおり、移行の当たりを付けるならここが出発点になります。

カーネル7.1・GCC 16.1・glibc 2.44という土台の入れ替え

カーネルはAL2023の既定6.1から7.1へ上がります。パッケージ名はkernel7.1のように版番号付きで、新しい版が後から追加される運用はAL2023と同じです。どの層の話をしているかを整理したい場合はカーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】を先に読んでください。

ツールチェーンの跳び幅はさらに大きく、GCCは11.5から16.1、glibcは2.34から2.44、binutilsは2.41から2.46へ。LLVM/Clangは15・18・19の個別SRPMから22の統合SRPMへまとまりました。公式は「AL2023でコンパイルしたコードは概ねAL2027でも動くが、再コンパイルするとGCC 16の厳しくなった既定で新しい警告やエラーが出る可能性がある」としています。systemdは252から260へ上がり、この更新でSystem V サービススクリプトのサポートが落ちました。ほかにRPMが4.16から6.0、Pythonの既定が3.9から3.14、zlibがzlib-ng 2.3への置き換え。自社でRPMを作っているなら、specファイルを新しいRPMで通す試験が要ります。

dnfとyumの実体がDNF5になりpython3-dnfが使えなくなる

パッケージ管理はDNF 4.14からDNF5 5.4へ入れ替わります。dnfもyumもDNF5を呼び、よく使う書き方は互換エイリアスで動き続けるため、手で叩く分にはほとんど意識しません。

問題はPython APIのほうです。DNF 4のPython API（python3-dnf）は提供されず、python3-libdnf5のバインディングへ移植が要ります。パッケージの導入状況を自前のPythonスクリプトで点検している構成管理は、ここが確実に壊れます。AnsibleやChef越しに入れているだけなら影響は小さいものの、独自スクリプトでimport dnfしている箇所は全数洗い出しの対象です。rpmデータベースもBerkeley DB形式の読み取り専用サポートが外れてSQLite形式のみになりました。

暗号ライブラリまわりも動きます。AL2027はAWS-LCを新たに同梱しますが、OpenSSLの置き換えではありません。既定はOpenSSL 3.5のままで、httpd・haproxy・libpq・python3.14などがAWS-LC側にリンクし、nginxはnginx-awslcという別ビルドが用意されました。両者には双方向の機能差があるため、自前アプリをリンクし直すかは使っている暗号APIを確かめてからの判断。npmとpipの依存クールダウンが既定で有効になった点もあわせて押さえます。公開直後のパッケージの導入を遅らせる仕組みのため、内部パッケージを即座に取り込むCIは待たされることがあります。

SELinuxがenforcing既定になって止まる処理と切り分け手順

AL2027で最も広く影響する変更がこれです。公式ドキュメントのとおり、AL2023はpermissive（違反をログに残すだけ）、AL2027はenforcing（違反を実際に拒否する）が既定になりました。AL2023で警告が出ているだけの状態を放置して移行すると、ファイルコンテキスト・ポート・アクセスパターンがポリシーと合わない処理はそのまま失敗します。

getenforceとsestatusで現在のモードと読み込み済みポリシーを見る

最初にやるのは現状確認です。getenforceは現在のモードだけを返し、sestatusはステータスとポリシー名まで出します。公式に載っている出力例は次のとおりです。

$ 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

読み込まれるポリシーはtargetedで、対象として定義されたデーモンに限って閉じ込める方式です。詰まりやすいのは、Webサーバーが標準外のディレクトリを読む構成、標準外のポートで待ち受ける構成、ミドルウェアが自前でソケットファイルを置く構成の3つ。なおpermissiveでは新しく作られるファイルに誤ったラベルが付くことがあり、enforcingへ戻すとSELinuxが自動で再ラベルを走らせるため、モードを往復させた直後は起動時間が延びます。

permissiveへ一時的に落とす2つの方法と再起動の要否

移行作業の途中で拒否を止めたい場面は必ず来ます。公式が示す方法は2つで、/etc/selinux/configを書き換えて再起動するか、起動時にcloud-configをユーザーデータで渡すかです。手順のページには次のように書かれています。

# 方法1: 設定ファイルを書き換えて再起動する
$ sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
$ sudo reboot

# 方法2: 起動時のユーザーデータで指定する（cloud-config）
#cloud-config
selinux:
  mode: permissive

cloud-configで指定した場合、既定ではインスタンスが再起動します。selinux_no_reboot: 1で省けるものの、安定性のために再起動する運用が公式の推奨。検証機を繰り返し作り直すなら、ユーザーデータで指定するほうが手数が減ります。

判断を1つ言い切っておきます。permissiveへ落としたまま本番へ持っていく選択は取るべきではありません。enforcingを既定にした狙いはセキュリティ境界の引き上げで、permissive運用はAL2023と同じ状態に戻すだけです。落とすのは移行作業中の一時措置と割り切り、拒否ログを潰し終えたらenforcingへ戻す。この線を先に決めないと、期限のない「暫定permissive」が残ります。

enforcingのまま通すならAVCログから不足ルールを特定する

permissiveモードの価値は、拒否せずにAVCメッセージだけを出す点にあります。一度ワークロードを流し切れば、enforcingで引っかかる箇所が先にログへ出そろうわけです。監査ログから拒否イベントを拾う流れは次のとおり。

# 直近の拒否イベントを人が読める形で一覧する
$ sudo ausearch -m AVC,USER_AVC -ts recent -i

# 拒否イベントから不足しているルールを生成して確認する
$ sudo ausearch -m AVC -ts recent | audit2allow -m myapp

# 標準外のポートで待ち受けるときはポートのラベルを追加する
$ sudo semanage port -a -t http_port_t -p tcp 8081

# 標準外のディレクトリを既定のコンテキストへ戻す
$ sudo restorecon -Rv /srv/myapp

audit2allowの出力をそのまま適用するのは早計です。生成されるのは「拒否されたアクセスを全部許す」内容なので、まずファイルコンテキストの付け直し（restorecon）とポートラベルの追加（semanage port）を試し、残る分だけカスタムポリシーとして固める。検証の初回にpermissiveで業務相当の処理を流してenforcingへ戻すループを1周回せば、GA後の移行工数がほぼ見積もれます。

プレビューAMIをEC2で起動してAL2027の挙動を確かめる手順

検証環境は使い捨てのEC2インスタンスで足ります。インスタンスタイプの選び方や料金モデルはAmazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説に譲り、ここではAL2027固有の起動手順とCPU要件に絞ります。

SSMパブリックパラメータでAMIを解決してrun-instancesに渡す

コンソールから探すなら、AMI一覧をパブリックイメージに絞ってal2027-preview-amiで検索し、所有者エイリアスがamazonであることを確認します。CLIからは公式手順のとおりSSMパブリックパラメータでAMI IDを解決させます。

$ aws ec2 run-instances \
  --image-id \
    resolve:ssm:/aws/service/ami-amazon-linux-latest/al2027-preview-ami-kernel-default-x86_64 \
  --instance-type {{m5.xlarge}} \
  --region {{us-east-1}} \
  --key-name {{my-key-pair}} \
  --security-group-ids {{sg-004a7650}}

# arm64 と最小AMIを使う場合のパラメータ名
#   al2027-preview-ami-kernel-default-arm64
#   al2027-preview-ami-minimal-kernel-default-x86_64
#   al2027-preview-ami-minimal-kernel-default-arm64

resolve:ssm:という接頭辞が、起動時点で最新のAMI IDへ解決させる指定です。プレビュー中はAMIが頻繁に差し替わるため、IDを固定するよりこの書き方が扱いやすくなります。接続先の既定ユーザーはAL2023と同じec2-user。セキュリティグループを省くと既定のものに入るので、SSH（TCP:22）を通す指定は明示します。

x86-64-v3要件で起動できない世代のインスタンスタイプ

AL2027はCPUの下限が上がりました。システム要件によると、x86-64のバイナリはすべて-march=x86-64-v3でビルドされます。x86-64-v3はv2のベースラインに加えてAVX・AVX2・BMI1・BMI2・F16C・FMA・LZCNT・MOVBE・XSAVEを要求し、おおよそ2015年以降のプロセッサ（IntelのHaswell、AMDのExcavator以降）に相当します。

この結果、c1・c3・i2・m1・m2・m3・r3・t1ではAL2027が起動しません。Arm側も条件があり、Graviton2以降のプロセッサが必要でa1インスタンスは対象外。要件を満たさないCPUでは実行のごく初期に不正命令エラーが出ます。32bit x86（i686）も完全に対象外です。メモリの下限は512MBで、800MB未満のインスタンスではzramによるスワップが既定で有効になります。コンテナで動かす場合も同じCPU要件が適用される点に注意が要ります。

AL2023から削除された機能を移行前に棚卸しするチェックリスト

移行で足を取られるのは、AL2023の時点で非推奨扱いだった機能です。公式の一覧には「AL2023で非推奨になった機能のほとんどはAL2027のプレビュー時点で削除済み」とあり、残りもGA前に消える予定。順番に潰します。

cron・ksh・System V initスクリプト・cgroup v1の置き換え先

まずジョブスケジューラです。cronieパッケージはAL2023の時点で既定導入から外れていました。AWSはsystemdタイマーへの移行を推奨し、将来のAmazon Linuxでは従来のcronジョブのサポート自体がなくなる可能性があると明記しています。運用スクリプトがcrontabに並ぶ環境は、この機会にユニットファイル化を検討する対象です。

シェルとinitまわりではkshが削除されるため、kshで書かれたスクリプトはbashへ移植が要ります。System V initスクリプトはsystemd 260がサポートを落として動かなくなり、ネイティブのsystemdユニットファイルへ書き換える。古いミドルウェアのインストーラが/etc/init.d/にスクリプトを置く作りだと、ここで確実に止まります。コンテナ基盤を自前で組んでいる場合はcgroupの版も確認対象です。systemd v258でcgroup v1が削除され、AL2027はv2のみのサポートになりました。レガシーのv1階層を読むツール（監視エージェントや自作のリソース制限スクリプト）はv2のインターフェースへ移します。

libdb・pcre1・32bitバイナリに依存した社内資産の洗い出し

ライブラリ側の削除も棚卸しの対象です。Berkeley DB（libdb）はAL2023が積んでいた5.3.28がライセンス変更前の最後の版で、AL2027では削除。PCREは版1が消えてPCRE2のみになるため、PCRE1にリンクした社内ビルドのツールは作り直しです。同じくaspell（後継はhunspellかenchant2）とopensmtpd（後継はpostfixかsendmail）が消え、ftpクライアントはAL2023の時点で削除されたまま復活しません。

洗い出しの実務は、稼働中のAL2023インスタンスで削除対象パッケージの導入有無を機械的に確認するところから始めます。パッケージ構成の前提を揃えたい場合はLinuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説【2026年版】を先に読んでください。

# 削除対象パッケージが入っていないかを稼働中のAL2023で確認する
$ rpm -qa --qf '%{NAME}\n' | grep -E '^(cronie|ksh|libdb|pcre|aspell|opensmtpd)$'

# System V init スクリプトの残骸を探す
$ ls -1 /etc/init.d/ 2>/dev/null

# dnf の Python API に依存した自作スクリプトを探す
$ grep -rl 'import dnf' /opt /usr/local/bin 2>/dev/null

プレビュー期間の制約から引くAL2027の採用条件と見送る場面

最後に、プレビュー版として明示されている制約から採用判断の線を引きます。既知の問題のページの内容は、検証計画そのものを左右します。

SSM Patch ManagerとNVIDIAドライバが使えない期間の運用

公式が挙げている制約は4つです。NVIDIAドライバが初期プレビューに含まれない、オンプレミス向けVMイメージが提供されない、SSM Patch Managerによるパッチ適用が成功しない、Attestable Image Examplesのレシピが未対応の4点。

運用面で効くのはSSM Patch Managerです。パッチ適用をPatch Managerに寄せている組織では、AL2027のインスタンスだけが管理の枠外へ落ちる。更新はdnf updateを手で回す形になるため、検証機でも当て漏れが起きやすくなります。脆弱性を機械的に拾う側を先に整えたい場合は、Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断で検出の仕組みを確認しておくと穴を埋められます。GPUを使う機械学習のワークロードは、NVIDIAドライバが入るまで検証そのものが始まりません。発表ではAWS Neuronドライバのサポートが入るとされているため、Inferentia・Trainium側の検証は先に着手できます。不具合の報告やパッケージの要望はGitHubのamazon-linux-2027リポジトリのissueで受け付けられており、プレビュー期間はここが実質の窓口です。

いま検証に着手する案件と、AL2023のまま進める案件の線引き

判断は3つに分かれます。第1に、いま検証に着手すべきなのは、2027年後半以降も改修と運用が続く基幹寄りのシステムで、かつSELinuxのポリシー調整が要りそうな構成（標準外パスで動くWebサーバー、独自ポートのアプリ、自前のソケット配置）を持つ案件。移行工数が読めないため、プレビューで実測する価値が工数を上回ります。

第2に、AL2023のまま進めてよいのは、2027年前半までに納品が終わり以後の改修予定がない案件。メンテナンスは2029年6月30日まで続きます。第3に、見送りではなく「待ち」に置くのが、GPUインスタンスを使う案件とオンプレミスのハイパーバイザーで同じイメージを回す案件です。前提となる提供物が揃っておらず、いま時間を使っても判断材料が増えません。

注意点が1つあります。AL2027にはAL2023からのインプレース移行の手段がありません。新しいインスタンスを立てて構成を作り直す形になるため、構成管理コードがどこまで自動化されているかで工数が大きく変わります。IaCで環境が再現できる状態なら検証は数日、手作業で積み上げたサーバーなら棚卸しだけで数週間。EC2上のLinux基盤の設計やAL2023からの移行を外部に出す前提で見積もりたい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応範囲を確認してください。

よくある質問

Amazon Linux 2027は本番環境で使えますか？

現時点では使えません。公式ドキュメントが評価とテスト専用と明記しています。プレビューのインスタンスは既定で自動更新を受け取らず、SSM Patch Managerによるパッチ適用も成功しません。本番でAWSのサポートが必要なワークロードは、一般提供までAL2023で運用します。

AL2023からAL2027へインプレースで移行できますか？

できません。インプレースの移行経路は提供されておらず、AL2027のAMIから新しいインスタンスを起動して構成を作り直す形になります。リポジトリのバージョンを向け直して稼働中インスタンスへ更新を当てる運用はAL2027内の話で、AL2023からの移行には使えません。

SELinuxをenforcingのままにしないと動きませんか？

permissiveへ落とすことも無効にすることも可能です。/etc/selinux/configのSELINUX値を書き換えて再起動するか、起動時のユーザーデータにcloud-configでselinux: mode: permissiveを渡します。ただしpermissive運用はAL2023と同じ状態に戻すだけで、移行作業中の一時措置です。

AL2023はいつまでサポートされますか？

2029年6月30日までです。四半期ごとのマイナー更新が入る標準サポートは2027年6月30日で終わり、以降はセキュリティ更新と重大なバグ修正だけになります。AL2027側は2032年までのサポートが公表されているものの、一般提供の日付はまだ出ていません。

古いインスタンスタイプでAL2027は動きますか？

動かないものがあります。x86-64ではx86-64-v3世代以降のプロセッサが必要で、c1・c3・i2・m1・m2・m3・r3・t1はサポート対象外。ArmではGraviton2以降が必要で、a1インスタンスは動きません。旧世代が残る環境では、AL2027への移行とインスタンスタイプの更新を同じ計画に載せます。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る