2026年6月30日がAmazon Linux 2のEOL。
筆者は金融系Webサービスのインフラ移行を担当し、AL2 → AL2023 と MySQL 5.7 → 8 を同時に進めた。
同じ状況の人のために、ハマったポイントと再利用できる手順をまとめる。
目次
- なぜ今すぐ動く必要があるか
- AL2 と AL2023 の主要差分
- 移行方針：インプレースアップグレードは不可
- 事前調査チェックリスト
- 移行手順
- MySQL 8 と同時移行する場合の注意点
- よくあるハマりどころ
- 移行後確認チェックリスト
1. なぜ今すぐ動く必要があるか {#why-now}
Amazon Linux 2 は 2026年6月30日にEOS（End of Support） を迎える。
EOSを過ぎるとセキュリティパッチが提供されなくなり、特に金融・医療系では規制上の問題に直結する。
重要な前提として、AL2 → AL2023 のインプレースアップグレードはサポートされていない。
つまり「新しいAMIでインスタンスを作り直す」ことが必須であり、計画的な移行期間が必要になる。
2. AL2 と AL2023 の主要差分 {#diff}
移行前にここを把握しておくと、後の作業量が格段に変わる。
パッケージ管理
| 項目 | Amazon Linux 2 | Amazon Linux 2023 |
|---|---|---|
| パッケージマネージャ | yum |
dnf（yumはエイリアスとして残存） |
| extras リポジトリ |
amazon-linux-extras あり |
廃止。全パッケージがCoreリポジトリに統合 |
| EPELサポート | あり（有効化可能） | なし |
| 32bitアプリ | サポートあり | 廃止 |
amazon-linux-extrasを使って nginx や php をインストールしているスクリプトはすべて書き直しが必要。
# AL2 では動くが AL2023 では失敗する例
amazon-linux-extras install -y nginx1 # → コマンド自体が存在しない
# AL2023 での正しい書き方
dnf install -y nginx
カーネル・コアライブラリ
| 項目 | Amazon Linux 2 | Amazon Linux 2023 |
|---|---|---|
| カーネル | 4.14 / 5.10 | 6.1 / 6.12 |
| glibc | 2.26 | 2.34 |
| OpenSSL | 1.0.2 / 1.1.1 | 3.x |
| Python デフォルト | 2.7 / 3.x |
3.x のみ（python2 コマンドなし） |
| systemd | 219 | 252 |
glibcのメジャーバージョンアップ（2.26 → 2.34）は、古いバイナリの互換性に影響することがある。
外部からダウンロードしてくる静的でないバイナリには要注意。
セキュリティデフォルト
| 項目 | AL2 デフォルト | AL2023 デフォルト |
|---|---|---|
| IMDSv1 | 有効 | 無効（IMDSv2 のみ） |
| SELinux | Disabled | Permissive（Enforcingへの移行推奨） |
IMDSv1無効化は特に影響が大きい。インスタンスメタデータをHTTPで直接取得しているスクリプトや古いAWS SDKが動かなくなる。
# 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
3. 移行方針：インプレースアップグレードは不可 {#strategy}
AL2 → AL2023 はインプレースアップグレード（yum update での移行）が公式にサポートされていない。
実際にやろうとしても動かない。
取れる移行アプローチは主に2つ：
① 新AMIでEC2を作り直す（推奨）
- AL2023のAMIでEC2を新規作成
- アプリケーションをデプロイし直す
- ELB等でトラフィックを切り替えてBlue/Green
② Dockerコンテナの場合
- ベースイメージを
amazonlinux:2→amazonlinux:2023に変更 - ビルド・動作確認後にデプロイ
本記事では主に①のEC2移行を前提に解説する。
4. 事前調査チェックリスト {#pre-check}
移行作業を始める前に、現行AL2環境を棚卸しする。
スクリプト・User Dataの確認
# amazon-linux-extras を使っている箇所を検索
grep -r "amazon-linux-extras" /etc/ /opt/ ~/
# yum を使っているスクリプトを検索（dnfに変換が必要なものを洗い出す）
grep -rn "^yum " /etc/cron* /opt/ ~/
インストール済みパッケージの確認
# AL2 で明示的にインストールされたパッケージ一覧を出力
rpm -qa --qf "%{NAME}\n" | sort > /tmp/al2-packages.txt
このリストを AL2023 のパッケージリポジトリと照合し、名称変更・廃止されたものがないか確認する。
Python 2 依存のスクリプト確認
# python2 を明示的に呼び出しているスクリプトを探す
grep -rn "#!/usr/bin/python2\|#!/usr/bin/env python2\|python2 " /opt/ /usr/local/bin/
IMDSv1 依存の確認
# IMDSv1 (トークンなしアクセス) を行っているスクリプトを探す
grep -rn "169.254.169.254" /opt/ /etc/ ~/
# 上記ヒットを確認し、X-aws-ec2-metadata-token ヘッダなしのcurlがあればNG
AWS SDK バージョン確認
IMDSv2対応は SDK バージョンによる。古い boto3 / AWS CLI v1 はデフォルトでIMDSv1を使う。
python3 -c "import boto3; print(boto3.__version__)"
aws --version
-
boto3は 1.16.0 以降でIMDSv2対応 - AWS CLI v1 は 1.19.0 以降
- AWS CLI v2 は問題なし
5. 移行手順 {#migration-steps}
Step 1: AL2023 AMI でテスト環境を構築
# AWS CLI で最新の AL2023 AMI ID を取得
aws ec2 describe-images \
--owners amazon \
--filters "Name=name,Values=al2023-ami-*" "Name=architecture,Values=x86_64" \
--query "sort_by(Images, &CreationDate)[-1].[ImageId,Name]" \
--output text
Step 2: アプリケーションのインストールスクリプトを書き直す
主なコマンド対応表
| AL2 | AL2023 |
|---|---|
amazon-linux-extras install nginx1 |
dnf install nginx |
amazon-linux-extras install php8.1 |
dnf install php |
yum install -y <pkg> |
dnf install -y <pkg>（yumも一応動くが非推奨） |
yum groupinstall "Development Tools" |
dnf groupinstall "Development Tools" |
Step 3: systemd ユニットファイルの確認
AL2 では /etc/init.d/ スクリプトを使っていたサービスが残っているケースがある。
AL2023 移行のタイミングで systemd ユニットに統一するのがベスト。
# /etc/systemd/system/myapp.service の例
[Unit]
Description=MyApp Service
After=network.target
[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/start.sh
Restart=on-failure
[Install]
WantedBy=multi-user.target
Step 4: OpenSSL 3.x への対応確認
OpenSSL 1.x から 3.x への変更で、以下が影響を受けることがある：
- MD5/SHA1 を証明書署名アルゴリズムとして使用している場合（デフォルトで無効化）
- 古いバージョンの Java（JDK 8 以前の古いビルド）やRuby gemがOpenSSL 3 非対応の場合
# AL2023 の OpenSSL バージョン確認
openssl version
# → OpenSSL 3.x.x
# TLS 接続確認
openssl s_client -connect your-endpoint:443
Step 5: IMDSv2 対応に修正
前述の通り、IMDSv1依存のコードをIMDSv2対応に修正する。
Terraformで管理している場合はLaunch Templateに設定を追加：
resource "aws_launch_template" "example" {
# ...
metadata_options {
http_endpoint = "enabled"
http_tokens = "required" # IMDSv2 only
http_put_response_hop_limit = 1
}
}
Step 6: 動作確認後にBlue/Green切り替え
AL2023 環境での全機能確認が完了したら、ロードバランサーのターゲットグループを切り替える。
しばらくはAL2環境を残しておき、問題があればすぐに戻せる状態を維持する。
6. MySQL 8 と同時移行する場合の注意点 {#mysql}
AL2 → AL2023 と MySQL 5.7 → 8 を同時に進める場合、リスクが二重に重なる。
筆者は同時移行を行ったが、切り分けを意識した手順を組まないと障害時の原因特定が困難になる。
推奨アプローチ：段階的に進める
Phase 1: AL2 + MySQL 5.7（現行）
↓
Phase 2: AL2023 + MySQL 5.7（OSのみ移行、DBは据え置き）
↓ 動作確認OK後
Phase 3: AL2023 + MySQL 8（DB移行）
「AL2023 + MySQL 5.7」の組み合わせは過渡期としての一時的な構成だが、原因切り分けに有効。
AL2023 上の MySQL 8 インストール
AL2023 の標準リポジトリには MySQL が含まれていないため、MySQL公式リポジトリを追加する。
# MySQL 8 リポジトリ追加
dnf install -y https://dev.mysql.com/get/mysql84-community-release-el9-1.noarch.rpm
# インポートのGPGキー確認
rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023
# インストール
dnf install -y mysql-community-server
# 起動・自動起動設定
systemctl enable --now mysqld
# 初期パスワード確認
grep 'temporary password' /var/log/mysqld.log
MySQL 5.7 → 8 でよくある問題
① sql_mode の変更
MySQL 8 では NO_AUTO_CREATE_USER が削除され、ONLY_FULL_GROUP_BY がデフォルト有効になった。
-- グループ句に集計関数対象外のカラムが含まれるクエリは失敗する
-- 例: SELECT a, b, COUNT(*) FROM t GROUP BY a ← bがGROUP BYにない
-- 一時的な回避（推奨はクエリ修正）
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
② utf8mb4_0900_ai_ci への照合順序変更
MySQL 8 のデフォルト照合順序は utf8mb4_0900_ai_ci（MySQL 5.7 は utf8mb4_general_ci）。
既存データベースと新規テーブルで照合順序が混在すると JOIN 時にエラーが出る。
-- 現在の照合順序確認
SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database';
-- 統一する場合（テーブル単位）
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
③ 認証プラグインの変更
MySQL 8 ではデフォルト認証プラグインが caching_sha2_password に変更。
古いクライアントやORMが mysql_native_password を前提としている場合は要確認。
-- 既存ユーザーの認証プラグイン確認
SELECT user, host, plugin FROM mysql.user;
-- 必要に応じて変更
ALTER USER 'myuser'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
7. よくあるハマりどころ {#pitfalls}
① python コマンドが存在しない
AL2023 では python コマンドがデフォルトで存在しない（python3 は存在する）。
# 確認
which python # → not found
# 解決策1: シンボリックリンク（非推奨、スクリプトへの影響に注意）
ln -s /usr/bin/python3 /usr/local/bin/python
# 解決策2: alternatives で管理
alternatives --install /usr/bin/python python /usr/bin/python3 1
② amazon-linux-extras を呼んでいる UserData の見落とし
EC2インスタンスの起動時に実行される UserData に amazon-linux-extras が残っている場合、
スタックが正常に見えても自動スケーリング時の新インスタンス起動に失敗する。
ASGのLaunch TemplateのUserDataは必ず確認すること。
③ glibc 互換性問題
自社外のベンダーが提供するバイナリエージェント（監視エージェント、APMエージェントなど）が
glibc 2.34 未対応の場合がある。AL2023 への移行前にベンダーに確認する。
# バイナリの要求するglibc最低バージョンを確認
objdump -p /usr/local/bin/your-binary | grep GLIBC
④ IMDSv1 を使っている古い Ansible playbook
Ansibleの ec2_metadata_facts モジュールは古いバージョンでIMDSv2非対応。
community.aws.ec2_metadata_facts の新しいバージョンを使うか、IMDSv1を一時的に有効化して対応。
⑤ SELinux Permissive モードの影響
AL2023 の SELinux はデフォルト Permissive（ポリシー違反をログに記録するが実行はブロックしない）。
将来 Enforcing に移行する可能性があるため、移行時に audit ログを確認しておくことを推奨。
# SELinux の現在の状態確認
getenforce # → Permissive
# audit ログで何か引っかかっていないか確認
ausearch -m AVC -ts recent
8. 移行後確認チェックリスト {#post-check}
[ ] アプリケーション全機能の疎通確認
[ ] ログに新しいエラーが出ていないか確認（/var/log/messages, アプリログ）
[ ] IMDSv2 で正常にメタデータが取れるか確認
[ ] Auto Scaling の新インスタンス起動テスト（UserData が正常に動くか）
[ ] CloudWatch Logs エージェントが正常に動いているか
[ ] バックアップ・リストアの動作確認
[ ] セキュリティグループ・NACLへのアクセス確認
[ ] MySQL 移行済みの場合：主要クエリのスロークエリログ確認
[ ] 旧AL2インスタンスの保持期間を決める（最低1週間は残す）
まとめ
| フェーズ | ポイント |
|---|---|
| 事前調査 |
amazon-linux-extras・IMDSv1・python2 依存を洗い出す |
| 移行方針 | インプレースは不可。新AMIで作り直す |
| スクリプト修正 |
yum → dnf、amazon-linux-extras → dnf install
|
| MySQL同時移行 | Phase分けして原因を切り分けやすくする |
| 移行後 | AutoScalingの新インスタンス起動を必ずテスト |
AL2 EOL は 2026年6月30日。余裕があるうちに検証環境から移行を進めることを強く推奨する。
本記事は金融系Webサービスの実際の移行作業をベースに執筆しています。環境や構成によって手順が異なる場合があります。