Amazon Linux 2のサポート期限は終了済み｜影響と移行先、移行手順を解説

Amazon Linux 2のサポート期限は2026年6月30日で、すでに終了しています。インスタンスは今日も問題なく起動しますが、AWSによる標準のセキュリティ更新の対象外となりました。

終了によって何が止まったのか、自社のどこにAL2（Amazon Linux 2）が残りやすいのか、そして後継のAmazon Linux 2023を含む移行先の選び方と手順を整理します。

Amazon Linux 2のサポート期限はいつ終了したか

Amazon Linux 2のサポート期限は2026年6月30日で、すでに経過しています。

2度の延長を経て確定した経緯と、Amazon Linux全体のバージョン別の期限、そしてAL2がどのような用途で使われてきたOSなのかを整理します。

Amazon Linux 2のサポート終了日

Amazon Linux 2のサポートは2026年6月30日に終了しました。

AWSの公式FAQに終了日として記載されており、カーネル、glibc、OpenSSL、OpenSSHなどのコアパッケージは、AWSによる標準のセキュリティ更新とバグ修正の対象外となりました。再起動なしで脆弱性を修正する「カーネルライブパッチ」も同様です。

Amazon Linux 2には延長ライフサイクルサポート（ELS）プログラムがなく、終了日以降の延長や例外、追加の支援オプションも用意されていません。

参考:「AWS」Amazon Linux 2 のよくある質問
参考：Get ELS for RHEL 7 and AL2 for Amazon EC2（AWS re:Post）

延長の背景と注意すべきポイント

この日付は、2度の延長を経て確定したものです。当初は2023年6月末での終了が予定されていましたが、本番環境での利用が広がっていたため、AWSは期限を2026年6月30日まで延ばしました。その後の延長はなく、猶予期間はすでに終わっています。

後継のAmazon Linux 2023（AL2023）は、四半期ごとのマイナー更新を軸にしたサポートモデルを採用しています。

AL2とAL2023ではベースとなるOS設計が異なるため、移行は既存環境の上書き更新ではなく「新しいOSへの載せ替え」に相当します。設定ファイル、パッケージ、カーネルに差異があるため、事前検証を挟む前提で計画を組みます。

参考：Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support（AWS News Blog）

Amazon Linuxのバージョン別サポート期限

Amazon Linuxはこれまで4つのバージョンがあり、それぞれの期限を押さえておくと移行先の判断が早くなります。

AL2023は、2027年6月30日までの標準サポート期間中は四半期ごとの機能更新を受け取れます。その後は2029年6月30日まで、セキュリティ更新と重大なバグ修正に限って提供されます。AL2027はプレビューが公開された段階のため、現時点で移行先を決めるならAL2023が現実的な選択肢になります。

参考:「AWS」Amazon Linux 2023 release cadence
参考：Release cadence – Amazon Linux 2027

【関連記事】【2026年最新】AWSサービス終了情報を総まとめ！公式発表の確認方法と移行のポイントを解説 | 株式会社ハートビーツ（HEARTBEATS Corporation）｜AWS・クラウド・サーバーなどのインフラ運用を24時間365日サポート

Amazon Linux 2の特徴と用途

Amazon Linux 2（AL2）は、AWSが提供するRPMベースのLinuxディストリビューションで、AWS環境向けに最適化されたOSです。軽量で高速な設計に加え、AWS CLIなどのAWS連携ツールを標準搭載しています。

EC2のAMI（Amazon Machine Image）として即利用でき、追加費用も不要なため、多くの企業で本番・検証環境の基盤として採用されてきました。RPMベースのOSで扱う形式やコマンド体系が共通するため、既存アプリやスクリプトの移行が容易です。ECSやEKSといったコンテナ基盤のベースOSとしても利用され、AWSサービス運用におけるデファクトスタンダードとなっています。

参考：Comparing AL2 and AL2023
参考：Amazon Linux 2（AWS）

自社にAmazon Linux 2が残っていないか確認する

対応の出発点は、AL2がどこに何台残っているかを正確に洗い出すことです。EC2のOS一覧だけを見ていると取りこぼしが起きるため、確認コマンドと、見落としが起きやすい場所の両方を押さえます。

EC2インスタンスのOSを確認する

インスタンスにログインできるなら、/etc/os-releaseと/etc/system-releaseを読めばOSを判別できます。Amazon Linux 2であれば、PRETTY_NAMEに「Amazon Linux 2」と表示されます。

台数が多い環境では、1台ずつログインするより、AWS Systems ManagerのインベントリやフリートマネージャーでマネージドインスタンスのOS名とバージョンを一覧取得するほうが確実です。AWS Configのリソース一覧や、起動テンプレートが参照しているAMI名から拾う方法もあります。amzn2で始まるAMI名は、AL2ベースと判断できます。

見落としやすい5つの場所

EC2のインスタンス一覧だけでは、AL2の残存を把握しきれません。見落としが起きやすいのは、次の5か所です。

1つ目はAuto Scalingグループの起動テンプレートです。稼働中のインスタンスをAL2023に入れ替えても、起動テンプレートがAL2のAMIを指したままだと、スケールアウトのたびにAL2が復活します。

2つ目はECSのコンテナインスタンスで、ECS最適化AMIのAL2版で動いているクラスターは同じ日付で期限を迎えています。

3つ目はEKSのノードグループです。AL2ベースのマネージドノードグループには、Kubernetes 1.33以降のAMIが提供されません。

4つ目はコンテナのベースイメージです。Dockerfileがamazonlinux:2を参照していれば、イメージの中身はOSと同じ期限を迎えています。

5つ目はAMIを作る仕組みそのもので、PackerやEC2 Image Builderのレシピ、Elastic BeanstalkのAL2ベースのプラットフォームブランチが該当します。

なかでも1つ目と5つ目は、移行が終わったつもりでもAL2が自動的に再生成される経路になるため、棚卸しの段階で押さえておくと手戻りを防げます。

Amazon Linux 2サポート終了後の影響

サポート終了後も、AL2のインスタンスは起動し、アプリケーションも動き続けます。止まるのは更新と支援の提供であり、その影響はセキュリティ、運用、コンプライアンスの3方向に及びます。

セキュリティ更新の停止

AWSからのパッチや修正が提供される保証がないため、既知の脆弱性は攻撃者の格好の標的になります。ゼロデイやランサムウェアの脅威が日々発見される現状では深刻で、とくにインターネットに接続したサーバーは被害リスクが高いといえます。

【関連記事】脆弱性対策とは？企業が取り組むべき4つのステップを解説！ | 株式会社ハートビーツ（HEARTBEATS Corporation）｜AWS・クラウド・サーバーなどのインフラ運用を24時間365日サポート

技術サポートの打ち切り

サポート終了日以降、障害や不具合は自社や外部ベンダーで対応することになり、時間とコストが増加します。新しいAWSサービスや機能の対象外となるため、長期的な改善も期待できなくなります。

参考：Get ELS for RHEL 7 and AL2 for Amazon EC2（AWS re:Post）

コンプライアンス・監査上のリスク

金融・医療・公共機関など、情報セキュリティ基準の遵守が求められる業界では、サポート切れOSの利用が重大なコンプライアンス違反となり得ます。ISMSやPCI DSSなどの認証維持にも支障をきたし、内部・外部の監査でも是正指摘を受けやすくなります。取引先から届くセキュリティチェックシートでも、サポート切れOSの有無が確認項目に含まれることがあります。結果として追加投資や改善計画が求められ、運用負荷が高まる可能性もあります。

サポート終了後に取り得る4つの選択肢

AL2が残っていた場合に取り得る対応は、大きく4つです。恒久的な解決になるのはAL2023などへの移行か、OS管理そのものを手放すマネージド化で、継続利用とサードパーティの延長サポートは移行までのつなぎという位置づけになります。
判断を分けるのは、移行先の準備にどれだけ時間が必要かという一点です。

in-place upgradeができない点に注意する

AL2からAL2023へのin-place upgrade、つまり既存環境を上書きするアップグレードはサポートされていません。Windows Serverのように、稼働中のサーバー上でコマンドを実行してOSだけを入れ替える進め方は取れません。

AL2023への移行は、新しいインスタンスを構築し、アプリケーションと設定を移し、動作確認のうえで切り替える流れになります。サーバー台数が多いほど、この構築とテストの工数が対応期間を左右します。AL2にはWindows ServerのESU（Extended Security Updates）に相当するAWS公式の有償延長サポートもないため、期限を延ばす前提の計画は立てにくいのが実情です。

参考:「AWS」Amazon Linux 2 のよくある質問
参考：Get ELS for RHEL 7 and AL2 for Amazon EC2（AWS re:Post）

そのまま使い続ける

サポート終了後もAL2のインスタンスは起動し、アプリケーションも動き続けます。ただしセキュリティ更新が保証されないため、移行作業が進行中で切り替えまでの期間が限られている場合の一時的な状態として扱う選択肢になります。

コンテナ化・マネージド化する

FargateやLambdaへ作り替え、OSの管理そのものをなくす進め方です。アプリケーションの改修を伴うため準備期間は長くなりますが、OSのサポート期限に左右されない構成へ移せます。

サードパーティの延長サポートを使う

TuxCareなどのサービスを利用し、AL2向けの更新提供を継続する方法です。費用がかかるうえ、移行そのものが不要になるわけではないため、移行先の準備に時間が必要な場合のつなぎという位置づけになります。

Amazon Linux 2からの移行先OS

移行先の第一候補は、Amazon Linux 2023です。長期サポートやマルチクラウド環境での共通運用を重視するなら、RHEL系やUbuntuも検討の余地があります。

Amazon Linux 2023の特徴と注意点

Amazon Linux 2023（AL2023）は、AL2の後継としてAWSが提供するディストリビューションで、現時点の移行先の第一候補です。Fedoraの複数バージョンやCentOS Stream 9などから構成されたRPMベースのパッケージ構成を採用し、新しいカーネルとglibcを搭載しています。標準サポートは2027年6月30日まで、その後のメンテナンスフェーズは2029年6月30日までです。

AWSとの親和性は高く、EC2やECSとの統合も容易です。一方で、AL2との互換性は完全ではありません。設定ファイルやパッケージ名が変わっている場合があり、アプリケーションやスクリプトの修正が生じることもあります。移行前に検証環境で動作確認を行う前提で計画を組むと、切り替え後の手戻りを抑えられます。

後継のAmazon Linux 2027は2026年9月にプレビューが公開された段階で、本番環境の移行先として選べるのは一般提供後です。

AL2023以外にも、長期サポートや運用互換性を重視した移行候補があります。

参考：「AWS」Amazon Linux 2023 release cadence
参考：Release cadence – Amazon Linux 2027
参考：Announcing Amazon Linux 2027（AWS What’s New, 2026年9月）

Amazon Linux 2とAmazon Linux 2023は何が違うか

AL2023はAL2の後継ですが、内部の仕組みは別物です。移行時に確認したい主な違いを整理します。

つまずきやすいのは3点です。

Python 2系に依存したスクリプトは、そのままでは動きません。運用で使っている小さなスクリプトほど見落とされやすく、移行後に定期処理が止まってから気づくことがあります。

amazon-linux-extrasやEPELから導入していたパッケージも、AL2023では同じ手順で入手できません。ミドルウェアのバージョンが変わる場合も多いため、何をどこから入れていたかを先に一覧化しておくと作業が進めやすくなります。

cronやrsyslogを前提にした運用手順も見直しが要ります。AL2023ではsystemdタイマーとjournaldが既定のため、既存の手順書やログ収集設定をそのまま持ち込むと、ジョブが動かない、ログが集まらないといった問題が起きます。

参考:「AWS」Comparing Amazon Linux 2 and Amazon Linux 2023
参考：AL2 supported kernels
参考：Updating the Linux Kernel on AL2023

RHEL / Rocky Linux / AlmaLinux

これらはRHEL互換ディストリビューションで、標準で10年のサポート期間が設けられています。商用サポートを重視するならRHEL、無償での長期利用ならRocky LinuxやAlmaLinuxが候補になります。AWS公式AMIも提供され、マルチクラウドやオンプレミス環境との統一運用が可能です。

ただし、AWS CLIやSSM Agentの標準搭載といったAWSサービスとの統合度はAmazon Linux 2023ほど高くなく、EC2やECS環境では追加設定が生じることがあります。

Ubuntu

UbuntuはDebian系で、新しいソフトウェアの取り込みが早く、開発環境やWebシステムに向いています。LTS版は標準で5年間、Ubuntu Proを利用すれば10年のサポートを受けられます。

ただし、RHEL系を前提とした運用ツールや商用アプリケーションを使っている場合、設定や管理方法を大きく見直すことになります。

参考:「Canonical」Ubuntu release cycle

選定時に考慮すべきポイント

移行先OSの選定においては、以下の観点を総合的に評価することが重要です。

• サポート期間と更新ポリシー：長期運用か、短期で最新機能を追うか。
• 互換性と移行コスト：既存アプリや運用スクリプトをどの程度修正する必要があるか。
• サポート体制：商用サポート契約の有無、コミュニティの活発さ。
• AWS最適化度：EC2やECSなどのAWSサービスとの統合度合い。

適切なOSを選定することで、移行後の安定稼働と運用負荷の低減を両立することができます。AL2はすでにサポートが終了しているため、候補の比較と検証には早めに着手しましょう。

Amazon Linux 2からの移行方法

移行は、棚卸しから検証、計画策定、構築、段階的な切り替えという流れで進めます。最初の棚卸しと検証を省くと、切り替え後に業務が止まる原因になります。

【関連記事】サーバー移行とは？移行先の選定ポイントや実施手順、注意点を解説 | 株式会社ハートビーツ（HEARTBEATS Corporation）｜AWS・クラウド・サーバーなどのインフラ運用を24時間365日サポート

現行環境の棚卸しと移行方針の整理

移行の出発点は、現行環境を正確に把握することです。稼働中のEC2インスタンス、利用OS、パッケージやミドルウェア、依存関係を洗い出します。さらにシステムの重要度や可用性要件を踏まえ、一括で切り替えるか段階的に進めるかという方針を決めます。AWS ConfigやSSM Inventoryを使えば効率的に棚卸しが可能です。EC2以外の残存箇所は、前述の5か所をあわせて確認します。

移行先OSの選定

棚卸しの結果をもとに、Amazon Linux 2023、RHEL系、Ubuntuなどから最適なOSを選びます。評価軸と候補の絞り込み方は、前章「選定時に考慮すべきポイント」で整理したとおりです。

移行先OSでの検証（PoC）

検証環境でアプリケーションの動作とパフォーマンスを確認します。設定やパッケージ名、カーネルやglibcの違いが影響するため、網羅的なテストが必要です。確認対象は主要機能だけでなく、定期ジョブ、ログ収集、監視通知、Python 2系に依存したスクリプト、extrasやEPEL由来のパッケージまで広げます。AWSでは一時的なEC2インスタンスや、Systems ManagerのAutomationで検証を自動化できます。

移行計画の策定

検証結果を踏まえ、移行スケジュールや作業手順、ロールバック（切り戻し）方法、関係者への周知方法などを定めます。停止を避けたいシステムではブルーグリーンデプロイやローリングアップデートでダウンタイムを最小化します。

構築・検証と段階的な移行

新OS環境の構築・検証を行い、移行計画に沿って優先度の低いシステムから段階的に切り替えていきます。移行後はログやメトリクスを監視し、異常があれば迅速にロールバック（切り戻し）できる体制を維持します。すべてのシステムが安定稼働した後、旧環境を完全に廃止します。

【関連記事】失敗しないAWS移行の進め方｜移行方式の選び方とよくある課題・対策 | 株式会社ハートビーツ（HEARTBEATS Corporation）｜AWS・クラウド・サーバーなどのインフラ運用を24時間365日サポート

ECS・EKSで動いている場合の進め方

ECSとEKSでは、ノードとコンテナイメージの両方を確認します。ECSのコンテナインスタンスは、AL2023版のECS最適化AMIに差し替えるか、この機会にFargateへ移してOS管理そのものをなくす進め方があります。EKSのマネージドノードグループは、AL2023またはBottlerocketをベースにした新しいノードグループを追加し、Podを移してから旧ノードグループを削除する手順が基本です。

いずれの場合も、コンテナイメージのベースがamazonlinux:2のままでは、ノードだけ更新してもイメージの中のOSはサポート切れのままです。

ハートビーツのクラウド移行・導入支援

台数が多い環境ほど、AL2の移行は棚卸しと検証に時間がかかります。ハートビーツは、AWSアドバンストティアサービスパートナーとして、現行システムのヒアリング・調査から、移行計画とスケジュールの策定、サーバーの設計・構築、アプリケーションの動作確認と切り替えまでを支援しています。移行後は、フルマネージドサービスによる24時間365日の監視運用へそのまま引き継げます。社内に移行を任せられる技術者がいない場合も、現状の整理からご相談いただけます。
※クラウド移行・導入支援は、フルマネージドサービスをご利用のお客様向けのオプションサービスです。

移行にかかる期間と費用の目安

移行期間は、台数と構成の複雑さでおおよそ決まります。費用は内製か外部委託かで構造が変わり、外部委託では並行稼働中のEC2費用が二重にかかる点を見込んでおくと、見積もりのずれを防げます。

いずれも一般的な目安で、ミドルウェアのバージョン差やPython 2系の資産が多いほど期間は延びます。内製の場合、費用の中心は担当者の工数です。外部に委託する場合は、構築・移行作業の委託費に加えて、新旧環境を並行稼働させる期間のEC2費用が重なります。予算を組むときは、この二重計上の期間をどれだけ短くできるかが効いてきます。

移行時の注意点

計画どおりに進めても、移行では想定外のトラブルが起きます。互換性、設定ファイル、セキュリティポリシー、ダウンタイム、切り戻しの5つは、事前に手を打っておくと影響を抑えられます。

互換性の事前確認不足

AL2と移行先OSでは、パッケージ構成や設定が異なる場合が多くなります。とくにAmazon Linux 2023はFedora由来の新しいパッケージ構成のため、古いライブラリに依存したアプリケーションが動かない可能性があります。検証環境で全機能を確認し、必要に応じて修正を加えます。

参考：Relationship to Fedora

設定ファイルやパスの変更

移行先OSでは、設定ファイルの配置や命名規則が変わることがあります。そのため、各種スクリプトや設定が機能しなくなる恐れがあります。移行前に設定ファイルの差分を洗い出し、移行時に修正できる状態にしておくと安全です。

セキュリティポリシーの差異

移行先OSによっては、SELinuxやファイアウォールの初期設定が厳格になり、適切に許可を設定しないとサービスが動かない場合があります。検証段階で挙動を確認し、本番切り替えの前に必要な例外設定を追加しておきます。

ダウンタイムの過小見積もり

移行作業では、停止時間を最小化する工夫が必要です。ブルーグリーンデプロイやローリングアップデートを採用しても、DNS切替やセッション維持に想定以上の時間がかかることがあります。事前に影響時間を試算し、関係者と調整しておくと当日の混乱を避けられます。

ロールバック（切り戻し）計画の不備

重大な不具合が起きたときに旧環境へ戻れる体制を整えておきます。AMIスナップショットやバックアップからの復元手順を事前に検証し、復旧にかかる時間と方法を明確にしておきます。切り戻しの道筋がないまま本番切り替えに踏み切ると、被害が広がります。

Amazon Linux 2のサポート期限に関するよくある質問

AL2のサポート終了をめぐって、現場で質問が集まりやすい論点を整理しました。とくに押さえておきたいのは、起動できることとサポートされていることが別だという点です。既存のAMIやスナップショットからAL2のインスタンスを立ち上げる操作自体は止められていませんが、新しい脆弱性が見つかっても修正が届く保証はありません。

参考:「AWS」Amazon Linux 2 のよくある質問

まとめ

本記事では、Amazon Linux 2の基本情報とサポート期限、終了後の影響、移行先OSの比較、移行方法、注意点について解説しました。サポート終了は単なるOS更新の問題ではなく、セキュリティやコンプライアンスに直結する課題です。移行計画の早期策定と、検証・段階的移行の実施が不可欠といえます。AWSやクラウド環境に最適化されたMSPサービスを活用することで、限られたリソースでも安全かつ確実な移行が可能になります。

ハートビーツでは、移行支援を含めて、お客様のクラウド環境に対する課題を解決するためのサービスを豊富に提供しています。移行作業の委託をご検討されている企業様は、ぜひ一度ハートビーツにご相談ください。