LASSIC Media らしくメディア
Amazon Linux 2 サポート終了への対応｜EOL対策とAL2023移行の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Amazon Linux 2のサポート終了（EOL）は2026年6月30日。AWS公式が明記しており、同日以降はセキュリティパッチ提供が停止します。
- 移行先のAmazon Linux 2023（AL2023）は2029年6月30日まで5年間のサポートが確保されており、無償で利用できます。
- パッケージ管理ツールの変更（YUM→DNF）やPython 2.7廃止など、移行には互換性確認が必要で、内製対応か外注判断が求められます。
目次
Amazon Linux 2のEOLとは何か
Amazon Linux 2のEOL（End of Life、サポート終了）とは、AWSがAmazon Linux 2（AL2）に対して提供してきたセキュリティパッチ・バグ修正・機能更新の提供を公式に終了する期日のことです。AWS公式FAQには「Amazon Linux 2 end of support date (End of Life, or EOL) will be on 2026-06-30」と明記されています*1。
EOL日と対象範囲
AWS公式が定めるEOL日は2026年6月30日です*1。この日を境に、Amazon Linux 2に対するセキュリティ更新・バグ修正・技術サポートが終了します。対象となるのは、Amazon EC2インスタンスのAMI（Amazonマシンイメージ）として利用しているAL2、およびAL2ベースのコンテナイメージです。
AWSはAL2の後継としてAmazon Linux 2023（AL2023）を2023年3月にリリースしており、すべてのユーザーに対してAL2023への移行を推奨しています*4。
サポート終了後のセキュリティリスクとコンプライアンス影響
EOL後もAL2上でシステムを稼働させること自体は技術的に可能です。しかし、セキュリティパッチが供給されない環境では、新たに発見された脆弱性が放置されるリスクが高まります。CVE（共通脆弱性識別子）による脆弱性情報が公開されても、修正パッチが入手できない状態が続くことになります。
PCI DSS（クレジットカード業界の国際セキュリティ基準）やISO 27001などのセキュリティ認証を維持している組織では、EOSのOSを本番環境で使用することが審査要件に抵触する可能性があります。サポートが切れたOSへの対応は、コンプライアンス審査においても重点確認事項となります。
移行しないリスク：稼働継続が招く具体的な影響
EOL後にAL2をそのまま使い続けた場合、想定されるリスクを整理します。第一に、新規CVEが公表されても修正パッチが提供されず、攻撃を受けた際の被害が拡大します。第二に、AWS Marketplace上の一部のソフトウェアはサポートされたOSバージョンのみを対象とするため、AL2向けのサポートを受けられなくなります。第三に、将来的にAWSがAL2向けのシステムアップデートを提供しなくなることで、AWSサービス連携（例：AWS SSM AgentやCloudWatch Agentの最新版）が機能しなくなるリスクがあります。
Amazon Linux 2とAmazon Linux 2023の主な違い
AL2023はAL2の単純なバージョンアップではなく、アーキテクチャ面での変更点が複数あります。移行前に主要な変更点を把握しておくことが、作業の見積もりと計画策定に直結します*3。
パッケージ管理：YUM から DNF へ
AL2ではYUM（Yellowdog Updater Modified）がデフォルトのパッケージマネージャでした。AL2023ではYUMの後継に当たるDNF（Dandified YUM）がデフォルトに変更されています*3。基本的なコマンド構文（install、update、removeなど）はほぼ互換性がありますが、一部のオプションや設定ファイルの記述方法が異なります。
自動化スクリプトやCI/CDパイプライン内でyumコマンドを直接呼び出している場合、dnfへの書き換えが必要になります。AL2023ではyumコマンドはDNFのシンボリックリンクとして提供されているため、多くのケースで互換性は保たれますが、YUM専用プラグインを利用しているケースでは個別対応が求められます。
Python 2.7の廃止とPython 3への移行
AL2ではPython 2.7がデフォルト環境として利用可能でしたが、AL2023ではPython 2.7が削除されています*3。Python 3が標準となり、Python 2系のコードやライブラリを使用しているアプリケーションはPython 3への移植が必要です。
Python 2系ライブラリ（boto2、paramiko 2系など）に依存した社内ツールや運用スクリプトが残っている場合、移行前に全棚卸しと対応方針の策定が必要です。
ネットワーク管理とsystemdの変更点
AL2ではネットワークインターフェースの管理にISC dhclientを使用していました。AL2023ではsystemd-networkdがデフォルトのネットワーク管理サービスとして採用されています*3。ネットワーク設定ファイルの記述形式が変わるため、カスタムネットワーク設定を持つ環境では設定の移植作業が必要です。
また、AL2023ではcgroupv2（Unified Control Group hierarchy）が採用されており、コンテナ運用（Dockerなど）においてもcgroupの設定・挙動の差異を確認する必要があります。ログ管理もrsyslogからsystemd journalへ変更されています。
| 項目 | Amazon Linux 2（AL2） | Amazon Linux 2023（AL2023） |
|---|---|---|
| パッケージ管理 | YUM | DNF（YUMの後継） |
| Python | Python 2.7 + Python 3 | Python 3のみ（2.7廃止） |
| ネットワーク管理 | ISC dhclient | systemd-networkd |
| ログ管理 | rsyslog | systemd journal（journald） |
| cgroup | cgroupv1 | cgroupv2（Unified階層） |
| タスクスケジューラ | cron | systemdタイマー（cron代替） |
| EBSデフォルト | gp2 | gp3 |
| サポート終了 | 2026年6月30日 | 2029年6月30日（Maintenance終了） |
Amazon Linux 2023移行の進め方（5ステップ）
AL2023への移行はインプレース（既存インスタンスのOS更新）ではなく、新しいAL2023 AMIを使った新規インスタンス起動による切り替えが推奨されるアプローチです。AWSの設計思想として、新しいインスタンスを作成してアプリケーションを乗せ替え、旧インスタンスを廃棄する「イミュータブルインフラストラクチャ」の考え方が前提となっています。
ステップ1：現環境の棚卸しと互換性確認
まずAL2で稼働しているすべてのインスタンスとコンテナを洗い出します。インスタンスごとに稼働しているアプリケーション、インストール済みパッケージ、カスタムスクリプト（Python/シェル）、cronジョブ、ネットワーク設定を記録します。
特に確認すべき点は、Python 2系のスクリプト依存、YUM専用プラグインの使用有無、rsyslogへの依存設定（ログ転送先など）です。AWS公式ドキュメントには「Package changes in AL2023」として、AL2からAL2023でのパッケージ追加・変更・削除の全リストが公開されています*3。
ステップ2：テスト環境でのAL2023動作検証
棚卸し結果をもとに、AL2023ベースのテストインスタンスを起動します。ここでの作業は本番環境には一切影響しないため、支障なく検証を進められます。アプリケーションの起動確認、各種スクリプトの実行確認、依存ライブラリのインストール確認をひととおり実施します。
テスト環境でエラーや互換性問題が見つかった場合、次のステップに進む前に対応方針を決めます。「AL2023対応の代替パッケージへの切り替え」「Pythonコードのバージョン移植」「設定ファイルの書き換え」などが主な対応メニューです。
ステップ3：アプリケーション・依存パッケージの修正
テスト環境で特定した互換性問題を解消します。Python 2系コードはPython 3への移植が必要です。cronジョブは、AL2023ではsystemdタイマーへの移行が推奨されますが、cronパッケージ自体はAL2023でも利用可能なため、段階的な対応が取れます。
ネットワーク設定（eth0の固定IPなど）はsystemd-networkdの設定ファイル形式（.networkファイル）での記述が必要となるケースがあります。ただし、EC2インスタンスでは多くの場合DHCPが使われるため、影響範囲は限定的です。
ステップ4：本番移行の実施（AMI更新・段階的切り替え）
テスト環境での動作確認が完了したら、本番移行に進みます。ブルーグリーンデプロイメントや段階的トラフィック切り替え（ロードバランサーのウェイト調整）を活用し、旧AL2インスタンスと新AL2023インスタンスを並行稼働させながら、段階的にトラフィックを移行します。
移行直前にはスナップショット（EBSのバックアップ）を取得することを強く推奨します。問題が発生した場合に旧AL2環境へのロールバックが必要になるため、AMIとスナップショットは移行完了確認後も一定期間保持してください。
ステップ5：移行後の監視と最終確認
AL2023環境への切り替え後、CloudWatch Metricsでインスタンスのリソース利用状況を監視します。エラーログ、アプリケーションの応答時間、バックグラウンドジョブの正常完了を確認します。
問題がない状態が一定期間（推奨：1〜2週間）継続したことを確認したうえで、旧AL2インスタンスを停止・終了します。これにより移行が完了となります。
移行作業で詰まりやすいポイントと失敗リスク
AL2→AL2023の移行は、OS間の変更点が広範囲にわたるため、事前調査が不十分なまま進めると本番トラブルにつながります。特に注意が必要なポイントを整理します。
DNFへの切り替えで起きるパッケージ依存関係エラー
AL2時代に独自リポジトリを追加していた場合、そのリポジトリがAL2023・DNFに対応しているとは限りません。例えば、サードパーティ製のモニタリングエージェントや独自ビルドのソフトウェアは、AL2023向けのパッケージが別途提供されているかを確認する必要があります。
EPEL（Extra Packages for Enterprise Linux）をAL2で利用していた場合も注意が必要です。AL2023向けのEPELは仕組みが変わっており、AL2時代と同じ手順では設定できません*3。移行前に利用しているすべての外部リポジトリのAL2023対応状況を確認します。
Python 2系依存アプリケーションが移行の主要な障壁になるケース
Python 2.7が廃止されたAL2023において、Python 2依存のレガシーコードは移行前に対処が必要です。ただし、AL2023ではAL2のコンテナイメージを別途使用することで、AL2023環境上でAL2コンテナを動かすという回避策も存在します。
とはいえ、この手法は短期的な移行期間中の緊急回避策にとどまります。Python 2系コードを長期間維持するとセキュリティリスクが残存するため、根本的なPython 3移植を計画に含めることを推奨します。
移行前にやるべき社内準備
技術的な移行作業と並行して、組織面での準備が移行の成否を左右します。具体的には、移行責任者の明確化、作業期間中の緊急対応フロー、業務システムの停止可能時間帯（メンテナンスウィンドウ）の合意が必要です。
AL2023移行を内製で実施する場合、Linux OS管理・AWS EC2操作・アプリケーションの互換性対応・移行後の監視設定という複数の技術領域を横断できる担当者が必要です。いずれかの知識が欠けていると、本番移行時のトラブル対応が後手に回ります。
内製移行 vs 外注移行：判断基準と費用感
AL2→AL2023の移行を内製で実施するか、外部パートナーへ委託するかは、自社のエンジニアリソースと移行の複雑度によって判断します。判断軸を整理します。
| 判断軸 | 内製移行に向く | 外注移行に向く |
|---|---|---|
| インフラ担当者 | AWS・Linuxの専任エンジニアが社内にいる | 運用担当者が兼務・少人数でリソース不足 |
| 移行対象の複雑度 | インスタンス数が少なく、依存関係がシンプル | 多数インスタンス・複雑な依存関係・独自リポジトリ多数 |
| Python 2系コード | ほぼPython 3移植済み | Python 2依存のレガシーコードが残存 |
| 許容停止時間 | 業務影響が少ない・メンテナンス時間が確保できる | 24時間稼働・停止時間がほぼ取れない |
| コンプライアンス | セキュリティ要件が標準的 | PCI DSS・ISO 27001等の審査対応が必要 |
外注移行の費用は、対象インスタンス数・アプリケーションの複雑度・移行期間によって大きく異なります。費用感については一次資料による数値の確認が難しいため具体的な数値は記載しませんが、一般的にはスポット型の移行支援から長期の伴走型サポートまで、複数の契約形態から選択できます。費用見積もりは複数のベンダーへの見積もり依頼を推奨します（市場参考値・一次資料ではありません）。
元請（プライムベンダー）として移行全体を管理できるパートナーを選ぶと、各工程での責任の所在が明確になり、トラブル時の対応が迅速になります。
まとめ：Amazon Linux 2 EOL対応の3つの判断軸
本稿では、Amazon Linux 2のEOL（2026年6月30日）に向けた対応策を整理しました。要点を3つに集約すると次の通りです。
第一に、EOL後もシステムは稼働しますが、セキュリティパッチが提供されなくなるリスクがあります。CVEへの無防備な状態や、PCI DSSなどのコンプライアンス要件との抵触を避けるためにも、計画的な移行が必要です。
第二に、移行先のAL2023はAWSが無償提供する後継OSで、2029年6月30日までサポートされます*2。パッケージ管理（YUM→DNF）、Python（2.7廃止→Python 3）、ネットワーク管理（dhclient→systemd-networkd）など複数の変更点があり、事前の互換性確認が不可欠です。
第三に、移行の内製化か外注化かは、社内エンジニアのリソースと移行の複雑度で判断します。インスタンス数が多い・Python 2依存が残存している・コンプライアンス対応が必要な場合は、外部の移行支援パートナーに委託することで、リスクを抑えた計画的な移行が期待できます。
よくある質問
Amazon Linux 2のEOL（サポート終了）はいつですか？
Amazon Linux 2のEOLは2026年6月30日です。AWS公式FAQに明記されており、同日以降はセキュリティパッチ・バグ修正・技術サポートの提供が終了します*1。EOL後もインスタンス自体は引き続き稼働しますが、新たな脆弱性に対するパッチが提供されなくなるため、早期の移行計画を推奨します。
Amazon Linux 2023への移行は無償でできますか？
はい、Amazon Linux 2023自体は無償で提供されています*4。ただし、AL2023を動かすEC2インスタンスの利用料金は通常どおり発生します。移行作業そのものは、社内エンジニアが実施する場合は人件費のみ、外部パートナーへ委託する場合はその委託費用が発生します。OS自体のライセンス費用は不要です。
Amazon Linux 2から2023へのインプレースアップグレードはできますか？
AL2からAL2023へのインプレースアップグレード（既存インスタンスのOS上書き更新）はサポートされていません。AL2023への移行は、新しいAL2023 AMIを使った新規インスタンスの起動と、アプリケーションの乗せ替えが推奨アプローチです。既存のAL2インスタンスを直接AL2023に更新することはできないため、新旧インスタンスを並行稼働させての段階的切り替えが現実的な移行方法になります。
Amazon Linux 2023のサポート期間はどれくらいですか？
AL2023は2023年3月にリリースされ、2029年6月30日までの5年間のサポートが提供されます*2。サポートは2フェーズに分かれており、Standard support（2027年6月30日まで）では四半期ごとのマイナーバージョン更新を受け取れます。Maintenance（2029年6月30日まで）ではセキュリティ更新と重大バグ修正のみ提供されます。
Amazon Linux 2023への移行にはどのくらいの期間がかかりますか？
移行期間は対象インスタンス数・アプリケーションの複雑度・Python 2系依存の有無によって大きく異なります。シンプルな構成の場合は数週間単位での移行も可能ですが、複数のアプリケーションが稼働する本番環境では、テスト環境での検証・修正・本番切り替えの工程を含め、数か月単位のスケジュールを確保することを推奨します。費用・期間の正確な見積もりは、構成調査を実施したうえで個別に判断する必要があります（市場参考値・一次資料ではありません）。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「Amazon Linux 2 FAQs」（2026年確認）
- *2 出典：AWS公式ドキュメント「Release cadence（Amazon Linux 2023）」（2026年確認）
- *3 出典：AWS公式ドキュメント「Comparing AL2 and AL2023」（2026年確認）
- *4 出典：AWS公式ドキュメント「What is Amazon Linux 2023?」（2026年確認）
