EOL（End of Life）とは

EOL（End of Life）とは、ソフトウェア、ハードウェア、またはサービスの「サポート終了」を意味します。ベンダーやコミュニティがそのプロダクトに対する公式なサポート、アップデート、セキュリティパッチの提供を終了する日付を指します。

---

EOLの種類

1. End of Support（EOS）

一般的なサポートの終了。バグフィックスや機能追加が停止されるが、セキュリティアップデートは継続される場合があります。

2. End of Extended Support（EOES）

延長サポートの終了。通常のサポート期間後、有償で提供される延長サポートも含めてすべてのサポートが終了します。

3. End of Life（EOL）

完全なサポート終了。セキュリティパッチを含むすべてのアップデートが停止されます。

4. End of Sale（EOS）

販売終了。新規の購入やライセンス取得ができなくなりますが、サポートは継続される場合があります。

---

EOLのリスク

セキュリティリスク

最も深刻なリスクです。EOL後のソフトウェアは：

• 脆弱性が修正されない: 新たに発見された脆弱性に対するセキュリティパッチが提供されない
• 攻撃対象になりやすい: EOL製品の脆弱性は公開情報として広まり、攻撃者の標的になりやすい
• コンプライアンス違反: PCI DSS、HIPAA、SOC2などのセキュリティ標準に違反する可能性

運用リスク

• 互換性の問題: 新しいハードウェアやソフトウェアとの互換性が保証されない
• バグが修正されない: 既知のバグが放置される
• 技術サポートの終了: トラブル時にベンダーからのサポートを受けられない

ビジネスリスク

• システム障害時の長期停止: サポートがないため、障害の復旧に時間がかかる
• 保守コストの増加: 社内で独自に対応する必要があり、コストが増大
• 監査での指摘: セキュリティ監査やコンプライアンス監査で問題視される

---

主要ソフトウェアのEOL一覧

OS

プログラミング言語ランタイム

AWS Lambdaのランタイムサポート:

注意: AWS LambdaのランタイムEOLは、AWS Health Dashboardで確認できます。EOL後も一定期間は関数を実行できますが、新規作成やアップデートができなくなります。

データベース

ミドルウェア

フレームワーク

---

EOL対応の基本戦略

1. EOL情報の継続的な監視

実施すべきこと:

• 使用しているすべてのソフトウェアのバージョンを台帳管理
• 公式サイトのEOLスケジュールを定期的にチェック
• EOL通知を受け取れるようメーリングリストに登録

推奨ツール:

• endoflife.date: 主要ソフトウェアのEOL情報を集約したサイト
• Snyk: 依存関係の脆弱性とEOL情報を自動スキャン
• Dependabot: GitHubの依存関係更新通知
• AWS Systems Manager: EC2のパッチ適用状況を管理
• AWS Health: LambdaランタイムやRDSエンジンなど、AWSリソースのEOL通知

2. 計画的なバージョンアップ

EOL 12ヶ月前:

• 影響範囲の調査
• 移行計画の策定
• 予算確保

EOL 6ヶ月前:

• 開発環境での検証開始
• 互換性問題の洗い出し
• 必要な改修作業の実施

EOL 3ヶ月前:

• ステージング環境での検証
• 本番移行計画の確定
• ロールバック手順の準備

EOL 1ヶ月前:

• 本番環境への適用
• 動作確認
• 監視体制の強化

3. 段階的な移行アプローチ

Blue-Green Deployment

新バージョン環境を並行構築し、切り替え後も旧環境を一定期間保持します。

メリット:

• ロールバックが容易
• ダウンタイムが最小限

デメリット:

• 一時的にリソースが2倍必要

Canary Release

一部のトラフィックのみ新バージョンに流し、徐々に比率を増やします。

メリット:

• リスクを最小化できる
• 問題の早期発見

デメリット:

• 移行期間が長くなる

4. EOL後の緊急対応

やむを得ずEOL後も使用を続ける場合の対策：

セキュリティ対策:

• WAF（Web Application Firewall）での保護強化
• IPSによる不正アクセス検知
• ネットワークセグメンテーション
• アクセス制限の厳格化

監視強化:

• 異常なトラフィックの検知
• ログの詳細な分析
• セキュリティスキャンの頻度増加

リスク受容:

• 経営層への報告とリスク受容の承認
• インシデント発生時の対応計画
• 保険の検討

---

EOL管理のベストプラクティス

1. ソフトウェア資産管理（SAM）

すべてのソフトウェアを一元管理：

# 管理すべき情報
- ソフトウェア名
- バージョン
- インストール場所（サーバー、環境）
- ライセンス情報
- EOL日
- 担当者
- 依存関係

2. 自動化されたバージョン検出

Infrastructure as Code:

• Terraform、CloudFormation等でインフラをコード化
• バージョン情報を明示的に管理

コンテナイメージ管理:

• ベースイメージのバージョンを固定
• 定期的なイメージの再ビルド

依存関係管理:

• package.json、requirements.txt、go.mod等でバージョンを明示
• 定期的な依存関係の更新

3. EOLポリシーの策定

組織としてのポリシーを定める：

原則：
- EOL 6ヶ月前までに移行を完了
- EOL後の使用は原則禁止
- 例外はセキュリティチームの承認が必要

責任：
- 開発チーム：アプリケーションレベルの対応
- インフラチーム：OS・ミドルウェアレベルの対応
- セキュリティチーム：リスク評価と承認

4. 定期的なレビュー

月次:

• 6ヶ月以内にEOLを迎えるソフトウェアのリストアップ
• 移行進捗の確認

四半期:

• 使用中のソフトウェアバージョンの棚卸し
• EOL管理プロセスの見直し

年次:

• 長期的なロードマップの策定
• 予算計画への反映

---

AWSにおけるEOL管理

AWS HealthでのEOL通知

AWS Healthを利用することで、LambdaランタイムやRDSエンジンなどのEOL情報を自動的に受け取ることができます。

AWS Health Dashboard（Personal Health Dashboard）:

• AWSアカウント固有のリソースに影響するイベントを表示
• LambdaランタイムのEOL通知
• RDSエンジンバージョンのEOL通知
• OSのEOL情報

確認できる主な情報:

• Lambda: 使用中のランタイム（Python 3.8、Node.js 16等）のEOL日と影響を受ける関数リスト
• RDS: 使用中のデータベースエンジンバージョンのEOL日と対象のDBインスタンス
• EKS: Kubernetesバージョンのサポート終了情報
• EC2: AMIで使用されているOSのサポート終了情報

AWS Health APIの活用:

import boto3

# AWS Healthクライアントの作成
health = boto3.client('health', region_name='us-east-1')  # Healthは us-east-1 のみ

# EOL関連イベントの取得
response = health.describe_events(
    filter={
        'eventTypeCategories': ['scheduledChange'],
        'services': ['LAMBDA', 'RDS']
    }
)

for event in response['events']:
    print(f"Service: {event['service']}")
    print(f"Event: {event['eventTypeCode']}")
    print(f"Start: {event['startTime']}")
    print(f"Description: {event['eventDescription']}")

EventBridgeとの統合:

# CloudFormation例
HealthEventRule:
  Type: AWS::Events::Rule
  Properties:
    Description: "Lambda EOL通知"
    EventPattern:
      source:
        - aws.health
      detail-type:
        - AWS Health Event
      detail:
        service:
          - LAMBDA
        eventTypeCategory:
          - scheduledChange
    State: ENABLED
    Targets:
      - Arn: !GetAtt NotificationTopic.Arn
        Id: SNSTopic

推奨アクション:

1. AWS Health Dashboardを定期的に確認（週次）
2. EventBridgeでSNS/Slackへの自動通知を設定
3. AWS Health APIを使った定期的なスキャン（日次バッチ）
4. 影響を受けるリソースのリストを自動生成

Amazon Linux 2 から Amazon Linux 2023 への移行

主な変更点:

• パッケージマネージャー: yum → dnf
• Python 2の非サポート
• SystemVの廃止、systemdのみ
• 5年のサポート期間（2028年まで）

移行手順:

1. Amazon Linux 2023のAMIで新規EC2を起動
2. アプリケーションの互換性テスト
3. Blue-Green Deploymentで段階的に切り替え

RDS for MySQL 5.7 から 8.0 への移行

注意点:

• 予約語の追加（RANK、SYSTEM等）
• GROUP BYの動作変更
• 認証プラグインの変更（mysql_native_password → caching_sha2_password）

移行手順:

1. RDSスナップショットからMySQL 8.0インスタンスを作成
2. アプリケーションの接続テスト
3. 本番DBのマイナーバージョンを最新化（5.7.44等）
4. メジャーバージョンアップグレード（5.7 → 8.0）
5. アプリケーションの動作確認

EKS Kubernetes バージョンアップ

Kubernetesのバージョンポリシー:

• 各バージョンのサポート期間：約14ヶ月
• 標準サポート終了後、延長サポート（12ヶ月、有償）

移行手順:

1. 新バージョンのEKSクラスター作成
2. アドオンの互換性確認（CoreDNS、kube-proxy等）
3. ワークロードの段階的移行
4. 旧クラスターの廃止

---

EOL情報の入手先

公式サイト

• Ubuntu: https://ubuntu.com/about/release-cycle
• Red Hat: https://access.redhat.com/product-life-cycles
• Python: https://devguide.python.org/versions/
• Node.js: https://nodejs.org/en/about/previous-releases
• MySQL: https://www.mysql.com/support/eol-notice.html
• PostgreSQL: https://www.postgresql.org/support/versioning/
• AWS: https://aws.amazon.com/jp/blogs/aws/

集約サイト

• endoflife.date: https://endoflife.date/
  • 800以上のプロダクトのEOL情報を集約
  • API提供あり
  • RSS/JSON形式で取得可能

---

まとめ

EOL対応は、セキュリティとシステムの安定稼働のために不可欠です。

重要ポイント:

1. 計画的な対応: EOLの6ヶ月以上前から移行を開始
2. 継続的な監視: 使用中のソフトウェアのEOL情報を常に把握
3. 自動化: ツールを活用してバージョン管理と検出を自動化
4. 組織的な取り組み: ポリシーを策定し、責任を明確化
5. 早めの更新: EOL直前ではなく、計画的にバージョンを最新化

EOLを正しく理解し、適切に管理することで、セキュリティリスクを最小化し、安定したシステム運用を実現できます。