Amazon Linux 2027とは｜AL2023との違いとGA時期・プレビュー更新で変わった点【2026年10月】

Amazon Linux 2027（AL2027）は、Amazon Linux 2023（AL2023）の後継にあたるAWS製のLinuxディストリビューションです。2026年9月3日にパブリックプレビューが始まり、10月12日までに3回の更新版が出ました。この間に既定カーネルは7.1から7.2へ上がり、NVIDIAドライバとオンプレミス向けVMイメージが加わり、カーネル版を名前に含むSSMパラメータは10月31日の削除が告知されています。公開直後の情報で立てた計画は、前提の見直しが要ります。この記事では、AL2023との違い、GAまでの日程、SELinux enforcingの切り分け、版固定リポジトリでの更新、削除済み機能の棚卸しを、公式資料と公式コンテナイメージでの実測（2026年10月21日）で確かめます。

まとめ：AL2027は本番に入れず、プレビューで先に潰す4点

いまAL2027を本番ワークロードに載せる理由はありません。AWSの製品ページのFAQによると、プレビューはAWSサポートの対象外で、期間は2027年初頭まで。GAの時点でプレビューAMIは非推奨になり、検証用のインスタンスも含めてGA版のAMIへ置き換えるよう求められています。AL2023は2029年6月30日まで使えるので、急いで移す必要もありません。

プレビューのうちに潰す価値がある確認は4つです。

• SELinuxのenforcing既定：AL2023では警告だけで通っていた処理が拒否される
• CPU要件x86-64-v3：c1・c3・i2・m1・m2・m3・r3・t1とa1では起動しない
• DNF5とSystem V initの削除：import dnfする自作スクリプトと/etc/init.d/の起動スクリプトが動かない
• 版固定リポジトリ：dnf upgradeだけでは新しいAL2027リリースへ進まず、--releaseverの指定が要る

AWSは2027年1月を過ぎて報告された問題はGAまでに直らない可能性があるとしているので、検証機での洗い出しは2026年中に済ませます。

Amazon Linux 2027のプレビュー公開とGAまでの日程

OSの利用料はかからず、AL2023（2023年3月リリース）から約3年半ぶりのメジャー更新です。

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

公開はAWSのWhat’s Newに2026年9月3日付で載りました。プレビューAMIは全商用リージョンでx86-64とArmの両方が引け、コンテナのベースイメージはAmazon ECR Public Galleryに2027タグで置かれています。初回では見送られたオンプレミス向けVMイメージは、9月28日の更新でVMware OVA・KVM/QEMU qcow2・Hyper-V VHDx・raw形式の配布が始まりました。

サポート期間はユーザーガイドのリリースサイクルに2032年までと書かれ、製品ページはGA後に5年の標準サポートを提供するとしています。

GA日付の発表状況と2027年初頭までのプレビュー予定

GAの日付は2026年10月21日時点で発表されていません。製品ページのFAQから読み取れる日程は次のとおりです。

プレビュー中のCVE修正と不具合修正は隔週で出ます。コンテナにdnf-plugin-support-infoを追加し、dnf supportinfo --pkg glibcでサポート期限を確認すると、プレビュー中はglibcも含めて2027年3月31日でunsupportedと表示されました（2027.0.20261012のコンテナで確認）。GA版のサポート期限はGA時に公開されます。

AL2023の標準サポート終了日と移行時期の決め方

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

AL2023のメンテナンスサポート終了日は2029年6月30日で、標準サポート終了日は2027年6月30日です。個別パッケージのサポートが先に終わる場合もあります。AL2023を使い続けるかは、必要なパッケージのサポート期限と運用終了予定で決め、2029年6月30日を超えて運用する案件は、それまでに移行を終える枠を確保しておきます。まだAmazon Linux 2が残っている環境は、AL2027を待たずにAL2023へ移すのが先で、手順はAmazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所にまとめました。

公開後のプレビュー更新で変わった点（9月14日〜10月12日）

プレビューは「出たときのまま」ではありません。リリースノートには2027.0.20260903の後に0914・0928・1012の3版が並び、検証計画に効く変更は0928と1012に集中しています。

既定カーネル7.2への更新とモジュールのzstd圧縮

2027.0.20260928から、既定AMIのカーネルは7.2系（kernel7.2-7.2.4）になりました。1012版ではkernel7.2-7.2.8-7.108まで進んでいます。ユーザーガイドの比較表はまだ「7.1」のままなので、版はリリースノート側で確かめてください。製品ページのFAQは、GA時点の最新LTSカーネルで出荷し、以後は毎年新しいカーネルを追加して各4年サポートするとしています。

同じ0928版で、カーネルモジュールは非圧縮の.koからzstd圧縮の.ko.zstに変わりました。/lib/modules配下の.koを直接insmodするスクリプトや、拡張子で探す監視・セキュリティエージェントは見つけられなくなります。公式はmodprobeのような圧縮形式に依存しない手段へ寄せるよう勧めています。

kernel.yama.ptrace_scopeの既定も1になり、通常のアタッチ先は子孫プロセスに制限されます。ただし、CAP_SYS_PTRACEを持つ場合や、対象がPR_SET_PTRACERで許可した場合などは例外です。gdb -pやstrace -pで動作中のプロセスにアタッチする場合も、まず現在の権限で実行できるか確認します。ホスト全体で制限を緩和する必要がある検証環境では、elfutils-yama-ptrace-enableの導入を検討します。0928版のリリースノートには、systemtapがカーネル7.2で動かず次版の5.6で直すとありますが、1012版のリポジトリでもsystemtapは5.5のままでした。systemtapを使う検証はカーネル7.1に留めます。

NVIDIAドライバの提供開始とP4d・P5・P6が使えない理由

初回プレビューに無かったNVIDIAドライバは、0928版からAWSが管理する専用リポジトリで配られています。NVIDIAドライバのページによると、AL2023の単一リポジトリからドライバのメジャー版ごとのリポジトリ（580＝LTSブランチ、595＝プロダクションブランチ）とCUDA Toolkit用のリポジトリへ分かれ、対象はx86_64のみです。

# 提供されている登録パッケージを確認する（2027.0.20261012で実行）
$ dnf list --available "nvidia-release-driver-*"
nvidia-release-driver-580.noarch    2027-1.amzn2027 amazonlinux
nvidia-release-driver-595.noarch    2027-1.amzn2027 amazonlinux
nvidia-release-driver-latest.noarch 2027-1.amzn2027 amazonlinux
nvidia-release-driver-lts.noarch    2027-1.amzn2027 amazonlinux
nvidia-release-driver-prod.noarch   2027-1.amzn2027 amazonlinux

# プロダクションブランチを追う場合
$ sudo dnf install nvidia-release-driver-prod -y
$ sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y
$ sudo dnf install nvidia-driver-cuda -y
$ sudo reboot

# 再起動後に再接続して確認する
$ nvidia-smi

ただし、複数GPUをNVSwitchでつなぐためのFabric Manager（nvidia-fabricmanager）はまだ無く、P4d・P5・P6のようにFabric Managerを必要とするGPUインスタンスは、プレビューではサポート対象外です。NVIDIA Container ToolkitとDCGMも未提供です。GPU検証はシングルGPU系のインスタンスで、コンテナを介さない構成から始めることになります。なおNVIDIAリポジトリはメタデータ署名に未対応なので、repo_gpgcheck=1を設定するとリポジトリを読み込めません。

既知の問題のページは、NVIDIAドライバとVMイメージについて初回プレビューでは未提供と説明し、更新状況はリリースノートを参照するよう案内しています（2026年10月21日時点）。プレビュー中は対象リリースを確認し、ユーザーガイドとリリースノートを突き合わせて提供状況を判断します。

kernel-7.x指定のSSMパラメータは10月31日に削除

2027.0.20261012のリリースノートには、プレビュー中にサポートするSSMパラメータはkernel-defaultの系統だけで、kernel-7.1やkernel-7.2を含む名前は2026年10月31日に削除すると書かれています。カーネル版付きのパラメータはGA時に改めて用意されます。

al2027-preview-ami-kernel-7.1-x86_64のような名前をTerraformやCloudFormationに書いた検証環境は、11月以降AMIを解決できません。grep -r "al2027-preview-ami.*kernel-7"でIaCを洗い、kernel-defaultへ置き換えます。

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

AL2027は上流のFedoraを土台に組み直したものです。公式の比較表と、2026年10月21日に公式コンテナイメージ（2027.0.20261012）で確かめた版を並べます。

カーネルの位置づけを整理したい場合はカーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】を先に読んでください。

GCC 16とRPM 6.0で自社ビルドが通らなくなる箇所

公式は、AL2023でコンパイルしたコードは概ね動くものの、GCC 16で再コンパイルすると厳しくなった既定で新しい警告やエラーが出うるとしています。LLVM/Clangは22の統合SRPMにまとまり、zlibはzlib-ng 2.3の互換パッケージに替わりました。自社でRPMを作っているならspecファイルをRPM 6.0で通す試験が要り、rpmデータベースはSQLite形式だけになります。

dnf・yumのDNF5移行とpython3-dnfの非提供

dnfもyumも/usr/bin/dnf5へのリンクで、よく使う書き方は互換エイリアスで動きます。壊れるのはPython APIで、コンテナでpython3 -c "import dnf"を実行するとModuleNotFoundErrorで止まりました。python3-dnfはリポジトリにも無く、python3-libdnf5へ移植します。AnsibleやChef越しでも、使っている版とパッケージ管理モジュールのDNF5対応を確かめます（Ansibleのdnf5モジュールはpython3-libdnf5が前提）。自前のスクリプトでimport dnfしている箇所は全数洗い出しの対象です。

OpenSSLとAWS-LCの併存とnginx-awslc

暗号ライブラリのAWS-LCが同梱されますが、OpenSSLの置き換えではなく、既定はOpenSSL 3.5（実測3.5.8）のままです。httpd・haproxy・libpq・python3.14・rsyncなどがAWS-LCにリンクし、0928版でMariaDB系も加わりました。nginxは通常版と別にnginx-awslcがあります。両者には双方向の機能差があるので、自前アプリのリンク先は使っている暗号APIを確かめてから決めます。

npm・pipの依存クールダウンとCIへの影響

npmとpipには公開から1日未満のパッケージを入れない設定が既定で入りました。コンテナでpython3-pipとnpmを入れると、次の設定ファイルが置かれます。

$ cat /etc/pip.conf
[global]
# Only install packages published >1 day ago (supply chain protection). Override: --uploaded-prior-to=P0D
uploaded-prior-to = P1D

$ cat /etc/npmrc
prefix=/usr/lib/nodejs24

# Only install packages published >1 day ago (supply chain protection). Override: --min-release-age=0
min-release-age=1

社内レジストリに上げた直後の版をCIで指定すると、クールダウンで候補から外れて依存解決に失敗する場合があります（範囲指定なら古い版が選ばれることもあります）。外すのはnpmなら--min-release-age=0かプロジェクトの.npmrc、pipなら--uploaded-prior-to=P0Dで、社内パッケージを扱うジョブに限ります。

SSHの鍵要件と設定ファイルの優先順位

SSHは既定の設定ページのとおり、ssh-rsa署名とDSA鍵が使えず、RSA鍵は2048ビット以上が必須で、ホスト鍵はed25519とECDSAだけが作られます。/etc/ssh/sshd_config.d/10-amazon-hardening.confにはPermitRootLogin noなどが並び、sshdは最初に読んだ値を採るため、後ろの番号のファイルでは上書きできません。変えるなら05-custom.confのように若い番号で置きます。

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

公式ドキュメントのとおり、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サーバー、標準外のポートで待ち受けるアプリ、自前でソケットファイルを置くミドルウェアです。permissive中に作ったファイルには誤ったラベルが付くことがあるので、enforcingへ戻す前にラベルを確かめます。公式が説明する自動再ラベルはdisabledからenabledへ変えたときのもので、permissiveとenforcingの切り替えでは走るとは限りません。

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

公式の手順は、/etc/selinux/configを書き換えて再起動するか、起動時にcloud-configをユーザーデータで渡すかの2つです。

# 方法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で省けますが、公式は安定性のため再起動を勧めています。

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

AVCログによるラベル・ポート・許可ルールの確認

permissiveは拒否せずにAVCメッセージだけを出すので、実行した処理について拒否候補を確認できます。ただし、未実行の処理やdontauditで記録が抑制されたアクセスは、この確認だけでは把握できません。

# 直近の拒否イベントを人が読める形で一覧する
$ 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

# httpdが読み取る専用ディレクトリのラベル規則を新規登録して適用する
$ sudo semanage fcontext -a -t httpd_sys_content_t '/srv/myapp(/.*)?'
$ sudo restorecon -Rv /srv/myapp

audit2allowの出力は「拒否されたアクセスを全部許す」内容なので、そのまま当てません。先にsemanage fcontextとrestoreconでのラベル付け、semanage portでのポート追加で直し、残った分だけカスタムポリシーにします。permissiveで業務相当の処理を流し、修正後にenforcingで再試験します。移行工数は、未確認の処理、ポリシー修正、依存パッケージの変更、回帰試験の範囲を含めて見積もります。

AL2027をコンテナとEC2で動かして確かめる手順

パッケージの有無や設定ファイルはコンテナで確かめ、コンテナでは見えないSELinux・カーネル・起動まわりだけEC2で確かめるのが手早い分け方です。

コンテナイメージによるOS版とパッケージ提供状況の確認

コンテナにもx86-64-v3の要件がかかります。次の動的リンカによる確認は、x86_64版コンテナを起動できる環境で使います。Arm環境ではこのパスを使えず、CPU要件を満たさない環境では確認コマンドを実行する前に起動が失敗する場合があります。

$ docker run --rm -it public.ecr.aws/amazonlinux/amazonlinux:2027 bash

# 版を確認する（2026年10月21日時点の2027タグ）
# cat /etc/amazon-linux-release
Amazon Linux release 2027.0.20261012 (Amazon Linux)

# CPUがx86-64-v3を満たすか確認する
# /lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v3
  x86-64-v3 (supported, searched)

# 移行元で使っているパッケージがAL2027にあるか確認する
# dnf repoquery --latest-limit 1 ksh cronie

過去の版も2027.0.20260903.0のようなタグで引けます。/etc/os-releaseのVARIANT="Public Preview"でプレビュー版を判別でき、版の確認コマンド全般はLinuxのバージョン確認：OS確認コマンドの早見表とos-release・unameの使い分けにまとめています。

SSMパブリックパラメータによるAMI解決とEC2の起動

EC2では公式手順のとおり、SSMパブリックパラメータでAMI IDを解決させます。前述のとおりkernel-defaultの名前を使います。次の例の二重波括弧は置換箇所を示します。実行前に波括弧を取り除き、インスタンスタイプ・リージョン・キーペア名・セキュリティグループ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が替わるプレビューに向きます。既定ユーザーはec2-userで、セキュリティグループを省くと既定のものに入ります。インスタンスタイプの選び方はAmazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説、検証後に自前のAMIへ固める手順はAWS AMIとは：作成・コピー・共有・登録解除のCLI手順と東京のスナップショット料金に譲ります。

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

システム要件によると、x86-64のバイナリはすべて-march=x86-64-v3でビルドされます。v3はAVX・AVX2・BMI1・BMI2・F16C・FMA・LZCNT・MOVBE・XSAVEを要求し、IntelのHaswell、AMDのExcavator以降、おおよそ2015年以降のプロセッサに相当します。

このためc1・c3・i2・m1・m2・m3・r3・t1ではAL2027が起動しません。ArmはGraviton2以降が必要で、a1は対象外。要件を満たさないCPUでは実行のごく初期に不正命令エラーが出ます。32bit x86（i686）の実行も無効です。メモリの下限は512MBで、800MB未満のインスタンスではzramによるスワップが既定で有効になります。

非推奨機能のAL2027での提供状況と移行前の棚卸し

公式の一覧は「AL2023で非推奨になった機能のほとんどはプレビュー時点で削除済み、一部はGA前に削除」としています。実測すると、削除済みのものと、まだ入るが移行すべきものに分かれました。

ksh・libdb・pcre1・System V init・cgroup v1は削除済み

1012版のコンテナでdnf install ksh libdb pcreを実行すると、3つともNo match for argumentで返りました。kshで書かれたスクリプトはbashへ、PCRE1にリンクした社内ツールはPCRE2で作り直します。Berkeley DB（libdb）はAL2023の5.3.28がライセンス変更前の最後の版で、AL2027では提供されません。opensmtpdも削除済みで、後継はpostfixかsendmailです。

System V initスクリプトはsystemd 260がサポートを落としたため動かず、ネイティブのユニットファイルへ書き換えます。古いミドルウェアのインストーラが/etc/init.d/にスクリプトを置く作りだと、ここで確実に止まります。cgroup v1もsystemd v258で削除され、v2だけになりました。v1の階層を読む監視エージェントや自作のリソース制限スクリプトはv2のインターフェースへ移します。

cronieとaspellはまだ入るが移行の対象

cronは削除されていません。cronieは1012版でも1.7.2をインストールでき、AL2023と同じく既定導入されないだけです。公式は将来のAmazon Linuxでcronジョブのサポートをやめる可能性があるとしてsystemdタイマーを勧めていますが、今回の移行で急ぐ必要はありません。一方aspellは1012版で入るもののGA前の削除が明記されており、hunspellかenchant2への移行はGAを待たずに済ませます。

稼働中のAL2023で依存を洗い出すコマンド

棚卸しは稼働中のAL2023インスタンスで機械的に確かめるところから始めます。パッケージ構成の前提を揃えたい場合はLinuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説【2026年版】も参考になります。

# AL2027で削除済み、またはGA前に削除予定のパッケージを確認する
$ rpm -qa --qf '%{NAME}\n' | grep -E '^(ksh|libdb|pcre|opensmtpd|aspell)$'

# 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

# .ko を直接扱うスクリプトを探す（.ko.zst 化の影響）
$ grep -rlE 'insmod|\.ko\b' /opt /usr/local/bin 2>/dev/null

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

採用判断では、必要なドライバやAMIレシピの提供状況と、GA後の移行作業を確認します。

dnf upgradeでは更新されない版固定リポジトリの扱い

AL2027のインスタンスは、既定で重要度の高いセキュリティ更新を含めて自動更新を受け取りません。加えて版固定リポジトリの仕組みにより、AMIごとにリポジトリの版が固定されています。2027.0.20260903.0のコンテナで確かめると、素のdnf upgradeは「Nothing to do.」で何も更新せず、--releasever=latestを付けて初めて2027.0.20261012まで上がりました。

# 固定されている版を確認する
$ rpm -q system-release
system-release-2027.0.20260903-0.amzn2027.noarch

# 最新の版へ上げる（版を指定するなら --releasever=2027.0.20261012）
$ sudo dnf upgrade --releasever=latest

SSM Patch Managerによるパッチ適用はプレビューでは成功しないため、Patch Managerに寄せている組織ではAL2027の検証機だけが管理の外へ落ちます。当て漏れを機械的に拾う側はAmazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断で検出の仕組みを確かめておくと穴を埋められます。

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

いま検証に着手すべきなのは、2027年後半以降も改修と運用が続き、SELinuxのポリシー調整が要りそうな構成（標準外パスのWebサーバー、独自ポートのアプリ、自前のソケット配置）を持つ案件です。0928版でVMイメージが出たので、同じイメージをオンプレミスのハイパーバイザーでも回す案件もここに入りました。

AL2023のまま進めてよいのは、必要なパッケージのサポートが運用期間を満たし、2029年6月30日までに運用終了または後継OSへの移行を完了できる案件です。「待ち」に置くのは、P4d・P5・P6などFabric Managerが前提のGPUインスタンスを使う案件と、EKSのノードとして使う案件で、それぞれFabric Managerと11月のEKS最適化AMIレシピが揃うまで判断材料が増えません。シングルGPUやInferentia・Trainiumでの検証は先に着手できます。

AL2023からAL2027へ移す公式の手順やツールは、2026年10月21日時点のユーザーガイドにありません。公式が示す--releaseverでの更新はAL2027の版同士のもので、移行は新しいインスタンスへ構成を作り直す前提で計画します。IaCで再現できる環境でも検証期間はアプリの互換性と回帰試験の範囲で決まり、手作業の設定が残る環境ではその棚卸しと再現手順の作成も見積もりに入ります。不具合の報告やパッケージの要望はGitHubのamazon-linux-2027リポジトリが窓口です。EC2上のLinux基盤の設計やAL2023からの移行を外部に出す前提で見積もりたい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応範囲を確認してください。

よくある質問

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

使えません。公式は評価とテスト専用と明記し、プレビューはAWSサポートの対象外です。自動更新は既定で無効、SSM Patch Managerによるパッチ適用も成功しません。本番でAWSのサポートが必要なワークロードは、GAまでAL2023で運用します。

Amazon Linux 2027のGA（一般提供）はいつですか？

2026年10月21日時点で日付は発表されていません。製品ページのFAQでは、プレビューは2027年初頭まで続き、2026年11月にPhase 2としてSPALパッケージ・DCV・EKS最適化AMIレシピが加わる予定です。2027年1月を過ぎて報告された問題はGAまでに直らない可能性があるとされています。

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

2026年10月21日時点で、公式にインプレース移行の手順は用意されていません。--releaseverでリポジトリの版を上げる更新はAL2027の版同士に使うもので、AL2023からはAL2027のAMIで新しいインスタンスを立てて構成を作り直す前提で計画します。

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への移行とインスタンスタイプの更新を同じ計画に載せます。

関連記事

• Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説
• Linuxのバージョン確認：OS確認コマンドの早見表とos-release・unameの使い分け
• カーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】