Amazon Linux 2（以下、AL2）のサポート終了である2026年6月30日が目前となりました。現在も移行作業を進めている企業や、これから移行計画を具体化する企業も多いでしょう。本記事では、サポート終了に伴うリスクを正確に整理した上で、実際の移行時に現場で対応が必要となる具体的なシステム変更点について解説します。
1. AL2のサポート終了後も利用を続けるリスク
現在の環境のまま使い続けた場合に発生する、リスクや運用上の影響について整理します。
セキュリティのリスク
パッチ提供の終了：サポート終了後は、新たな脆弱性や不具合が発見されても、AWSから提供されるセキュリティパッチや不具合修正は提供されなくなります。
認証維持への影響：サポート切れOSを運用し続けることは、ISMSやPマーク、PCI DSSなどのセキュリティ監査において指摘事項となる可能性があります。適切なリスク対応が行われていない場合は、受審時の是正要求や認証維持そのものに影響を及ぼすことがあります。
コストと運用への影響
OS自体は無料：新OSであるAmazon Linux 2023（以下、AL2023）への切り替え自体には、OS自体のライセンス費用などはかかりません。
運用負荷の増加：AL2のサポートは終了するため、OS起因の問題について十分なサポートを受けられなくなります。障害対応や原因調査にかかる工数が増える可能性があり、万が一のインシデントによる損失を考えると、未移行のままでいる将来的な対応コストの方が結果的に高くなる傾向があります。
2. 移行時に合わせて対応したいシステム変更点
OSの移行は単なるサーバーの引っ越しではなく、ミドルウェアやアプリケーション環境を見直す良い機会となります。確実に対応を進めるために、あらかじめ現場で確認しておきたいポイントをまとめました。
PHP 8系への対応とLaravelのアップデート
AL2023ではPHP 8系が利用できます。利用可能なバージョンは記事執筆時点の情報であり、リポジトリの更新によって提供バージョンが変わる可能性があります。古いPHPはサポートされていないため、PHP 8.2などへのバージョンアップに合わせて、Laravelなどのフレームワークのアップデートや、使用している外部ライブラリの互換性対応も同時に対応を検討するとよいでしょう。
PythonやOpenSSLの仕様変更への対応
Python 2.7の廃止とコマンドの変更：AL2023ではPython 2.7が完全に削除されています。また、デフォルトでは /usr/bin/python というコマンド自体が用意されていないため、自社で動かしている古い運用監視スクリプトなどがあればPython 3系への対応（スクリプトの修正など）とコマンドパスの確認をしておきます。
OpenSSL 3.0への刷新：OpenSSL 3ではProvider機構が導入され、一部のAPIや暗号アルゴリズムの扱いが変更されています。利用しているライブラリや接続先によっては互換性の問題が発生する場合があるため、外部APIとの連携や古いランタイム・ライブラリが残っている場合は事前に接続テストをしておくと安心です。
パッケージ管理ツールとサーバー構築、SELinuxの設定
YUMからDNFへの変更：パッケージ管理ツールが従来の yum から dnf へ変更されています（yumコマンドも互換性のために残されていますが、中身はdnfです）。Ansibleやシェルスクリプトなどの自動構築スクリプトがある場合は見直しが必要です。
サーバー構築とSELinuxの確認：インプレース（上書き）アップデートは行えないため、新しくAL2023サーバーを構築して移行することになります。あわせて、SELinuxの設定も確認し、 /var/log/audit/audit.log を確認しながら必要に応じてポリシーや権限を調整しておくと、移行直後のアクセス拒否（Permission denied）などのトラブルを防げます。
忘れがちなデータ、周辺機能、各種エージェントの引っ越し
静的ファイルの同期：過去にユーザーが投稿したPDFや画像などはGitで管理していない（Git管理対象外）ことが多いため、rsyncやS3同期などを用いて手動で新サーバーへ移行させてリンク切れを防ぎます。
メール送信環境の確認：AL2023ではPostfixなどのメール送信ミドルウェアが初期状態ではインストールされていません。新しい環境ではメール送信環境を改めて構築する必要があります。この機会にAmazon SESなどのマネージドメールサービスへの切り替えを検討するのも選択肢の一つです。
空ディレクトリと権限：Laravelのログ出力先（storage/logsなど）といった、Git管理対象外のディレクトリを新サーバーに手動で作成し、Webサーバーへの書き込み権限を正しく設定しておきます。
各種エージェントの動作確認：AWS Systems Manager Agent（SSM Agent）やAmazon CloudWatch Agentなど、EC2上で動かしている利用中の各種AWSエージェント類もAL2023に対応した最新バージョンが正しく動作するか確認が必要です。
インフラ運用まわりの設定確認
Auto ScalingとLaunch Templateの更新：Auto Scaling GroupやLaunch Template（起動テンプレート）を利用している場合は、AL2023をベースに新しく作成したAMI（Amazonマシンイメージ）への差し替え設定を忘れずに実施します。あわせて、Launch Templateや各設定に組み込まれているUserData（インスタンス起動時に実行される初期設定スクリプト）の内容も合わせて確認します。
タスクスケジューラと独自サービス：従来のcron（crond）やsystemd timerが新環境でも意図通りに動作するかテストします。また、バックグラウンドで常駐させる独自サービスを登録している場合は、systemdユニットの記述と起動ステータスも合わせて確認します。
検証環境での動作確認と運用設計
本番切り替え前には、検証環境で十分な動作確認を行います。また、万が一のトラブルに備え、バックアップ取得方法や切り戻し手順も事前に整理しておくことをおすすめします。これにより、仕様変更に伴う予期せぬ挙動を未然に防ぐことができます。
3. 実務で使える「AL2023移行チェックリスト」
実際の移行作業や設計時に見落としがないか確認するためのチェックリストです。自社の環境に合わせてカスタマイズしてご活用ください。
- 利用中のPHPをAL2023で利用可能なPHP 8系へ更新し、互換性を検証する
- Laravelなど主要フレームワーク、外部ライブラリのアップデート
- 運用スクリプト等のPython 3対応とコマンドパスの確認
- OpenSSL 3への移行に伴う外部APIや既存ランタイムとの接続テスト
- パッケージ管理（yumからdnfへの変更に伴うスクリプト修正）
- 新規サーバー構築（インプレースアップデート不可への対応）
- SELinux設定（/var/log/audit/audit.logを用いた権限調整）
- Git管理対象外ファイル（PDF・画像等）の新サーバーへの同期
- Postfix等のメール送信環境の再構築（またはAmazon SES等への移行）
- ログ出力先などGit管理対象外ディレクトリの作成と権限設定
- 各種AWSエージェント（SSM, CloudWatch等）の最新化と動作確認
- Launch Template（AMI ID、UserData）およびAuto Scaling設定の更新
- cron（crond）およびsystemd timerの動作確認
- 独自常駐サービスのsystemdユニット設定確認
- 検証環境での総合テスト、バックアップ取得、切り戻し手順の策定
前編のまとめ
まずは直近の課題であるAL2023への移行を着実に完了させましょう。ミドルウェアのバージョンアップに伴うコード修正など確認項目は多岐にわたりますが、インフラ環境を健全かつ最新の状態に保つためには不可欠なプロセスです。
移行後も定期的なアップデートを継続し、次回のOS更新に備えることが重要です。Amazon Linuxでは一定のライフサイクルに沿って新しい世代が提供されるため、後編は「次の移行時の負担を軽減するための運用計画」について解説します。
