Amazon EKS（Elastic Kubernetes Service、AWSが提供するマネージド型Kubernetesサービス）で、クラスタのマイナーバージョンをアップグレードした後に旧バージョンへ戻せる「EKSクラスタロールバック」機能が一般提供（GA）となった[1]。Kubernetes（コンテナ化したアプリケーションを多数のサーバーで自動運用するオーケストレーション基盤）のバージョンアップグレードは、これまで実行すると後戻りできない「片道切符」が運用の前提だった。今回のGAにより、アップグレードから7日以内であれば、コントロールプレーン（クラスタの中枢管理部分）とワーカーノード（実際にコンテナを動かすサーバー群）を旧バージョンへ戻せるようになった[1][2]。インフラ運用やSRE（信頼性エンジニアリング）を担う読者にとって、アップグレード計画やロールバック体制そのものの見直しが必要になる変化である。本稿では機能の中身と、運用フロー・コスト判断への影響を整理する。
予備知識
- コントロールプレーン: クラスタ全体の状態管理やAPIサーバーを担う中枢部分。EKSではAWSが管理する。
- ワーカーノード: 実際にコンテナ（アプリ）を動かすサーバー群。EKS Auto Modeではこの管理もAWS側が担う。
- EKS Auto Mode: ワーカーノードの選定・スケーリング・更新までAWSが自動化するEKSの運用モード。
- Rollback Readiness Insights（ロールバック可否診断）: ロールバック実行前にEKSが自動でクラスタの互換性を点検する仕組み。
EKSを本番環境で運用するための構築・運用手順をアプリケーションエンジニア視点で解説
何がGAになったのか
Amazon EKSクラスタロールバックは、Kubernetesのマイナーバージョンアップグレード後に問題が見つかった場合、クラスタを直前のバージョンへ戻す機能である[1]。対象はコントロールプレーンとワーカーノードの両方で、EKS Auto Modeを使うクラスタではワーカーノード側のロールバックも自動化される[2][3]。ロールバック実行時は、etcd（Kubernetesの状態を保存するデータストア）のデータやワークロード、永続ボリュームはすべて保持される[2]。
これまでのEKS運用では、アップグレード後に互換性問題が発覚しても、クラスタを新規に作り直すか、問題を個別に修正するしかなかった。今回のGAで、アップグレード自体を「試して、駄目なら戻す」運用に切り替えられる。
ロールバックをいつ発動するかという判断基準を、Google発の信頼性エンジニアリングの枠組みから学べる
7日間ウィンドウとロールバックできない条件
ロールバックが可能な期間は、アップグレード完了から7日間に限られる[1][3]。この間EKSは「Rollback Readiness Insights」と呼ぶ自動チェックを継続し、APIの互換性、APIフィールドの変更、バージョンスキュー（コントロールプレーンとノードのバージョン差）、アドオンの互換性、クラスタの健全性を点検する[2][3]。
ロールバックできない条件は主に3つある。クラスタが現在のバージョンで新規作成された場合、アップグレードから7日を超えた場合、そのクラスタで既に別のアップグレードを実行済みの場合である[3]。診断を無視して強制的にロールバックしたい場合は、CLIの--forceオプションで可否チェックを回避できる[3]。
| 項目 | GA前 | GA後 |
|---|---|---|
| アップグレード失敗時の対応 | 手動修正または再構築 | 7日以内ならロールバック |
| 互換性チェック | 手動確認が中心 | Readiness Insightsで自動診断 |
| 対象範囲 | コントロールプレーンのみ意識 | コントロールプレーン＋ワーカーノード（Auto Mode） |
Azure Storage GPv1（General Purpose v1、汎用ストレージアカウント旧バージョン）が2026年10月13日に廃止される。Azureでストレージアカウントを持つ組織は、この期日までにGPv2（Gener[…]
Auto Modeとワーカーノードのロールバック、かかる時間
コントロールプレーンのロールバックは通常のアップグレードと同程度で、およそ20分で完了する[2]。一方、EKS Auto Modeでのワーカーノードのロールバックは、設定した「ディスラプションコントロール（ノード入れ替え時の許容範囲を制御する設定）」次第で、数分から最大7日間かかる[3]。EKSはコントロールプレーンを戻す前に、まずワーカーノード側のロールバックを完了させる順序を取る[3]。
Auto Modeを使っていないクラスタでは、この自動ロールバックの対象はコントロールプレーンのみになる。セルフマネージドのワーカーノードやマネージドノードグループを使う場合、旧バージョンのAMI（マシンイメージ）への切り戻しは従来どおり自前で手順化しておく必要がある。
AWSは2025年後半から、ALB・NLB・KMS・ACM・CloudFront・Secrets Managerで、ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism、NI[…]
運用コストと意思決定への影響
EKSクラスタロールバック機能自体の利用に追加費用はない[1][2]。一方でKubernetesバージョンのサポート期間には別のコストがある。EKSの標準サポートは提供開始から14か月、延長サポートはその後12か月続き、合計26か月まで同じマイナーバージョンを使い続けられる[4]。延長サポート期間中のクラスタは1時間あたり0.60ドル（約93円、1ドル=155円換算）の追加課金があり、標準サポート期間中は1時間あたり0.10ドル（約16円）である[4]。
ロールバックという安全網が整った以上、アップグレードを先延ばしにして延長サポート費用を払い続けるより、早めにアップグレードして問題が出たら戻す運用のほうが、コスト面で合理的になる場面が増える。Kubernetesのマイナーバージョンはコミュニティから平均4か月に1回のペースでリリースされ、年3回程度アップグレード判断が発生する[4]。ロールバックという退路が用意されたことは、アップグレード実行の判断を早める根拠になる。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
まとめ
EKSクラスタロールバックのGAで、Kubernetesアップグレードは「片道切符」ではなくなった。7日以内なら自動診断つきでコントロールプレーンとワーカーノードを旧バージョンへ戻せる[1][3]。読者への実務上の示唆は3つある。第一に、アップグレード計画にロールバック検証の手順を組み込む。第二に、延長サポート費用と早期アップグレードのコストを比較して判断する。第三に、EKS Auto Modeを使っていない場合はワーカーノード側の切り戻し手順を別途用意する。次回のクラスタアップグレードでは、ロールバックを前提にした計画を検討する価値がある。
よくある質問（FAQ）
Q1. EKSクラスタロールバックとは何か。
Amazon EKSでKubernetesのマイナーバージョンをアップグレードした後、問題が見つかった場合に直前のバージョンへ戻せる機能である[1]。
Q2. ロールバックできる期間はどれくらいか。
アップグレード完了から7日以内である。7日を超えた場合や、クラスタが現在のバージョンで新規作成された場合はロールバックできない[3]。
Q3. ロールバック機能の利用に追加費用はかかるか。
かからない。EKSクラスタロールバック自体は追加費用なしで全リージョンで利用できる[1][2]。ただし、Kubernetesバージョンの延長サポートには別途1時間あたり0.60ドル（約93円）の課金がある[4]。
