Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所

Amazon Linux 2（AL2）は2026年6月30日でサポートを終えました。EC2インスタンスは止まらずに動き続けますが、新しく見つかる脆弱性は直りません。厄介なのは、AL2がEC2だけでなくLambdaのランタイム、ECSやEKSのノード、Elastic Beanstalkの環境にも潜んでいて、サービスごとに期限が違う点です。この記事では、AWSサービス別の終了日、稼働中のAL2をCLIで洗い出すコマンド、後継のAmazon Linux 2023（AL2023）で動かなくなる設定と書き換え例、AL2023とプレビュー中のAL2027のどちらへ移すかの判断を、AWSの公式ドキュメントに沿って整理します。

まとめ：サポート終了済みのAL2から抜ける順番とAL2023を選ぶ判断

結論から書くと、移行先はAL2023一択で、着手は今です。AWSのAL2 FAQは、AL2が標準のセキュリティ更新を受け取らなくなったことを明記したうえで、将来の版を待たずにAL2023へ移るよう勧めています。AL2からAL2023へのインプレース更新はなく、新しいAMIから作り直す移行になります。

進める順番は3段です。第1に、EC2・Lambda・コンテナ基盤のどこにAL2が残っているかをCLIで全数出す。第2に、外部に公開しているもの、更新が止められる期限が近いものから順に移す。Lambdaのpython3.10は2026年10月31日に廃止日を迎えます。第3に、yum・cron・rsyslog・IMDSv1・ssh-rsaといった、AL2023で既定から外れた前提を構成コードから消していく。

作業量を決めるのは台数ではありません。サーバーを手作業で積み上げてきたか、構成をコードで再現できるか。この差がそのまま工数になります。

Amazon Linux 2のサポート終了日と終了後も動き続ける範囲

AL2はAL1（旧Amazon Linux AMI）の次に出た前世代のAmazon Linuxで、2023年3月に後継のAL2023が出ています。AL2のユーザーガイドも冒頭で、AL2はもう現行版ではなくAL2023が後継だと書いています。

2026年6月30日の終了で止まった更新と止まらないインスタンス

終了日は延長を経て2026年6月30日に確定し、すでに過ぎています。この日を過ぎても、AL2で動いているEC2インスタンスが停止されたり、起動できなくなったりはしません。止まったのはAWSによる標準のセキュリティ更新で、FAQは「新しい脆弱性が修正されないため、使い続けるほどリスクが増える」と説明しています。

実務で効くのは、この「動くが直らない」状態が監査や取引先のセキュリティチェックで指摘対象になる点です。OSのサポート期限切れは、脆弱性診断の報告書でほぼ確実に指摘項目へ載ります。本番で外部公開しているサーバーなら、期限を越えた状態は数か月単位で放置できるものではありません。

インプレース更新が無くAMIからインスタンスを作り直す前提の移行計画

AL2からAL2023へ、稼働中のインスタンスをそのまま上げる手段は用意されていません。新しいAL2023のAMIからインスタンスを起動し、ミドルウェアと設定を載せ直してから切り替える形です。AL2とAL2023の比較ページには、パッケージ管理がYUMからDNFへ、ネットワーク管理がdhclientからsystemd-networkdへ変わったことをはじめ、30項目近い差分が並んでいます。

カーネルもAL2の4.14・5.10系からAL2023の6.1・6.12系へ上がります。32bitのユーザー空間パッケージは一切含まれず、lsb_releaseコマンドも同梱されません。OSの判定をlsb_releaseに頼っている古いインストーラやスクリプトは、/etc/os-releaseを読む形へ直す必要があります。

AWSサービス別に違うAL2の終了日とLambda・ECS・EKSの期限

AL2本体の終了日は2026年6月30日の1つですが、AL2を土台にしたAWSのマネージドサービスは、それぞれ別の日付で提供を畳んでいます。EC2だけを見ていると、ここを取りこぼします。

LambdaのAL2系ランタイムと関数の更新が止められる日付

Lambdaは例外的に、AL2本体の終了後もAL2系ランタイムへのパッチを続けています。Lambdaのランタイム一覧によると、Java 8・11・17（AL2）、Python 3.10・3.11、provided.al2は、言語ランタイムのパッチに加えてAL2の重大なセキュリティ問題への修正を各ランタイムの廃止日まで受け取ります。2026年10月2日時点の公式表は次のとおりです。

廃止日を過ぎても関数は呼び出せますが、更新ブロック日以降はコードも設定も変えられません。障害時に1行直してデプロイする手段が消えるので、実質の締め切りは2027年8月31日の更新ブロックより前に置きます。Java 8・11・17の版を上げられない場合でも、java8.al2023のようなAL2023版のランタイムへ載せ替えれば2029年まで延ばすことが可能です。Lambdaの実行環境とランタイムの関係はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説で押さえられます。

ECS・EKS・Elastic Beanstalkで先に切れていたAL2の提供

コンテナ基盤側は、AL2本体より早く、あるいは同時に提供を止めています。EKSのAMI移行ガイドによると、EKS-optimized AL2 AMIの公開は2025年11月26日で止まり、AL2のAMIが出たKubernetesは1.32が最後です。既存ノードは動き続けますが、1.33以降へクラスターを上げるにはAL2023かBottlerocketのノードへ移るしかありません。EKSのノード提供形態の違いはAmazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説が詳しいところです。

ECSはECSの移行ガイドのとおり、AL2のECS-optimized AMIの標準サポートを2026年6月30日で終え、以降はAMIを公開しません。Elastic Beanstalkは2026年8月6日のリリースノートで、Docker・ECS・Go 1・Corretto 8／11／17・Tomcat 9・.NET Coreの残っていたAL2プラットフォームブランチをすべて退役させ、保守更新の提供を止めました。

稼働中のAL2を洗い出すSSMとLambdaの棚卸しコマンド

移行計画は、残っているAL2の全数が出るまで始まりません。台帳や記憶に頼らず、AWSのAPIから機械的に引きます。

SSMのdescribe-instance-informationでAL2一覧取得

Systems Managerのエージェントが入っているEC2なら、describe-instance-informationの出力にOS名と版が含まれます。CLIリファレンスにあるとおり、PlatformNameがOS名、PlatformVersionがその版です。リージョンを回しながら版が2のAmazon Linuxだけを抜き出します。

# 全リージョンのSSMマネージドノードから Amazon Linux 2 を抜き出す
for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  aws ssm describe-instance-information --region "$r" \
    --query "InstanceInformationList[?PlatformName=='Amazon Linux' && PlatformVersion=='2'].[InstanceId,ComputerName,PingStatus]" \
    --output text | sed "s/^/$r\t/"
done

# インスタンスの中から確かめる（AL2 は VERSION_ID="2"、AL2023 は "2023"）
$ grep -E '^(NAME|VERSION_ID)=' /etc/os-release
NAME="Amazon Linux"
VERSION_ID="2"

絞り込みに使うPlatformNameの値は、手元の1台で一度--output jsonを見て確かめてから流してください。SSMエージェントが入っていない、またはPingStatusがConnectionLostのインスタンスはこの一覧に出ません。漏れを拾うには、EC2側で起動元AMIの名前（AL2はamzn2-ami-で始まる）を照合します。Session ManagerやRun Commandでの一括作業まで視野に入れるなら、AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころで機能の範囲を確認しておくと段取りが組めます。

Lambdaのprovided.al2とAL2系ランタイムを全リージョンで探す

Lambdaは公式の手順がlist-functionsの--queryでランタイムを絞る方法を示しています。AL2系の識別子をまとめて渡せば、1回の走査で済みます。

# AL2 上で動くランタイムを使っている関数を、全バージョン・全リージョンで一覧する
AL2_RUNTIMES="['provided.al2','python3.9','python3.10','python3.11','java8.al2','java11','java17','nodejs18.x','ruby3.2']"
for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  aws lambda list-functions --function-version ALL --region "$r" --output text \
    --query "Functions[?contains(${AL2_RUNTIMES}, Runtime)].[FunctionArn,Runtime]"
done

コンテナイメージで作った関数はRuntimeが空なので、この一覧には出ません。ベースイメージがAL2系（例えばpublic.ecr.aws/lambda/provided:al2）かどうかを、DockerfileのFROM行で確かめます。AWSアカウントが複数あるなら、同じループを各アカウントで回すか、AWS Configの高度なクエリでまとめて引くのが早道です。

AL2023へ移すと動かなくなる運用設定と構成スクリプトの書き換え例

AL2023は「入っているのが当たり前だったもの」をいくつも既定から外しました。移行で止まるのは、たいていアプリケーション本体ではなく、構成スクリプトや運用の仕組みのほうです。影響の大きい順に並べます。

yumとamazon-linux-extrasとEPELが使えないときの置き換え先

AL2023のパッケージ管理はDNFが標準で、yumコマンドはDNFへのポインタとして残っています。yum installと書いたスクリプトはほぼそのまま通ります。止まるのはamazon-linux-extrasで、AL2023にはこの仕組みがなく、パッケージはすべてcoreリポジトリから入れる形に変わりました。

もう1つの落とし穴がEPELです。EPELの互換性ページによると、AL2のextrasで有効にできたEPEL7は2024年6月30日で保守を終えており、AL2023とバイナリ互換のEPELはありません。git-lfsやjemallocのようにAL2023のcoreに入ったものもあれば、xmlstarletのように提供されないものもあります。残りの一部はSupplementary Packages for Amazon Linux（SPAL）で入りますが、SPALはAWSサポートの対象外で、CVEの追跡もされません。

# AL2 の構成スクリプトでよく見る書き方
$ sudo amazon-linux-extras install nginx1
$ sudo yum install -y epel-release

# AL2023 では extras も EPEL も無いので core から直接入れる
$ sudo dnf install -y nginx
$ sudo dnf install -y git-lfs jemalloc

# 入れたいパッケージが AL2023 にあるかを先に確かめる
$ dnf search xmlstarlet

cronとrsyslogが既定で入らない環境の定期実行とログ確認

AWSの説明では、AL2のAMIに既定で入っていたcronieがAL2023では入りません。crontabに夜間バッチを並べていたサーバーは、移した直後から何も実行されなくなります。エラーも出ないので、気づくのは翌朝です。sudo dnf install cronieで戻せますが、AWSが勧めているのはsystemdタイマーへの移行です。

# /etc/systemd/system/nightly-backup.service
[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/opt/app/bin/backup.sh

# /etc/systemd/system/nightly-backup.timer（crontab の「0 3 * * *」に相当）
[Unit]
Description=Run nightly backup at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

# 有効化と次回実行時刻の確認
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now nightly-backup.timer
$ systemctl list-timers nightly-backup.timer

Persistent=trueにしておくと、停止中に予定時刻を過ぎた分を起動後に1回実行します。ログも同じ構図で、AL2023はrsyslogを既定で入れないため/var/log/messagesが存在しません。tail -f /var/log/messagesはjournalctl -fへ置き換えます。ログファイルを監視エージェントで拾っている構成は、収集元をjournaldへ向け直すか、rsyslogを明示的に入れるかは、移行前に決めておくべき事項です。ユニットファイルとタイマーの仕組みはsystemdとは何か？Linuxにおける役割と概要解説で前提を揃えられます。

IMDSv2必須とssh-rsa無効で起動処理や接続が止まる箇所

AL2023のAMIは、インスタンスメタデータサービスをIMDSv2のみで起動するのが既定です。ユーザーデータや起動スクリプトでcurl http://169.254.169.254/latest/meta-data/...と直接叩いていた箇所は、トークンを取らないと401で弾かれます。

# IMDSv2: 先にトークンを取ってからメタデータを読む
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

SSHの接続も変わります。AL2023のsshd既定設定ではssh-rsa署名が無効で、クライアントはrsa-sha2-256・rsa-sha2-512かed25519鍵に対応している必要があります。古い踏み台や監視ツールの組み込みSSHクライアントがここで繋がらなくなる例が典型です。UseDNS=noも既定になり、authorized_keysのfrom=にホスト名を書いていた行はIPアドレスへ書き換えます。

cgroup v2でJavaのメモリ上限が見えなくなるコンテナの対処

コンテナを載せている場合に効くのがcgroupの版です。AL2はcgroup v1、AL2023はv2が既定で、ECSの移行ガイドは2つの症状を挙げています。1つはメモリ使用量の数字がページキャッシュ込みになり、同じワークロードでも高く見えること。もう1つは、タスク単位でだけメモリを指定しコンテナ単位で指定していない場合に、コンテナ内からタスクの上限が見えなくなることです。

後者はJVMで実害が出ます。cgroupの上限からヒープを自動で決めるため、ホスト全体のメモリを前提に確保しすぎてOOMで落ちる。EKSのガイドも、jdk8u372より前のJDK 8はcgroup v2の上限を読めないと書いています。対処はタスク定義でコンテナ単位のmemoryをタスクと同じ値で明示するのが確実で、ECSエージェント1.104.0以降なら設定で上限を伝播させる方法もあります。

# /etc/ecs/ecs.config（ECS エージェント 1.104.0 以降・cgroup v2 のみ有効）
ECS_PROPAGATE_TASK_MEMORY_LIMIT_CGROUPV2=true

リポジトリ固定の既定でパッチが自動で当たらないAL2023の更新運用

見落とされがちなのが更新の仕組みです。AL2は起動時にcloud-initがセキュリティ更新を当てていましたが、AL2023はAMIごとにリポジトリの版が固定され、起動しただけでは追加の更新を受け取りません。決定的アップグレードの説明のとおり、新しい版へ上げるのは利用者の操作です。

# 上げられるリポジトリの版を確認する
$ sudo dnf check-release-update

# 版を指定して更新する（以後この版が既定になる）
$ sudo dnf upgrade --releasever={{version}}

同じAMIから起動した全台が同じパッケージ構成になる利点がある一方、放っておくと古い版のまま固まります。新しいAMIでの作り直しか、SSM Patch Managerでの定期適用か、どちらで回すかを移行と同時に決めておきます。

AL2023とAL2027のどちらへ移すかの判断と見送る場面

2026年9月3日にAL2027のパブリックプレビューが始まり、「どうせならAL2027まで待つ」という声が出やすい時期です。ここは判断を言い切ります。

2027年6月30日の標準サポート終了を見てもAL2023へ移す理由

AL2023のリリースサイクルでは、四半期ごとのマイナー更新が入る標準サポートが2027年6月30日に終わり、セキュリティ更新と重大なバグ修正だけのメンテナンスが2029年6月30日まで続きます。期限が見えているので次のAL2027を待ちたくなりますが、AL2027はプレビューで、本番向けではないと公式が明記し、一般提供の日付も出ていません。AL2の期限はすでに過ぎています。脆弱性が直らないサーバーを、日付の決まっていないGAまで抱える理由はありません。

AL2→AL2023の作業は無駄にもなりません。yumからDNF、cronからsystemdタイマー、cgroup v1からv2への書き換えはAL2027でもそのまま前提になります。AL2027で新たに増える差分（SELinuxのenforcing既定やx86-64-v3要件）はAmazon Linux 2027とは｜AL2023との違いとSELinux既定化で詰まる箇所にまとめたので、AL2023への移行と並行して検証枠だけ取っておくのが現実的な線です。

移行を急ぐ案件と、AL2のまま隔離して畳む案件の公開範囲と廃止期限による線引き

最優先は、インターネットに公開しているAL2のEC2と、Lambdaのpython3.10のように廃止日が目前のものです。次が、EKSで1.33以降へ上げたいクラスターのノード。Kubernetesの版上げがAL2のノードで止まるため、OSの移行がクラスター全体の更新を塞ぎます。

AL2のまま置いてよい例外は1つだけです。半年以内に廃止が決まっていて、外部に公開しておらず、セキュリティグループで到達経路を絞れるシステム。この条件をすべて満たすなら、移行の工数をかけるより隔離して予定どおり畳むほうが合理的です。逆に「いずれリプレイスするから」と期限のない延命をするのは採るべきではありません。リプレイス計画が半年以上かかる時点で、その間の脆弱性はすべて未修正のまま積み上がります。

手作業で積み上げたサーバーが多く、棚卸しから作り直しまで社内で回す余力がない場合は、AL2023の構成をIaCで起こし直すところから外部に出す選択肢もあります。EC2上のLinux基盤の作り直しやコンテナ基盤の移行を見積もりたい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応範囲を確認してください。

よくある質問

Amazon Linux 2のサポート終了と移行について、検索の多い質問に答えます。

Amazon Linux 2はサポート終了後も使えますか？

動かすことはできます。2026年6月30日を過ぎてもEC2インスタンスは停止されず、起動も可能です。ただしAWSによる標準のセキュリティ更新は止まり、新しく見つかった脆弱性は修正されません。外部に公開しているサーバーや、取引先のセキュリティ審査を受けるシステムで使い続けるのは避け、AL2023への移行を進めます。

Amazon Linux 2からAL2023へアップグレードできますか？

稼働中のインスタンスをそのまま上げるインプレースの経路はありません。AL2023のAMIから新しいインスタンスを起動し、ミドルウェアと設定を載せ直して切り替えます。EBSのデータ領域は付け替えられますが、OS側の設定やパッケージは作り直しです。構成をAnsibleやTerraformなどのコードで管理していれば、工数は大きく下がります。

自分のサーバーがAmazon Linux 2かどうかはどう確認しますか？

インスタンスの中で/etc/os-releaseを開き、VERSION_ID="2"ならAL2、"2023"ならAL2023です。台数が多いときは、SSMのdescribe-instance-informationでPlatformNameとPlatformVersionを全リージョン分引くと一覧になります。SSMエージェントが入っていない台は、起動元AMIの名前がamzn2-ami-で始まるかで判定します。

LambdaのPythonやJavaのランタイムもAL2の影響を受けますか？

受けます。Python 3.10・3.11、Java 8（AL2）・11・17、provided.al2はAL2上で動くランタイムです。これらはAL2本体の終了後も各ランタイムの廃止日まで重大な脆弱性の修正が続きますが、関数の更新は2027年8月31日にブロックされます。python3.13やjava21、provided.al2023などAL2023系のランタイムへ切り替えます。

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

2029年6月30日までです。四半期ごとのマイナー更新が入る標準サポートは2027年6月30日で終わり、以降はセキュリティ更新と重大なバグ修正だけになります。後継のAL2027は2026年9月にプレビューが始まったものの、一般提供の日付はまだ公表されていません。AL2から移る先としては、AL2023を選ぶのが現時点の答えです。

関連記事

• Amazon Linux 2027とは｜AL2023との違いとSELinux既定化で詰まる箇所：AL2023の次に控えるAL2027で増える差分と、プレビューで先に潰す検証項目
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説：AL2023で作り直すインスタンスのタイプ選びと料金モデル
• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説：AL2系ランタイムを載せ替える前に押さえる実行環境の仕組み
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説：AL2ノードからAL2023・Bottlerocketへ移すときのノード提供形態の選び方
• AWS Elastic Beanstalkとは？仕組み・対応プラットフォームと料金・採用判断を実装者目線で解説：AL2ブランチ退役後に移るAL2023プラットフォームの前提