Amazon Linux 2のサポート終了後にどうする？2026年6月30日期限とAL2023移行の判断基準・手順【2026年版】
Amazon Linux 2（AL2）のサポートは、2026年6月30日をもって終了しました。すでに期限は過ぎています。
それでも、EC2で長く使われてきたOSだけに、「動いているから後回し」になっている環境は少なくありません。AWSの標準OSとして採用されたAL2は、Webサーバーやバッチサーバーだけでなく、ECSやEKSのノード、コンテナのベースイメージにも広く入り込んでいます。
AL2には、Windows ServerやSQL Serverのようなメーカー提供の有償延長サポート（ESU）がありません。さらに、後継のAmazon Linux 2023（AL2023）へはin-place upgrade（その場での上書きアップグレード）ができず、新しいサーバーを作って載せ替える方式が前提になります。この2点が、他製品のサポート終了対応と異なるところです。
本記事では、Amazon Linux 2のサポート終了後に何が止まるのか、自社にAL2が残っていないかを確認する方法、取り得る4つの選択肢と判断基準、AL2023へ移行する手順を整理します。
目次
想定読者
- EC2でAmazon Linux 2を使い続けており、サポート終了後の対応方針をまだ決めていない情報システム担当者・インフラ担当者の方
- AL2023との違いや、移行で何が壊れるかを把握したうえで計画を立てたい方
- ECS・EKS・Elastic Beanstalkなど、EC2以外の場所にもAL2が残っていないか棚卸ししたい方
- 監査や取引先のセキュリティ確認で「サポート切れOS」を指摘され、説明と対応計画が必要な方
Amazon Linux 2のサポートは2026年6月30日に終了した
AWSの公式FAQで、Amazon Linux 2のサポート終了日（EOL）は2026年6月30日と明記されています。当初は2023年6月末の予定でしたが、2度の延長を経てこの日付に確定しました。すでに3度目の延長はなく、期限は到来しています。
この日を境に、AL2に対して次の提供が止まりました。
- コアパッケージ（カーネル、glibc、OpenSSL、OpenSSHなど）へのセキュリティ更新とバグ修正
- カーネルライブパッチ（再起動なしでカーネルの脆弱性を修正する機能）
- AWSサポートによるAL2固有の問い合わせ対応
あわせて、Amazon ECS最適化AMIのAL2版も同じ2026年6月30日でサポート終了となりました。Amazon EKS向けのAL2 AMIはさらに早く、Kubernetes 1.32を最後に新規提供が打ち切られ、2025年11月26日以降はリリースされていません。
動き続けることと、使い続けてよいことは別
サポート終了は、インスタンスを止めるものではありません。既存のAL2インスタンスは今日も普通に起動し、アプリケーションも動作します。
ただし、新しい脆弱性が公表されても修正パッケージは配布されません。インターネットに面したWebサーバーであれば、脆弱性が公開された時点から攻撃の対象になります。社内向けのバッチサーバーであっても、PCI DSSやISMSの審査、取引先のセキュリティチェックシートでは「サポート切れOSの有無」が確認項目になっており、説明が難しくなります。
「動いているから問題ない」ではなく、「修正が来ない状態で何を守っているか」で判断する必要があります。
Amazon Linuxのバージョン別サポート期限一覧
Amazon Linuxの各バージョンについて、サポート期限を整理します。
| バージョン | リリース | サポート終了 | 備考 |
|---|---|---|---|
| Amazon Linux AMI（AL1・2018.03） | 2010年 | 2023年12月31日 | 終了済み。残っていれば最優先で対応 |
| Amazon Linux 2（AL2） | 2018年 | 2026年6月30日 | 終了済み。本記事の対象 |
| Amazon Linux 2023（AL2023） | 2023年3月 | 標準サポート 2027年6月30日 ／ メンテナンスフェーズ 2029年6月30日 | 現行版。移行先の第一候補 |
AL2023は、2027年6月30日までの標準サポート期間中は四半期ごとの機能更新を受け取れ、その後2029年6月30日まではセキュリティ更新と重大なバグ修正のみが提供されます。次のメジャーバージョンはおおむね2年ごとにリリースされる方針が示されており、AL2023へ移行しておけば当面のライフサイクルは確保できます。
まず自社にAL2が残っていないかを確認する
対応の第一歩は、AL2がどこに残っているかを正確に洗い出すことです。EC2のOSだけを見ていると、見落としが起こります。
EC2インスタンスのOS確認
インスタンスにログインできる場合は、次のコマンドでOSを確認できます。
cat /etc/os-release
cat /etc/system-releaseAmazon Linux 2であれば、PRETTY_NAMEに「Amazon Linux 2」と表示されます。台数が多い場合は、AWS Systems ManagerのインベントリやFleet Managerで、マネージドインスタンスのOS名とバージョンを一覧で取得するほうが確実です。AWS Configのリソース一覧や、起動テンプレートで参照しているAMI名（amzn2で始まるもの）から拾う方法もあります。
見落としやすい5つの場所
EC2以外にも、AL2は次のような場所に残っていることがあります。
- Auto Scalingグループの起動テンプレート：稼働中のインスタンスをAL2023に入れ替えても、起動テンプレートがAL2のAMIを指したままだと、スケールアウト時にAL2が復活する
- ECSのコンテナインスタンス：ECS最適化AMIのAL2版で動いているクラスターは、同じ日付でサポート終了になっている
- EKSのノードグループ：AL2ベースのマネージドノードグループは、Kubernetes 1.33以降のAMIが提供されない
- コンテナのベースイメージ：Dockerfileで amazonlinux:2 をベースにしているイメージは、OSと同じ期限を迎えている
- AMI作成の仕組み：PackerやEC2 Image Builderのレシピ、Elastic BeanstalkのAL2ベースのプラットフォームブランチ
とくに1と5は、移行が終わったつもりでも自動的にAL2が再生成される経路になるため、棚卸しの段階で必ず押さえておきます。
サポート終了後に取り得る4つの選択肢
AL2が残っていた場合、企業が取り得る対応は大きく4つに整理できます。
| 選択肢 | 概要 | 向いているケース | 主な注意点 |
|---|---|---|---|
| そのまま使い続ける | 何も対応せず、AL2のまま稼働させ続ける | 移行作業中の一時的な状態としてのみ許容できる | セキュリティ更新が来ない状態で運用することになる。恒久策にはならない |
| AL2023へ移行する | 新規にAL2023のインスタンスを構築し、アプリケーションを載せ替えて切り替える | ほとんどのEC2ワークロード。AWSが推奨する標準の移行先 | in-place upgradeができないため、構築・テスト・切り替えの工数が必要 |
| コンテナ化・マネージド化する | ECS FargateやLambdaなど、OSの管理をAWSに委ねる形に作り替える | アプリケーションの改修余地があり、今後もOSのEOL対応を繰り返したくない場合 | アプリケーション側の設計変更が伴い、移行期間が長くなる |
| サードパーティの延長サポートを使う | TuxCareなどが提供するAL2向けの延長ライフサイクルサポートで、セキュリティ更新を受け続ける | 移行先の準備に時間がかかる基幹系で、期限までの時間を買いたい場合 | AWS公式の提供ではない。別途費用がかかる。恒久策にはならず、移行までのつなぎ |
in-place upgradeという逃げ道がない
Windows Serverであれば、上位バージョンへのインプレースアップグレードが選択肢になります。一方、AL2からAL2023へのin-place upgradeはサポートされていません。既存インスタンス上でコマンドを実行してOSだけを入れ替える、という進め方はできないと考えてください。
そのため、AL2023への移行は「新しいインスタンスを構築し、アプリケーションと設定を移し、動作確認のうえで切り替える」という流れになります。サーバー台数が多いほど、この構築とテストの工数が対応期間を決める要因になります。
AL2023はAL2と何が違うか
AL2023は、AL2の後継ではあるものの、内部の仕組みは別物です。移行時に確認が必要な主な違いを整理します。
| 項目 | Amazon Linux 2 | Amazon Linux 2023 |
|---|---|---|
| パッケージ管理 | yum | dnf（yumコマンドは互換のため残る） |
| 追加パッケージの入手 | amazon-linux-extras、EPEL | extrasは廃止。EPELは非対応。標準リポジトリから提供 |
| Python | Python 2.7が標準 | Python 2.7を廃止し、Python 3系のみ |
| カーネル | 4.14系（extrasで5.10系） | 6.1系 |
| ネットワーク設定 | dhclient | systemd-networkd |
| 定期実行 | cron（cronieが標準） | systemdタイマー（cronieは必要に応じて追加インストール） |
| ログ | rsyslog | systemd journal（journald） |
| cgroup | v1 | v2 |
| SELinux | 無効 | 有効（既定はpermissiveモード） |
| メタデータ取得 | IMDSv1・v2の両方 | IMDSv2が既定 |
| リポジトリの更新方式 | 常に最新を取得 | バージョン固定の決定論的アップグレード（明示的に更新先を指定） |
| AWS CLI | v1 | v2 |
| 標準JVM | OpenJDK | Amazon Corretto |
移行でつまずきやすい3つのポイント
Python 2系に依存したスクリプトは、そのままでは動きません。運用で使っている小さなスクリプトほど見落とされやすく、移行後に定期処理が止まってから気づくケースがあります。
amazon-linux-extrasやEPELから入れていたパッケージは、AL2023では同じ手順で入手できません。ミドルウェアのバージョンが変わることも多いため、何をどこから入れていたかを先に一覧化しておく必要があります。
cronやrsyslogを前提にした運用手順も見直しが必要です。AL2023ではsystemdタイマーとjournaldが既定になっているため、既存の運用手順書やログ収集の設定をそのまま持ち込むと、ジョブが動かない、ログが集まらないといった問題が起こります。
AL2の残存確認や、AL2023への移行方式の選定でお困りでしたら、c3index にお気軽にご相談ください。
AL2023への移行を進める5つのステップ
方針が決まったら、次の順序で進めます。最初の2ステップを省くと、切り替え後に業務が止まる原因になります。
- 棚卸し：EC2・Auto Scaling・ECS・EKS・コンテナイメージ・AMI作成の仕組みまで含めて、AL2が残っている場所と台数を一覧にする
- 依存関係と互換性の確認：Python 2系のスクリプト、extrasやEPEL由来のパッケージ、cron・rsyslog前提の運用手順、IMDSv1しか使えない古いSDKの有無を洗い出す
- 新環境の構築：AL2023のAMIから新しいインスタンスを作り、ミドルウェアと設定を載せる。EC2 Image BuilderやTerraform・CloudFormationで構築手順をコード化しておくと、複数台への展開と次回のEOL対応が楽になる
- 並行稼働とテスト：本番と同じデータ・同じ負荷で動作確認を行い、定期ジョブ・ログ収集・監視通知まで含めて確認する
- 切り替えと旧環境の保持：ロードバランサーの振り分け先を新環境に変えるBlue/Green方式、またはAuto Scalingグループの起動テンプレートを差し替えて順次入れ替える方式で切り替える。切り替え後も一定期間はAL2の環境を停止状態で残し、問題が出た場合に戻せるようにしておく
ECS・EKSで動いている場合
ECSのコンテナインスタンスは、AL2023版のECS最適化AMIに差し替えるか、この機会にFargateへ移してOS管理そのものをなくす選択肢があります。EKSのマネージドノードグループは、AL2023またはBottlerocketをベースにした新しいノードグループを追加し、Podを移してから旧ノードグループを削除する手順が基本です。
いずれも、コンテナイメージのベースがamazonlinux:2のままでは、ノードだけ更新してもイメージの中のOSはサポート切れのままです。ノードとイメージの両方を確認してください。
移行にかかる期間と費用の目安
期間は、台数と構成の複雑さで変わります。あくまで目安ですが、Webサーバー数台の単純な構成であれば、棚卸しから切り替えまで数週間から1か月程度です。数十台・複数環境（本番・検証・開発）で、ミドルウェアのバージョン差やPython 2系の資産がある場合は、2〜4か月を見込むケースが多くなります。ECS・EKSを含む全社規模の基盤であれば、半年以上の計画になることもあります。
費用は、内製か外部委託かで構造が変わります。内製であれば主に担当者の工数、外部委託であれば構築・移行作業の委託費に加えて、並行稼働期間中のEC2費用が二重にかかる点を予算に入れておく必要があります。AWS構築を委託する場合の費用相場は、次の記事で規模別に整理しています。
移行後の運用まで含めて外部に任せたい場合は、AWS運用代行会社の比較も参考になります。
Windows Server・SQL Serverの期限と重ねて確認する
AL2の移行を検討するタイミングでは、同じAWS環境に残っている他のOSやミドルウェアの期限もあわせて確認することをおすすめします。
- Windows Server 2016は2027年1月に延長サポートが終了する
- SQL Server 2016は2026年7月に、SQL Server 2017は2027年10月に延長サポートが終了する
期限が1〜2年の範囲に集中しているなら、OSごとに個別に移行するより、環境全体の刷新として一度に計画するほうが、停止調整とテストの回数を減らせます。
よくある質問
Q. サポート終了後もAmazon Linux 2のAMIからインスタンスを起動できますか。
A. 既存のAMIやスナップショットから起動すること自体は可能です。ただし、起動できることとサポートされていることは別で、セキュリティ更新は提供されません。新規構築でAL2を選ぶ理由はなく、AL2023を使ってください。
Q. AL2からAL2023へ、コマンドでアップグレードできますか。
A. できません。AL2からAL2023へのin-place upgradeはサポートされておらず、AL2023のインスタンスを新しく構築してアプリケーションを移す方式が前提です。
Q. AWSからAL2の有償延長サポートは提供されていますか。
A. Windows ServerのESUのようなAWS公式の有償延長サポートはありません。延命が必要な場合は、TuxCareなどサードパーティが提供するAL2向けの延長ライフサイクルサポートを利用する方法がありますが、移行までのつなぎと位置づけるべきものです。
Q. AL2023を使うと追加料金はかかりますか。
A. かかりません。AL2023はAL2と同様、EC2の利用料金のみで追加のライセンス費用なしに利用できます。
Q. yumコマンドを使った既存の手順書は、AL2023でも使えますか。
A. AL2023ではdnfが標準のパッケージ管理ツールですが、互換のためyumコマンドも残されています。ただし、amazon-linux-extrasは廃止されているため、extrasを使ってミドルウェアを入れていた手順は書き換えが必要です。
まとめ
- Amazon Linux 2のサポートは2026年6月30日に終了済み。インスタンスは動くが、セキュリティ更新は提供されない
- ECS最適化AMIのAL2版も同日で終了。EKS向けAL2 AMIは2025年11月26日で提供が止まっている
- AL2にはAWS公式の有償延長サポートがなく、AL2023へのin-place upgradeもできない。新規構築による移行が前提
- 棚卸しではEC2だけでなく、Auto Scalingの起動テンプレート・ECS/EKSのノード・コンテナのベースイメージ・AMI作成の仕組みまで確認する
- AL2023はdnf・Python 3のみ・systemdタイマー・journald・cgroup v2・IMDSv2既定など内部が作り直されている。extrasとEPELが使えない点は移行前に確認する
- 移行は棚卸し → 互換性確認 → 新環境構築 → 並行稼働とテスト → 切り替えと旧環境保持の5ステップで進める
期限はすでに過ぎていますが、今からでも計画的に進めれば十分に対応できます。どこにAL2が残っているかを正確に把握し、移行方針を決める日を先送りしない。この2つが対応の出発点です。
c3indexでは、AWSアドバンストティアサービスパートナーとして、AL2の残存調査からAL2023への移行設計・構築・切り替え、移行後の運用代行までを一貫してご支援しています。対応方針でお悩みでしたら、まずは現状をお聞かせください。
CATEGORIES
