
数千人規模の従業員が使う基幹システムをAmazon EKS(Amazon Elastic Kubernetes Service、AWSのマネージドKubernetesサービス)上で本番稼働させ、年1回の内部監査を受ける情報システム部門のインフラ担当者に、直接関わる変更が起きている。EKSのKubernetes 1.33は2026年7月29日に標準サポートを終了し、対象クラスタは追加操作なしに延長サポート料金へ切り替わった[1]。放置してもクラスタは即座には止まらないが、コストは静かに増え続け、最終的には予告のない強制アップグレードが待つ。稟議と承認フローを経る組織ほど、この分岐点の判断は早いほうがよい。本稿は延長サポートを払い続ける場合の費用と、最新版1.36への計画移行に伴う破壊的変更を突き合わせ、判断材料を示す。
予備知識
- EKS: AWSが提供するマネージドKubernetesサービス。コントロールプレーンの運用をAWS側が担う。
- cgroup: Linuxカーネルの機能で、CPUやメモリなどのリソース配分を制御する仕組み。v1とv2で管理方式が異なる。
- containerd: コンテナの起動・停止を担う実行エンジン(コンテナランタイム)。ノード上でPodを動かす土台になる。
- 標準サポート/延長サポート: EKSがバージョンごとに設ける保守期間の区分。標準サポート終了後は割高な延長料金が自動適用される。
EKSクラスタ運用の設計判断を体系的に整理でき、移行計画の実務検討に使える
EKS 1.33の標準サポート終了で実際に何が変わったのか
標準サポート終了とは、追加の申請や承認なしに延長サポート料金へ自動移行する仕組みを指す。EKSのKubernetes 1.33は2025年5月29日にGA(一般提供)となり、標準サポートは14か月後の2026年7月29日に終了した[1][5]。延長サポートはそこから12か月間続き、終了日は2027年7月29日になる[2]。この間、クラスタの起動や運用に支障は生じない。変わるのはコントロールプレーンの課金だけで、ワーカーノード側のEC2やFargateの費用は影響を受けない[2][3]。

延長サポート費用のような継続コストを組織的に可視化・意思決定する枠組みを学べる
延長サポートを払い続けるといくらかかるのか
延長サポートは、標準サポート料金との差額が1クラスタあたり時間0.50ドルの追加費用になり、稼働クラスタ数が増えるほど負担が線形に増える。標準サポートの料金は1クラスタ時間あたり0.10ドル(約16円、1ドル=155円換算)、延長サポートは0.60ドル(約93円)で、いずれもコントロールプレーンの課金であり6倍の水準になる[2][3]。24時間365日稼働のクラスタ1台なら、標準サポート料金との差額だけで年間4,380ドル(約68万円)、5台なら21,900ドル(約339万円)、10台なら43,800ドル(約679万円)の追加負担になる。
| クラスタ数 | 追加費用(年間USD) | 追加費用(年間・155円換算) |
|---|---|---|
| 1 | 4,380ドル | 約68万円 |
| 5 | 21,900ドル | 約339万円 |
| 10 | 43,800ドル | 約679万円 |
複数クラスタを本番・検証・DR用に分けて運用している企業ほど、この差額は移行プロジェクトの予算根拠として使いやすい。

数百のWebアプリをAzure App Serviceで運用し、年次のセキュリティ監査を受ける企業のプラットフォーム担当者は、2026年後半に複数のランタイムが立て続けにサポート終了を迎える事態に向き合うことになる。対象はAzure Ap[…]
1.33から1.36への移行で何が壊れるのか
1.33から1.36の間には、事前確認をしないまま上げるとPodやノードが起動しなくなる破壊的変更が複数ある。cgroup v1は1.35で既定無効化された(opt-outの猶予あり)[1]。完全削除の時期はKEP-5573でも未確定で、全サポート対象リリースで無効化が行き渡ってから着手するとされている[6]。containerdはKubernetes 1.35がcontainerd 1.x系に対応する最後のバージョンで、次のバージョンへ上げる前に2.0以降へ切り替える必要がある[1]。1.7.xも1.x系に含まれるため、1.36へ進む場合は2.0以降が必須になる。なおFargateは引き続きcgroup v1を使用する[1]。gitRepoボリュームは1.33の時点で既定拒否(opt-out可)だったものが、1.36ではopt-outの猶予自体が恒久的に閉じられる。
| 変更 | 導入の経緯 | 実務への影響 |
|---|---|---|
| cgroup v1廃止 | 1.35で既定無効化→1.36で完全削除 | cgroup v1のノードは1.36で起動不能 |
| containerdバージョン | 1.35がcontainerd 1.x最後の対応。1.36へ進む前に2.0以降へ[1] | 1.6.x系ノードはkubelet登録に失敗 |
| gitRepoボリューム | 1.33で既定拒否→1.36でopt-out恒久廃止 | Pod再起動時にエラーが顕在化し、原因特定に時間がかかる |
1.33稼働企業はAL2023かBottlerocketへの移行が前提のため、cgroup v2自体は対応済みのケースが多い。ただしcontainerdバージョンとgitRepoボリュームの利用有無は別途棚卸しが必要だ。

主要システムをAzureのWest US(米国西部)リージョン単一に集約し、複数リージョンへの分散やDR(災害復旧)計画をまだ具体化していない企業のインフラ担当者は、この障害の技術的経緯を無視できない。2026年7月23日14時44分(U[…]
延長期間を放置するとどうなるのか
延長サポートの期限を過ぎると、コントロールプレーンだけが予告なく最も古い対応バージョンへ自動更新される。1.33の場合、延長サポート終了日である2027年7月29日以降のどこかで、AWSが段階的にコントロールプレーンを最新の対応最古バージョンへ引き上げる仕組みで、個々のクラスタへの事前通知や確定した実行時期は案内されない[2]。しかもこの自動更新はコントロールプレーンに限られ、ワーカーノードとアドオンは自動更新されない。結果として、コントロールプレーンだけ新しいKubernetesバージョンに上がり、ノード側は古いcontainerdやcgroup構成のまま取り残される版数不整合が起きる。cgroup v1やcontainerd 1.x依存のノードが残っていれば、この不整合はPodの起動失敗として表面化する。

※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論(Seedance 2.0の要点) 何がすごい[…]
SIer保守契約と稟議フローがEKS移行判断を遅らせる構造
AWSのサポート期限と料金体系は地域に関わらず同一で、日本企業のEKS利用者にもそのまま適用される。違うのは意思決定の速度だ。SIerとの保守契約は年次更新が基本で、契約範囲の変更には数か月かかることが多い。稟議は起案から承認まで複数階層を経て数週間から数か月を要し、年次の内部監査・変更管理プロセスは計画外の緊急アップグレードと相性が悪い。Kubernetes専任者が少なくSIer外注に依存する体制も多く、影響範囲の棚卸しそのものに時間がかかる。
| 観点 | クラウドネイティブ企業に多い型 | 日本の伝統的エンタープライズに多い型 |
|---|---|---|
| 意思決定サイクル | 数日〜数週間 | 数週間〜数か月(稟議・複数階層承認) |
| 保守契約 | 継続契約・随時変更可 | SIerとの年次契約が基本 |
| 変更管理 | チーム内で完結しやすい | 内部監査・統制プロセスを通す |
| 人材体制 | Kubernetes専任者を内製 | SIer外注に依存する割合が高い |
IT部門の判断は一行で言える。延長サポート開始を起点に、影響システムの棚卸しと稟議準備を今すぐ始めることだ。決裁側の判断も一行で言える。移行予算は次年度の定例稟議を待たず、緊急枠での前倒し承認を検討することだ。
まとめ
インフラ担当者がまず着手すべきは、稼働中のEKSクラスタとノードOS・containerdバージョンの棚卸しで、cgroup v1やcontainerd 1.x系に依存するノードとgitRepoボリューム使用箇所を特定することだ。決裁側は、延長サポートを払い続けた場合の年間追加費用と、計画移行にかかるプロジェクト費用を比較し、猶予のある今のうちに移行時期を確定する材料として使ってほしい。延長サポートは選択肢の一つであって解決策ではなく、いずれ1.36以降への移行は避けられない。
よくある質問(FAQ)
Q1. EKSの延長サポート料金はいつから請求されますか。
標準サポート終了日(1.33は2026年7月29日)から自動的に適用されます。申請作業は不要です[2][3]。
Q2. 延長サポート中もクラスタは通常どおり動きますか。
動きます。停止することはなく、変わるのはコントロールプレーンの課金だけです[2]。
Q3. 1.36への移行に停止時間は必要ですか。
コントロールプレーン更新自体は無停止ですが、cgroup v1やcontainerd 1.x系のノードは事前の入れ替えが要り、省くとPodが起動しなくなります[1][6]。




