主要クラウドのLinuxサポート最新動向まとめ｜選定時の着眼点

クラウドのLinuxサポートが運用リスクに直結する理由

クラウド上でLinuxインスタンスを運用する場合、ディストリビューションのサポート期限はオンプレミス以上に重要な意味を持ちます。クラウドプロバイダーは独自のパッケージリポジトリやカーネルパッチを提供するケースが多く、アップストリームのサポート終了（EOL）とクラウド側の提供終了タイミングが必ずしも一致しないためです。

EOLを迎えたイメージをそのまま使い続けると、セキュリティパッチが当たらないだけでなく、クラウドプロバイダーが提供するエージェント（モニタリング・SSM・ゲスト拡張機能など）も順次サポート対象外となり、運用ツールの整合性が崩れていきます。2025年から2026年にかけては複数の主要ディストリビューションがEOLを迎えるサイクルが重なっており、移行計画の立案が急務になっている現場も少なくありません。

AWS（Amazon EC2）の主要ディストリビューション動向

AWSで広く使われてきた Amazon Linux 2（AL2）は、2025年6月30日をもってメインストリームサポートが終了しました。以降はセキュリティ更新のみの「メンテナンスサポート」フェーズへ移行しており、新規ワークロードでの採用は推奨されません。後継の Amazon Linux 2023（AL2023） がAWSの現行標準イメージとなっており、Fedoraをアップストリームに置いたローリングリリースモデルを採用しています。

AL2023の特徴として、デフォルトで SELinux が Enforcing モードで有効化されており、iptables が nftables バックエンドに切り替わっている点があります。AL2から移行する際はこれらの差異が想定外の動作差を生むことがあり、移行前の検証環境での確認が欠かせません。また、AL2023はメジャーバージョン（2023.x）単位でサポートライフサイクルが定められており、今後は年次リリースサイクルで更新される見通しです。

RHEL互換ディストリビューションとしては、Rocky Linux 9・AlmaLinux 9 が EC2 マーケットプレイスおよびコミュニティ AMI として利用可能です。RHEL 8 は2029年5月まで延長サポート（ELS）が提供される予定ですが、新規構築であれば RHEL 9（またはその互換系）を選ぶのが自然な流れです。Ubuntu については、20.04 LTS（Focal）が2025年4月にスタンダードサポートを終了しており、現時点では 22.04 LTS（Jammy） または 24.04 LTS（Noble） が採用候補となります。

Microsoft Azure・Google Cloud の Linux サポート状況

Microsoft Azure では、独自ディストリビューションとして Azure Linux（旧称 CBL-Mariner）が継続的に開発されています。軽量なフットプリントと Azure エコシステムとの親和性が設計思想の中心であり、AKS（Azure Kubernetes Service）のノードOSとしても採用が進んでいます。汎用ワークロード向けには RHEL・Ubuntu・Debian・SUSE Enterprise Linux がファーストパーティ扱いでサポートされており、Azureポータルからのパッチ管理（Azure Update Manager）との統合が整備されています。

Azureでは特に、Extended Security Updates（ESU） を Azure 上でホストされたインスタンスに限り無償提供する仕組みが RHEL・Ubuntu の一部バージョンで適用されています。これはオンプレミス環境との重要な違いであり、本来有償になるESUがクラウド移行のインセンティブとして機能することがあります。ただし適用条件や期間はバージョンごとに異なるため、Azure公式ドキュメントで個別に確認することが必要です。

Google Cloud（GCP）では、Container-Optimized OS（COS） がGKEノードの標準OSとして位置付けられています。汎用VMについては Debian・Ubuntu・RHEL・Rocky Linux・AlmaLinux がサポートイメージとして提供されており、OS Config エージェントを通じたパッチ管理が可能です。Debian については、2026年時点では Debian 12（Bookworm）が安定版であり、GCPのデフォルトイメージもこのバージョンが採用されています。Debian 11（Bullseye）は LTS サポートが継続していますが、新規採用する理由は薄くなっています。

2026年時点の主要サポート期限と切り替えポイント

2026年現在、運用担当者が特に注意すべきサポート期限のポイントを整理します。

• Ubuntu 20.04 LTS（Focal）：2025年4月にスタンダードサポート終了。Ubuntu Pro（有償）の ESM を使えば2030年まで延長可能ですが、新規インスタンスでの採用は避けるべきフェーズです。
• Amazon Linux 2：2025年6月にメインストリームサポート終了。AL2023への移行が正式推奨。2026年6月まではセキュリティパッチのみ提供予定。
• RHEL 8 / 互換系（Rocky 8・Alma 8）：2029年5月まで延長サポートあり。ただし RHEL 9 互換系との機能差が広がりつつあるため、余裕のあるうちに移行計画を立てるのが得策です。
• Ubuntu 22.04 LTS（Jammy）：スタンダードサポートは2027年4月まで。現時点では安定した選択肢のひとつです。
• Ubuntu 24.04 LTS（Noble）：2024年4月リリース、サポートは2029年4月まで。新規構築での採用が増えています。

注意すべきは、クラウドプロバイダーが提供するエージェントやドライバー類（例：AWS SSM Agent、Azure VM エクステンション、GCP Ops Agent）が EOL イメージへの新機能追加を打ち切るタイミングが、アップストリームのEOLより早い場合があることです。セキュリティパッチが届いていても、オブザーバビリティや構成管理の機能が使えなくなるという事態が起こりえます。

クラウド選定・ディストリ選定での着眼点

どのクラウドでどのLinuxを選ぶかは、単純なサポート期限だけでなく、以下の観点を組み合わせて判断することが実務上の標準になっています。

1. 既存の運用ツールチェーンとの親和性
Ansible・Terraform・Chef などの構成管理ツールで使っているモジュールやロールが、移行先のOSバージョンに対応しているかを先に確認します。特にパッケージ名の変更・サービス管理の差異・Python バージョンの違いは、Ansible プレイブックの動作に影響することがあります。

2. コンプライアンス・ライセンス要件
FIPS 140-2/3 準拠が必要な環境では、RHEL またはその互換系を選ぶケースが多くなっています。RHEL のサブスクリプション費用を抑えたい場合は Rocky Linux や AlmaLinux が選択肢になりますが、商用サポート契約（例：Percona・OpenLogic）を別途手配する運用も現場では見られます。

3. コンテナ・Kubernetes との統合度
ワークロードの大半がコンテナベースであれば、ノードOSとして最適化されたイメージ（EKS最適化AMI・AKSのAzure Linux・GKEのCOS）を選ぶことでパッチサイクルの管理負荷を大幅に削減できます。汎用ディストリビューションを使う場合でも、immutable なノードイメージ運用（ノードの更新はインスタンス置き換えで行う）を採用する現場が増えており、特定バージョンへの固執が薄れる傾向があります。

4. マルチクラウド・ハイブリッド構成での統一性
複数のクラウドにまたがってインフラを展開する場合、ディストリビューションを統一しておくことで、パッチポリシーや構成管理の手順を共通化できます。Ubuntu や RHEL 互換系は主要クラウドのどこでも利用可能なため、この観点からも採用しやすい選択肢です。Amazon Linux 系はAWS専用であるため、マルチクラウド戦略との相性は必ずしも良くありません。

2026年の現行環境を踏まえた運用上の留意点

2026年時点での実務上の変化として、クラウドプロバイダーによるパッチ管理サービスの成熟が挙げられます。AWS Systems Manager Patch Manager、Azure Update Manager、GCP OS Config のいずれも、スキャン・適用・レポートのワークフローが整備されており、手動でのパッチ作業をなくすことが実質的に可能になっています。ただし、これらのサービスがサポートするゲストOSの対応バージョン一覧は定期的に更新されているため、半年に一度程度は公式ドキュメントを確認する運用が推奨されます。

また、長期サポート版に対する過信も注意点のひとつです。LTS や延長サポートは「セキュリティパッチが届く」ことを意味しますが、ミドルウェアのバージョンアップに追随できなくなるケースが多く、アプリケーション側の要件（例：OpenSSL 3.x が必要、あるいは glibc のバージョン依存）とOSの提供バージョンが乖離していく問題が現場で報告されています。OS自体のEOLより先に、依存ライブラリ側の制約がボトルネックになる事例が増えているため、単純に「サポート期限内だから安全」とは言い切れない側面もあります。

ディストリビューションの選定とサポート期限の管理は、一度決めたら終わりではなく、年に一度は現行の提供状況と照合して見直すサイクルに組み込むことが、安定した運用体制の維持につながります。クラウド各社の公式サポートマトリックスやリリースノートをブックマークしておき、EOL通知を見逃さない仕組みを整えることが、現場での第一歩となります。