AL2023に移したら/var/log/messagesが無い。Amazon Linux 2のサポート終了後に移行で変わること

こんにちは、インフラエンジニアのryuです。

Amazon Linux 2の標準サポートは、2026年6月30日で終わりました。もう3か月以上がたっています。

それでも、まだAmazon Linux 2のEC2が動いている現場は少なくないと思います。サーバーはサポートが切れても止まらないので、後回しにしやすいんですよね。

ただ、9月30日にはLambdaの provided.al2 ランタイムで関数の更新ができなくなるなど、周りのサービスのほうから期限がやってきています。

今日は、Amazon Linux 2（AL2）からAmazon Linux 2023（AL2023）へ移すときに、何が変わるのかを具体的に整理してみます。

OSの選び方そのものは、以前の記事『2026年のLinuxディストリビューション選びとサポート期限』で書きました。今回はAL2023に移すと決めたあとの、作業の中身の話です。

Amazon Linux 2のサポート終了で、何が起きたのか？¶

まず、いま何が終わっていて、何がまだ動いているのかを確認しておきます。

AL2の終了日は、もともと2023年の予定でした。そこから何度か延長されて、最終的に2026年6月30日になりました。

終了したあともインスタンスは普通に起動しますし、すぐに止まるわけではありません。ただ、新しい脆弱性が見つかっても、AWSからの修正パッケージは出なくなります。

関連するサービスの期限もあわせて表にしておきます。

EC2だけを見ていると、AL2は「まだ動いているから大丈夫」に見えます。

でも、EKSのノードやLambdaの関数も同じAL2の上で動いています。EKSは1.33以降のバージョンでAL2のAMIを出していないので、クラスターを上げようとした時点で移行が必要になります。

サポートが終わっても動き続けるのは、安心材料ではありません。止まらないぶん、古いOSが残っていることに気づきにくくなります。

まず、自分の環境にAL2が残っているか調べる¶

移行の話をする前に、AL2がどこに残っているかを調べておきましょう。

サーバーにログインできるなら、OSのバージョンは /etc/os-release で確認できます。

$ cat /etc/os-release | grep -E '^(NAME|VERSION)='
NAME="Amazon Linux"
VERSION="2"

VERSION="2" ならAL2、VERSION="2023" ならAL2023です。

台数が多い場合は、1台ずつログインするより、EC2の一覧からAMIの情報をたどるほうが早いです。Lambdaについては、AWS CLIでランタイムの一覧を出せます。

# provided.al2 を使っている Lambda 関数を探す
aws lambda list-functions \
  --query "Functions[?Runtime=='provided.al2'].FunctionName" \
  --output table

コンテナを使っている場合は、Dockerfile の FROM 行に amazonlinux:2 が残っていないかも見ておきます。

AL2からAL2023へ、そのままアップグレードはできるのか？¶

ここで最初につまずくのが、アップグレードの方法です。

結論から言うと、AL2からAL2023へのインプレースアップグレード（動いているサーバーをそのまま上げること）はサポートされていません。 AWSのドキュメントでも、メジャーバージョンをまたぐアップグレードはできないと書かれています。

そのため移行は、AL2023で新しいインスタンスを作って、設定とデータを移すやり方になります。

新しく作り直すことになるので、AMIの仕組みも理解しておくと作業がスムーズです。AMIについては『EC2のAMIとは？』で詳しく書いています。

作り直す以上、AL2で当たり前に使っていたものがAL2023では無い、という場面に何度も出会います。ここからは、その違いを順番に見ていきます。

AL2023で変わることを順番に確認しよう¶

AL2とAL2023の違いはたくさんありますが、普段の運用で影響が大きいものを7つに絞りました。

ひとつずつ、移行のときに何をすればいいかを書いていきます。

1. yumとamazon-linux-extrasは、dnfにまとまる¶

AL2023のパッケージ管理は dnf です。yum の後継にあたるツールです。

コマンドの書き方はほとんど同じなので、手で打つぶんにはあまり困りません。

# AL2
sudo yum install -y httpd
sudo amazon-linux-extras install -y nginx1

# AL2023
sudo dnf install -y httpd
sudo dnf install -y nginx

困るのは、構築スクリプトの中に amazon-linux-extras が書かれている場合です。AL2023にはこのコマンドが無いので、スクリプトがそこで止まります。

もうひとつ注意したいのがEPELです。AL2ではEPELを足して追加のパッケージを入れていた方も多いと思いますが、AL2023とバイナリ互換のあるEPELはありません。

EPELから入れていたパッケージは、AL2023の標準リポジトリにあるか、別の入れ方があるかを1つずつ確認する必要があります。

2. /var/log/messagesが無い¶

冒頭のタイトルにも書いたのがこれです。AL2023では、rsyslogが標準では入っていません。

そのため、AL2で見ていた /var/log/messages や /var/log/secure のようなテキストのログファイルは、最初は存在しません。ログはsystemd-journaldに集められていて、journalctl で読みます。

# AL2 でよく使っていた見方
sudo tail -f /var/log/messages

# AL2023 での見方
sudo journalctl -f
sudo journalctl -u httpd --since "1 hour ago"

問題になるのは、ログファイルを前提にした仕組みです。

たとえば、CloudWatch エージェントで /var/log/messages を送っていた、監視ツールが /var/log/secure を読んでいた、という構成はそのままでは動きません。

どうしてもファイルで残したい場合は、dnf install rsyslog でrsyslogを入れることもできます。ただ、新しく作るなら journalctl での見方に慣れておくほうが、ほかのディストリビューションでも役に立ちます。

ログのローテーションの考え方は『logrotateが動かない・効かない原因の確かめ方』も参考になると思います。

3. cronが入っていない¶

AL2023には、cronの本体であるcronieが標準では入っていません。つまり、何もしないと crontab -e が使えません。

AWSは、代わりにsystemd timerを使うことを勧めています。もちろん dnf install cronie でcronを入れて、今までどおり使うこともできます。

# cron を使い続ける場合
sudo dnf install -y cronie
sudo systemctl enable --now crond

どちらを選ぶかは、チームの慣れと、ジョブの数で決めればいいと思います。

cronとsystemd timerの違いは『cronとsystemd timerの使い分け』で詳しく比べています。移行のついでに見直す場合は、あわせて読んでみてください。

4. ネットワークの設定ファイルの場所が変わる¶

AL2では、/etc/sysconfig/network-scripts/ の下にある ifcfg-eth0 のようなファイルでネットワークを設定していました。

AL2023では、ネットワークインターフェースの管理がsystemd-networkdに変わっています。普通にEC2を使うだけなら、DHCPでIPアドレスを受け取るので、設定を触ることはほとんどありません。

影響が出るのは、MTUを変えていた、静的ルートを足していた、複数のENIを付けていた、といった手作業の設定がある場合です。ifcfg のファイルをそのままコピーしても効かないので、systemd-networkdの書き方で作り直します。

5. メタデータの取得にトークンが要る（IMDSv2）¶

EC2のインスタンスメタデータは、インスタンスIDやIAMロールの一時的な認証情報などを取得する仕組みです。

AL2023のAMIから起動したインスタンスは、標準でIMDSv2が必須になっています。IMDSv2では、先にトークンを取得してからメタデータを読みます。

# トークンを取得してからメタデータを読む（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

AL2時代のスクリプトで、トークン無しで curl http://169.254.169.254/... と書いている部分は、AL2023では 401 が返って失敗します。

ユーザーデータや監視のスクリプトに、こういう書き方が残っていないか検索しておきましょう。

6. dnf upgradeしても、最新にならないことがある¶

これはAL2023で初めて触る方が、いちばん戸惑うところかもしれません。

AL2023では、パッケージのリポジトリにバージョンがあり、インスタンスはAMIを作ったときのバージョンに固定されています。AWSはこれを「決定的アップグレード（deterministic upgrades）」と呼んでいます。

そのため、ただ sudo dnf upgrade を実行しても、固定されたバージョンの中での更新しか入りません。新しいリポジトリのバージョンに上げるには、明示的に指定します。

# 新しいリポジトリのバージョンが出ているか確認する
sudo dnf check-release-update

# 最新のバージョンへ上げる
sudo dnf upgrade --releasever=latest

同じAMIから作ったサーバーは同じパッケージの状態になるので、検証環境と本番の差が出にくいのが良いところです。

その反面、何もしないとセキュリティ更新も入らないままになります。パッチの当て方の手順は、AL2のときの「yum update を流すだけ」から書き換えておく必要があります。

7. Python 2がなくなり、SELinuxの初期設定も変わる¶

最後は、細かいけれど見落としやすい2つです。

AL2023ではPython 2.7が削除され、OSのツールもPython 3で動くようになりました。#!/usr/bin/python で始まる古いPython 2のスクリプトは、書き直しが必要です。

また、AL2023ではSELinuxが有効になっていて、標準はpermissiveモードです。permissiveでは拒否は記録されるだけで、動作は止められません。

今すぐ何かが壊れるわけではありませんが、将来enforcingに切り替えるつもりなら、permissiveのうちにログを確認しておくと安心です。

移行の前に、チェックしておくこと¶

ここまでの違いを、移行前のチェックリストとしてまとめておきます。

この中で、いちばん漏れやすいのはログと定期実行の2つだと思います。

どちらも、エラーが出て止まるのではなく、黙って動かなくなるからです。ログが送られていない、バッチが走っていない、ということに数日たってから気づく、というのは避けたいところです。

移行したら、初日にログが届いているか、定期ジョブが動いたかを必ず目で確認しましょう。systemdのサービスが起動しない場合の調べ方は『systemdのサービスが起動しないときの確認手順』にまとめています。

Linuxの基本は、AL2023でも変わらない¶

違いをたくさん並べましたが、ファイルの権限、プロセス、ネットワーク、ログの読み方といったLinuxの基本はAL2023でも同じです。

むしろAL2023は、journald、systemd timer、systemd-networkd、dnfと、RHEL系やほかの新しいディストリビューションと同じ道具がそろいました。AL2023で覚えたことは、ほかのLinuxでもそのまま使えます。

InfraAcademyの『Linuxロードマップ』では、コマンドやログの見方など、ディストリビューションが変わっても使える基本を順番に学べます。AWS上での運用まで含めて学びたい方は『AWSロードマップ』もあわせて使ってみてください。

まとめ¶

Amazon Linux 2の標準サポートは2026年6月30日に終わり、Lambdaの provided.al2 も9月30日で関数の更新ができなくなりました。EKSも1.33以降はAL2のAMIを出していません。

AL2からAL2023へはそのままアップグレードできないので、新しいインスタンスを作って移すことになります。そのとき、yum と amazon-linux-extras は dnf に、ログはjournaldに、cronはsystemd timerかcronieの追加インストールに変わります。

さらに、メタデータの取得にはIMDSv2のトークンが要り、パッケージの更新はリポジトリのバージョンを指定して行います。

どれも、知っていれば手間はそれほどかかりません。移行の前にチェックリストを1回流して、黙って止まる仕組みが無いかを確かめておきましょう。

参考¶

• Comparing AL2 and AL2023（AWS 公式ドキュメント）
• systemd journal replaces rsyslog（AWS 公式ドキュメント）
• systemd timers replace cron（AWS 公式ドキュメント）
• Deterministic upgrades through versioned repositories on AL2023（AWS 公式ドキュメント）
• Default SELinux status and modes for AL2023（AWS 公式ドキュメント）
• Extra Packages for Enterprise Linux (EPEL) - Amazon Linux 2023（AWS 公式ドキュメント）
• Upgrade from Amazon Linux 2 to Amazon Linux 2023 - Amazon EKS（AWS 公式ドキュメント）
• Guide to EKS AL2 & AL2-Accelerated AMIs transition features（AWS 公式ドキュメント）
• Lambda runtimes（AWS 公式ドキュメント）
• Amazon Linux 2023 package support information（AWS 公式ドキュメント）