EC2 上で動いている業務システムの OS を、最後にメジャーバージョンごと上げたのはいつでしょうか。
こう聞くと、多くの現場で返ってくるのは「動いているので触っていない」です。それ自体は妥当な判断で、動作中のシステムを理由なく触るべきではありません。問題は、触らない判断が有効なのはサポート期限までで、期限は自社の都合とは無関係に来ることです。
2026年9月、AWS が Amazon Linux の4年ぶりとなるメジャーバージョン「Amazon Linux 2027」をパブリックプレビューとして公開しました。プレビュー段階なので本番で使う話ではありません。ただし、このリリースは AL2023 で動いている環境の期限を数える出発点になります。
2027年の標準サポート終了と2029年の最終期限を分ける
Amazon Linux 2023 のサポートは2029年6月30日までですが、この期間は2つに分かれています。
| 段階 | 終了時期 | 提供される内容 |
|---|---|---|
| 標準サポート | 2027年6月30日 | 四半期ごとのマイナーバージョン更新 |
| メンテナンスサポート | 2029年6月30日 | セキュリティ修正と重大な不具合の修正のみ |
2027年6月を過ぎると、新しいパッケージや機能の更新は届かなくなります。 セキュリティ修正は続くので即座に危険になるわけではありませんが、新機能が必要な場合は別の導入方法や OS 移行の検討が必要になることがあります。
2029年を期限として計画を立てていると、実際には2027年半ばから身動きが取りにくくなります。2027年は検討の節目、2029年は OS のサポート終了として分けて管理します。すべての環境が2027年までに移行必須という意味ではありません。個別パッケージの期限も dnf supportinfo --show installed で確認します。
SELinux が既定で強制モードになる
AL2027 で挙動が変わる箇所のうち、既存アプリケーションに最も影響するのがここです。
AL2023 では SELinux は既定で permissive（許可）モードでした。ポリシーに反する動作を検出はしますが、実際には止めません。AL2027 ではこれが enforcing（強制）モードになり、ポリシーに反する動作は実際にブロックされます。
permissive モードを前提に動いていたアプリケーションは、移行時にポリシーの調整が必要になる可能性があります。調整の途中で業務を止めないために、一時的に permissive へ戻すこともできますが、それは移行が完了していない状態です。
止まりやすいのはどこか
SELinux で引っかかるのは、標準的な構成から外れている部分です。実務でよく問題になるのは次のようなケースです。
独自のディレクトリにファイルを書くアプリケーション。 /var/www や /var/log の外、たとえば /opt/自社アプリ/data のような場所へ書き込む構成は、ファイルの SELinux ラベルとプロセスのドメインの組み合わせによっては拒否されます。独自パスだから必ず拒否されるわけではありません。
標準以外のポートで待ち受けるサービス。 番号の知名度では判断できません。サービスのドメインが、そのポートに割り当てられた型への bind を許可されているかを確認します。
別のプロセスのファイルを直接読み書きする連携。 バッチ処理が Web アプリの生成ファイルを直接触るような、プロセス境界をまたぐ設計は影響を受けやすい部分です。
これらは、いずれも「動いているから正しい」と判断されてきた箇所です。移行で壊れるのは新しく作った部分ではなく、長く動いてきた部分のほうです。
SELinux 以外に変わるところ
移行の検証範囲を見積もるうえで、押さえておくべき変更が他にもあります。
- カーネルが 7.1 系になる。 古いカーネルモジュールに依存した監視エージェントやドライバは、対応版が出ているかの確認が要ります
- パッケージ管理が DNF5 になる。 構築を自動化しているスクリプトが、オプションの書き方の違いで失敗することがあります
- 暗号処理が AWS-LC 中心になり、耐量子暗号への対応が入る。 独自にビルドした OpenSSL に依存しているアプリケーションは確認対象です
- x86-64-v3 を前提にビルドされている。 古い世代のインスタンスタイプで動かす前提だった場合、インスタンスの世代も一緒に上げることになります
保守を外部に委託している場合、これらのどこまでが契約の範囲に入っているかは分かれます。保守契約に何が含まれるかを、期限から逆算して確認しておく時期です。
検証の順番
プレビュー段階でやるべきことは、移行そのものではなく、移行にどれだけかかるかを測ることです。
- いま動いている OS のバージョンと、その標準サポート終了日を書き出す。 AL2、AL2023 が混在しているケースが多く、まず一覧が要ります
- SELinux を permissive のまま有効にして、AL2023 上で警告を集める。 ここで出るログが、AL2027 でブロックされる候補です。移行前に、いまの環境で採れます
- 警告が出た箇所を、設定変更で直せるか、アプリの修正が要るかで仕分ける。 この仕分けの結果が、移行の工数そのものになります
- プレビュー環境で、いちばん警告の多かったサーバーを1台だけ立ち上げる。 全台の検証はまだ不要です
この2番が重要です。AL2023 の監査ログは早期の棚卸しに使えます。ただし OS とポリシーが変わるため、AL2027 上の検証を置き換えるものではありません。 監査ログ（/var/log/audit/audit.log）に記録される拒否ログを数週間ぶん集めれば、現行環境での拒否候補を整理できます。
つまずきやすいところ
「プレビューだから来年考える」で1年が過ぎる。 標準サポート終了が2027年6月なので、検証と修正の期間を考えると、着手の目安は2026年中です。言語やランタイムの移行と同様に、期限が近づくほど選択肢は減ります。
SELinux を無効化して回避しない。 移行を急ぐと SELINUX=disabled で通す判断が出てきますが、それは AL2027 を選ぶ理由の1つを捨てることになります。permissive で運用しながらポリシーを整える段階を挟んでください。
検証環境と本番環境の構成差を先に潰す。 検証機だけ SELinux を切っていた、というケースはよくあります。この状態では、検証を通っても本番で止まります。
次にやること
稼働中の EC2 インスタンスの OS バージョンを一覧にして、標準サポート終了日を横に書いてください。2027年6月より前の行があれば、それが今期の計画に載せる対象です。
そのうえで、SELinux が有効になっているサーバーで拒否ログが出ているかを確認してください。すでにログが出ている箇所を、移行検証の優先候補にできます。
既存システムの OS 移行の影響範囲の調査、SELinux ポリシーの整理、保守の範囲に期限管理を組み込む設計については、グリームハブの開発・AI・自動化のご相談で承っています。構成と運用体制によって進め方が変わるため、範囲は個別にお見積りします。お問い合わせからご相談ください。
