EOL？パッチ当て？ そんなの知るか！（上司）〜株式会社ジンベエ水産 EOL狂騒曲〜 / how can we operate eol management well

2026/8/7に開催されたJAWS-UG情シス支部のチョークトークです。

すでにEOLを迎えたAmazon Linux2...
EC2でなくてもLambdaでも各言語のバージョンの追従をしていく必要があり
情シスの管理者としては切っても切れないEOL（End of Life）、サポート切れが多くあります。
みんなその辺どうしてる？だいぶパワー要るよね？うまいやりかたとか無いかな？
ということをテーマにしてみんなでディスカッションしました。

Transcript

1. JAWS-UG 情シス支部 第35回勉強会 EOL？パッチ当て？ そんなの知るか！（上司） 〜株式会社ジンベエ水産 EOL狂騒曲〜 2026年8月7日(金)
2. チョークトークの進め方 チョークトークとは対話型のセッションで、学校の授業やゼミに近いものです 途中、質問があります 質問について発言したい方は手を挙げてください チョークトークはクイズではないので、正解も不正解もありません 積極的に発言と議論をして、みんなで知見の共有をしましょう！
3. 想定企業とシステムについて 株式会社ジンベエ水産 北の港町・鮫ヶ浦市の水産加工・食品メーカー。 BtoB卸が主力だが、ECサイト「ジンベエ市場」 が売上の2割に成長。 10年前にAWSを導入(オンプレからのリフト中心)。 70 年 850 名 120 億円 300 社 創業 従業員 売上規模 取引先企業 12 万人 20 % 10 年 4名 「ジンベエ市場」会員数 EC売上比率 AWS利用歴 情シス(兼任込み)
4. ジンベエ水産のシステム構成 基幹販売管理「UROKO」 ECサイト「ジンベエ市場」 EC2(Amazon Linux 2)×4台。 EC2+RDS for MySQL 5.7。 地元SIer「フカヒレ・ソリューションズ」製、保守契約あり 内製+スポット外注の継ぎ足し AL2 サポート終了済み MySQL 5.7 延長課金中 業務自動化 Lambda 約150本 その他 EC2 計38台 Python 3.8/3.9、Node.js 16/18が混在。 うちAL2が12台。 退職者の遺産でドキュメントなし タグ運用は「あってないようなもの」 EOLランタイム混在 正体不明 12台
5. 登場人物 ① 鮫島 蒼 鯨岡 剛 蟹江 守 さめじま・あおい くじらおか・つよし かにえ・まもる 32歳・情報システム課係長(主人公) 55歳・管理本部長 62歳・再雇用嘱託 中途入社5年目。 経理畑出身でコストに厳しい。 オンプレ時代からの生き字引。 AWSは独学+JAWS-UG通い。 説明されれば動くタイプ。 知識は頭の中にしかない。 真面目で抱え込みがち。 口癖 「動いてるんでしょ? 信条「動いているものは触るな」 なんでお金かかるの?」 ※ 参加者のみなさんは「鮫島さんに助言する先輩」の立場でご参加ください
6. 登場人物 ② 鰯田 若菜 海月 遊 いわしだ・わかな くらげ・ゆう 24歳・入社2年目 3年前に退職(名前だけ登場) 地元SIer 唯一の若手。 ドキュメントなしのLambda 150 基幹システムUROKOの開発元。 コンテナとIaCに興味津々。 本を残して去った伝説の人。 保守契約はあるが、 「全部作り直しましょう!」が先走り がち フカヒレ・ソリューションズ 契約範囲外は一切やらない。
7. TOPIC 1 / 8 ストーリー EOLは来てしまった 〜正体不明のAL2、12台〜 2026年6月30日、Amazon Linux 2 がサポート終了 。 把握していた分は移行済みのはずだった 7月の洗い直しで、AL2のEC2が12台残っていた 工場の帳票が絡んでるから絶対に触るな。 詳細は思い出せん Nameタグは「test-2019-copy-final2」。 作成者不明、SSH鍵も所在不明 パッチはもう出ない。それでも「触るな」と言われている 蟹江さん 62歳・再雇用嘱託。 オンプレ時代からの生き字引 信条「動いているものは触るな」
8. TOPIC 1 / 8 ディスカッション あなたなら、どうする? 1 この12台、まず何から手を付ける? 2 「用途不明だが止めるのが怖いサーバ」、どう白黒つける? 3 蟹江さんの「触るな」に、どう向き合う?
9. TOPIC 1 / 8 ベストプラクティス 正体不明サーバの白黒のつけ方 棚卸し: SSM Inventory / AWS Config / Resource Explorer+タグ戦略(Owner・System・EOL日) 利用実態の確認: CloudWatch・VPCフローログ・CloudTrailで「本当に使われているか」を見る 計画停止(スクリームテスト): 告知・スナップショット・切り戻し手順とセットで実施 移行は再構築前提: AL2→AL2023はインプレース不可。IaC化・ゴールデンAMIの好機。EC2不要ならFargate等へ 暫定リスク低減: SG最小化・ネットワーク隔離・IMDSv2強制
10. TOPIC 2 / 8 ストーリー 海月さんの遺産150本 〜ランタイムを上げたら即死した日〜 「[Action Required] Lambda end of support」 のメール、 去年の秋から放置されていた Lambda約150本:Python 3.8/3.9・Node.js 16/18混在。 トリガー不明、 テストコードはゼロ ランタイムの数字を変えるだけじゃ 済まないじゃないですか…… 試しにNode.js 16→22に上げたら即エラー : Cannot find module 'aws-sdk' 同梱SDK v2頼みのコード(そのv2も2025年9月にEOL済み)。 v3は書き味が別物 鰯田さん 24歳・入社2年目。 唯一の若手 コンテナとIaCに興味津々
11. TOPIC 2 / 8 ディスカッション あなたなら、どうする? 1 150本・テストなし・ドキュメントなし。どういう順番・基準で手を付ける? 2 応急処置(v2を同梱して延命)と書き換え(v3移行)、どう使い分ける? 3 「この際全部コンテナで作り直し」案に、先輩としてどう助言する? 8:00
12. TOPIC 2 / 8 ベストプラクティス 遺産Lambdaの棚卸しと移行戦略 まず集計: CLIでランタイム別に棚卸し+CloudWatchで直近90日の実行有無 → 動いていないものは上げずに消すのが最速 コードも棚卸し: grepで require('aws-sdk')=v2利用関数を特定し、ランタイム一覧と掛け合わせて「危険リスト」に 延命は期限付きで: v2同梱での延命は可能だが、v2自体が2025年9月にEOL済み。「期限を切った応急処置」と割り切る 恒久策はv3移行: aws-sdk-js-codemodやAWS Transformで機械的変換。コールドスタート改善のオマケも 教訓: EOL対応は数字の変更ではない。通知の整流化(Health→Slack)+標準ランタイムに絞る+IaC/CI/CD化で機械化
13. TOPIC 3 / 8 ストーリー 金曜18時の緊急速報 〜通称「メガロドン」脆弱性〜 金曜18時、Javaログライブラリに認証不要RCE・CVSS 9.8 (架空の「メガロドン」) ジンベエ市場は外部公開なのに脆弱性スキャン未導入 田舎の水産会社なんぞ誰も狙わんよ UROKOはJava製だがソース非公開で使用ライブラリ不明 。 フカヒレは週末連絡不能 大口取引先から「影響有無を48時間以内に回答されたし」 蟹江さん 62歳・再雇用嘱託。 オンプレ時代からの生き字引 信条「動いているものは触るな」
14. TOPIC 3 / 8 ディスカッション あなたなら、どうする? 1 金曜18時。今夜、何をどこまでやる?判断基準は? 2 ソース非公開のベンダー製。「使っているか」に即答できる? 3 「うちみたいな会社は狙われない」に、どう答える?
15. TOPIC 3 / 8 ベストプラクティス ゼロデイ速報への備えと初動 平時の可視化が全て: SSM Inventory+InspectorでCVE×資産の突合を自動化、Security Hub→Slack通知 SBOMを納品物に: 自社分はビルド時生成、ベンダーには契約で義務付け トリアージ: CVSSだけでなく「外部到達可能か・悪用実績(CISA KEV)・認証の内外」で判断 時間を稼ぐ: WAFの仮想パッチ+SG絞り込みで抑え、恒久対応へつなぐ 幻想を捨てる: 攻撃はスキャナで無差別。「うちは狙われない」は通用しない 回答テンプレ: 取引先向け(調査中・影響なし・対応中)を平時に用意しておく
16. TOPIC 4 / 8 ストーリー 明細の中の刺客 〜RDS延長サポート料、気づいたら2倍〜 請求書に謎の項目「RDS Extended Support」 。 この春から倍額に MySQL 5.7は2024年に標準サポート終了 → 自動で有償延長入り 、2026年3月から$0.20/vCPU時 この 「RDS Extended Support」 って 項目は何だ? 倍額になってるぞ フカヒレの見積:8.0化は互換性検証込みで350万円 その8.0も、開催のちょうど1週間前 (2026-07-31)に 標準サポート終了 鯨岡本部長 55歳・管理本部長。 経理畑出身でコストに厳しい 説明されれば動くタイプ
17. TOPIC 4 / 8 ディスカッション あなたなら、どうする? 1 延長サポート料を「保険料」として払い続けるのはアリ? 2 8.0で止める?8.4まで行く?Auroraへ乗り換える? 3 「検証に350万」——何を確認し、どう圧縮する?
18. TOPIC 4 / 8 ベストプラクティス 延長サポートとの付き合い方 「時間を買う保険」: 自動オプトイン+年次値上げの構造を理解して、意図的に使う 「まだ払えてしまう」が怖い: 5.7の延長は2029年6月まで。なし崩しの継続を避ける 着地点はEOLカレンダーで: 上げる先の期限まで見て決める。8.0に上げて即また延長、の二度手間を避ける 検証の型: Blue/Green Deploymentsで切替リスク圧縮。スナップショットから検証環境、 Performance Insightsで前後比較 数を減らす: DBが増えるほどEOL管理も増える。Auroraへの寄せ・統合も検討
19. TOPIC 5 / 8 ストーリー 「それ、売上いくら増えるの?」 〜経営への説明と予算〜 EOL対応の予算を役員会に諮ると、 「それで売上はいくら増えるの?」 蟹江さん 「ワシの頃はWindows Server 2003を10年使ったもんじゃ」。 動いてるのになんでお金がかかるの? それで売上はいくら増えるの? 援護のない会議室 翌週、大口取引先からセキュリティチェックシート 。 設問に「サポート終了したOS・ソフトウェアの使用有無」の欄 鯨岡本部長 55歳・管理本部長。 経理畑出身でコストに厳しい 説明されれば動くタイプ
20. TOPIC 5 / 8 ディスカッション あなたなら、どうする? 1 鯨岡本部長に、どんな言葉・どんな数字で説明する? 2 「EOL対応は売上を生まない」への切り返しは? 3 火が付く前の平時から、経営にやっておけることは?
21. TOPIC 5 / 8 ベストプラクティス 経営に通じるEOLの語り方 経営の言葉に翻訳: 「サポート切れ=保険の失効」「パッチが出ない=既知の穴が開きっぱなし」 効果は事業影響の回避で: EC停止1日=売上◯百万円、チェックシートNG=取引条件、サイバー保険の免責 1枚で見せる: EOL台帳を色分け(赤=超過/黄=1年以内)。同業のランサム事例は最強の教材 Run予算に織り込む: 特別プロジェクトにしない。導入起案時点で5年後の更改費までTCOに含める 松竹梅で選ばせる: 「やらない」も経営が選んだリスク受容として記録に残す
22. TOPIC 6 / 8 ストーリー 毎年2月は祭りである 〜RDSアップグレード祭り〜 月曜朝、受注バッチ遅延。 原因は デフォルトのままのメンテナンスウィンドウ で走った自 動マイナーアップグレード+再起動 蟹江さん「自動は全部切れ!」 これは単発のイベントじゃない。 毎年恒例の祭りなんだ vs 鰯田さん「逆に全部自動でよくないですか?」 RDSは8台 。 保留中メンテナンス3台、工場のPostgreSQL 13はEOL済み で 2台目の延長課金が発生中 マイナーバージョンは年数回、メジャーは毎年どれか切れる 鮫島さん 32歳・情報システム課係長(主人公) 中途入社5年目。 AWSは独学+JAWS-UG通い
23. TOPIC 6 / 8 ディスカッション あなたなら、どうする? 1 自動マイナーアップグレード、ON派?OFF派? 2 8台×年数回の「祭り」、どう回している? 3 メジャーアップの互換性検証、どこまでやれば「良し」? 議論
24. TOPIC 6 / 8 ベストプラクティス アップグレード祭りの回し方 台帳を1枚に: 全DBのエンジン/バージョン/サポート期限/メンテウィンドウ+保留中メンテの定期確認+RDSイベント通知→Slack ウィンドウは明示設定: デフォルト任せにしない。Multi-AZで停止最小化 定番運用: 検証は自動ONで先行検知 → 本番は同バージョンを計画適用。「ONでも適用はウィンドウ内」の仕様理解が説得の鍵 定例行事化: 年1回の「アップグレード祭り」として年間計画・予算に織り込む 検証の型: Blue/Green+スナップショット復元で本番同等検証、パラメータグループ差分確認。メジャーは飛び級(13→17)も可 規模を減らす: DB統合・Auroraへの寄せで祭りそのものを小さく
25. TOPIC 7 / 8 ストーリー もう火消しはイヤだ 〜EOLを「イベント」にしない仕組み〜 嵐が一段落した秋。しんどかったのは 「気づくのが遅い・全容がわか らない・上げる作業が重い」 の3つ EOLの波は続く:Python 3.10、Node.js 20、 AL2023だって いつかは終わる しんどかったのは、 EOLそのものじゃなかったんだよね 4人の情シスでどう追従し続けるか。2人はホワイトボードの前に。 あなたもその前にいます 鮫島さん 32歳・情報システム課係長(主人公) 中途入社5年目。 AWSは独学+JAWS-UG通い
26. TOPIC 7 / 8 ディスカッション あなたなら、どうする? 1 「気づく」仕組み:EOL情報をどう収集・通知している? 2 「追従が軽い」システムとは、どんな設計・運用? 3 4人でEOL管理にかけていい工数は、どのくらい?
27. TOPIC 7 / 8 ベストプラクティス 気づく・軽くする・減らす 気づく: AWS Health→EventBridge→Slack。endoflife.date等でEOL台帳+「EOL日」列。 四半期30分のレビュー会を定例化 軽くする: 組織標準でバージョンを絞る。IaC化で「作り直せる」状態に(ペットではなく家畜に)。テスト自動化度=追従の軽さ 減らす: EC2よりFargate、セルフ管理DBよりマネージド。責任共有モデルの持ち分を減らすのが最強のEOL対策 小さく払い続ける: Dependabot/Renovateで日常更新、SSM Patch Managerでパッチを日常業務に
28. TOPIC 8 / 8 ストーリー 「保守契約にOSは含まれておりません」 〜ベンダー任せシステムのEOL〜 契約書を読み返すと、保守範囲は 「アプリケーションの障害対応」のみ 。 OS・MWのバージョンアップは対象外 見積は「AL2023化+全機能検証で480万円、期間6ヶ月」 「保守契約にOSは含まれておりません」 鯨岡本部長は絶句、蟹江さん「だから触るなと言ったんじゃ」 UROKOのリプレースは3年後。 この3年をどう乗り切るか フカヒレ・ソリューションズ 地元SIer。 基幹システムUROKOの開発元 契約範囲外は一切やらない
29. TOPIC 8 / 8 ディスカッション あなたなら、どうする? 1 フカヒレ社と何を交渉する?480万の見積のどこを見る? 2 リプレースまで3年、「塩漬け」は選択肢になる? 3 次の契約書・RFPに、EOLについて何を書いておく?
30. TOPIC 8 / 8 ベストプラクティス ベンダー任せシステムのEOL戦略 契約時が全て: 保守契約にOS/MW/ランタイムのEOL追従の責任分界を明記。EOLロードマップの年次提出を要求 相見積は5年TCOで: バージョンアップ費まで含めて比較する 塩漬けは稟議とセット: 隔離・アクセス制限・監視強化を条件に、期限を切って経営承認。なし崩しが一番危ない EOLはリプレースの追い風: 更改計画と束ねてSaaS化・パッケージ移行を含め再評価 交渉材料: 検証範囲の絞り込み(全機能→重要業務フロー)・検証環境の内製提供・段階移行。「言い値の480万」の分解から
31. TAKE AWAY EOLは単発のイベントではなく、 例大祭 祭りとして計画しよう 1 「気づく・軽くする・減らす」の3点セット 2 平時の可視化(棚卸し・台帳・通知)が、有事のすべてを決める 3 契約と経営説明も、情シスの技術のうち