Amazon Linux 2サポート終了は2026年6月30日、残り18日｜in-place更新の公式経路なし——放置EC2の確認手順

結論：6月30日を過ぎてもサーバは止まらない。だが「直らないサーバ」になる

AWSの標準OSとして長く使われてきた Amazon Linux 2（AL2）のサポートが2026年6月30日に終了する。残り 18日 だ。AWS公式FAQは終了日を「2026-06-30」と明記し、後継のAmazon Linux 2023（AL2023・サポートは2029年6月まで）への移行を求めている。

期限を過ぎてもEC2インスタンスは止まらない。問題は、サポート終了後のAL2が 新たな脆弱性に対するセキュリティ更新の提供対象から外れる ことだ。「動き続けるが、直らないサーバ」になり、取引先のセキュリティチェックでの指摘対象になる。数年前に構築して保守ベンダー任せのサーバは、高い確率でAL2のままだ。

厄介なのは、稼働中サーバのOSをその場で入れ替える公式のin-placeアップグレード経路が提供されていない ことだ。新しいAL2023環境を構築して載せ替える「作り直し型」の移行になり、Elastic Beanstalkではブルー/グリーンデプロイが必須と明記されている。残り18日で全移行が難しくても、「どのサーバがAL2か」の棚卸しは今日できる。

押さえるべき1点：EOL対応の第一歩は移行作業ではなく台帳化だ。「自社のEC2のうちAL2が何台あり、何の業務を担っているか」に即答できない状態こそが最大のリスクである。

何がいつ終わるか：AL2とAL2023の比較

出典はAWS公式FAQとAL2023ユーザーガイド。土台レベルの差分が多く、単なるバージョンアップではなくOS移行案件 として扱うべきだ。

なぜ「うちのAWS」が危ないのか：塩漬けクラウドの構造

クラウドは「作るのが簡単」だった分、プロジェクト単位で立てたまま台帳に載らず放置されたインスタンス が残りやすい。とくに2018〜2022年頃の構築なら、当時の標準OSがAL2だったため該当率が高い。

構築を外部委託し保守契約が切れたケースはさらに危ない。「AWSだから安全」という思い込みの下でOSだけが古くなるが、責任共有モデルでは ゲストOSのパッチ適用は利用者側の責任 だ。ベンダー任せのシステムを棚卸しする観点はレガシーシステム刷新をベンダーに相談する前の準備にまとめた。

移行先のAL2023ではSELinuxが有効（permissive）になり、BeanstalkのAL2023環境ではIMDSv1無効化（DisableIMDSv1）が既定でtrueになる。古いアプリが突然動かなくなる「移行の罠」 は、こうした既定値の差から生まれる。

残り18日でやる確認手順

1. AL2インスタンスを特定する。 各サーバで `cat /etc/os-release` を実行し「Amazon Linux 2」表記を確認する。台数が多ければAWS Systems Manager等で一括収集する。
2. 業務影響を紐づける。 AL2サーバごとに「何の業務が載っているか」「外部公開か」を台帳化し、外部公開系を最優先にする。
3. 保守ベンダーに書面で確認する。 「AL2該当の有無」「移行計画と完了予定日」「移行までの暫定対策」を文書で回答させる。
4. 移行方式を決める。 原則はAL2023の新環境を構築して載せ替える方式。コンテナ化やRDS等への寄せ替えを同時に検討すると次のEOLにも強くなる。
5. 間に合わないサーバの暫定策を決める。 公開範囲の最小化、セキュリティグループの絞り込み、監視強化など、パッチが出ない前提の防御を期限前に適用する。

チェックの勘所：手順2を飛ばして技術調査だけ進めると優先順位がつかず移行が止まる。経営に説明できる単位（この業務が載っている）で台帳を作ることが、予算と人手を引き出す最短路だ。

よくある質問（FAQ）

Q. 6月30日を過ぎるとEC2は止まるのか？ A. 止まらない。ただしサポート終了後は新たなセキュリティ更新の提供対象から外れ、以降に見つかる脆弱性は塞がれないまま残る。外部公開サーバほど放置の危険が時間とともに増す。

Q. なぜin-placeアップグレードできないのか？ A. AL2023はパッケージ体系・既定値がAL2と大きく異なり（DNF化、extras廃止、SELinux有効化、cron非搭載など）、AWSは稼働中サーバ上でのOS入れ替え経路を提供していない。公式ガイドは新環境でテストして移行する手順を示し、Beanstalkではブルー/グリーンが必須とされる。

Q. 期限までに間に合わない場合、延長サポートを買えるか？ A. AWS公式FAQに終了日を延長する有償オプションの記載はない。露出の最小化と監視強化で時間を稼ぎつつ、移行完了日を切って進めるしかない。AL2023は2029年6月までサポートされる。

発注・更改判断に落とすための確認観点

システム開発や基盤更改の記事を読むときは、ニュースそのものよりも自社の要件に変換できるかが重要である。確認すべきは、対象システム、利用部門、業務影響、現行保守の期限、データ移行の難易度、権限・ログ・監査要件、移行中の業務継続方法である。

特にRFPや要件定義では、製品名やベンダー名を先に書くと比較が歪む。先に書くべきなのは、処理量、可用性、権限、監査、移行制約、運用体制である。ニュースをきっかけに検討を始める場合でも、発注書には自社の制約条件を具体化して入れる必要がある。

GXOへ相談する前に整理しておくと早い情報

相談前には、現行システムの概要、利用人数、主要業務、連携先、保守期限、障害履歴、困っている改修、予算感、希望時期をまとめる。詳細な仕様書がなくても、画面・帳票・データの棚卸しから要件を復元できる。

90日で要件定義へ進めるロードマップ

最初の30日は、現行業務と現行システムの棚卸しに使う。画面、帳票、データ、連携、利用者、例外処理、障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書よりも現場の運用が正になっているため、担当者ヒアリングも必要である。

31日目から60日目は、刷新・更改の目的を決める。保守期限への対応だけなのか、業務改善、データ活用、AI導入、セキュリティ強化まで含めるのかで、要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。

61日目から90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限、ログ、監査、非機能、移行、テスト、保守、運用体制を含める。ニュースを見て急いで製品選定に入るより、この90日を使って発注側の物差しを整える方が、失敗コストは小さい。

よくある失敗パターン

第一の失敗は、ニュースをきっかけに製品選定から始めることだ。製品名を先に決めると、要件定義が後付けになり、現行業務の例外や移行制約が漏れる。まず現行業務、データ、権限、帳票、連携、非機能を整理する必要がある。

第二の失敗は、移行を軽く見ることだ。新システムを作るより、現行データを正しく移し、業務を止めずに切り替え、利用者を教育する方が難しいことが多い。移行方式、並行稼働、切り戻し、移行後の照合を要件に入れない発注は危険である。

第三の失敗は、保守運用を見積もりから外すことだ。システムは公開して終わりではない。権限変更、法改正、障害、脆弱性、データ増加、連携先変更に対応する体制が必要になる。初期開発費だけで比較すると、運用で破綻する。

成果物として残すべきもの

発注前には、業務フロー、機能一覧、権限マトリクス、帳票一覧、データ一覧、連携一覧、非機能要件、移行方針、受入テスト方針を残す。完璧な仕様書でなくても、これらがあるだけで見積もりの精度とベンダー比較の質は大きく上がる。

判断表：読むだけで終わらせないための整理

この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。

公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。

いつGXOに相談すべきか

• AWS上に 何のOSのサーバが何台あるか把握できておらず、棚卸しから支援がほしい
• 構築ベンダーが不在になった 「塩漬けクラウド」のAL2023移行（再構築・コンテナ化含む） を任せたい
• EOL対応を機に 取引先セキュリティチェックに耐える構成への再設計 までやり切りたい

GXOはレガシーシステム刷新で棚卸しからOS・基盤更改までを伴走し、脆弱性診断で外部公開資産の露出評価を、DX/システム開発で移行を機にした再構築を支援している。→ 相談はこちら

関連記事

• SQL Server 2016延長サポート終了は2026年7月14日｜基幹パッケージの裏で動くDBの棚卸し
• Windows 10サポート終了まで半年｜企業が今やるべき移行チェックリスト
• レガシーシステム刷新をベンダーに相談する前の準備｜現行調査・移行範囲・見積比較チェックリスト

追加確認：社内展開時の合意形成

社内でこの記事を共有する場合は、単にURLを回覧するだけでは不十分である。関係部門に対して、対象有無、対応期限、必要な判断、次回会議で決めることをセットで伝える。情報共有だけで終わると、誰も担当しないまま時間が過ぎる。

また、対応を急ぐほど、後から見たときの判断根拠が重要になる。なぜ今対応するのか、なぜ今回は見送るのか、どの一次情報を見たのか、誰が承認したのかを簡単に残す。短いメモでも、監査・稟議・次回対応の引き継ぎに使える。

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

• AWS「Amazon Linux 2 FAQs」（サポート終了日2026-06-30）
• AWS「Amazon Linux 2023 FAQs」（AL2023は2029年6月までサポート）
• AWS「Comparing AL2 and AL2023」（DNF・cgroup v2等の差分）
• AWS「SELinux（AL2023ユーザーガイド）」（SELinux有効・permissiveが既定、AL2では無効）
• AWS「Prepare your migration to AL2023」（extras廃止・Python 2.7→3・cron→systemdタイマー）
• AWS「Migration from Amazon Linux 2 to Amazon Linux 2023（Elastic Beanstalk）」（ブルー/グリーン必須・DisableIMDSv1既定true）

本記事は2026年6月12日時点の公開情報をもとに作成。サポート期限・移行ガイダンスは更新され得るため、AWS公式の一次情報の最新版を必ず確認すること。