はじめに
EKS の大規模運用をしていると、コントロールプレーンのスロットリングに頭を悩ませる瞬間は誰でも一度は経験するはずです。2026 年 3 月 20 日、AWS はその痛点に直接応える 2 つのアップデートを発表しました。
1 つ目は、Provisioned Control Plane を利用するクラスターへの SLA 引き上げです。従来の標準コントロールプレーンが保証する 99.95% から 99.99% へと向上しました。
2 つ目は、新しいスケーリングティア「8XL」の追加です。これまでの最大ティアだった 4XL の 2 倍となる Kubernetes API サーバーのリクエスト処理能力を持ち、超大規模なワークロードへの対応が現実的になりました。
本記事では、「何が変わったのか」「どんな課題が解決されるのか」「実際にどう設定するのか」を中心に解説します。大規模 EKS クラスターを運用しているエンジニアや、Kubernetes 基盤の信頼性・スケーラビリティに関心のある方はぜひ最後まで読んでみてください。
新機能の概要
Provisioned Control Plane とは
本題に入る前に、今回のアップデートの対象となる Provisioned Control Plane を整理しておきます。
通常の EKS クラスターでは、コントロールプレーン（API サーバー・etcd・スケジューラーなど）の容量は AWS が自動管理します。負荷が増えればスケールアップされますが、スケールに時間がかかるため、突発的な負荷増加時にリクエストのスロットリングが発生するリスクがあります。
Provisioned Control Plane は、コントロールプレーンの容量をあらかじめ指定・確保しておく仕組みです。スケーリングティア（XL / 2XL / 4XL、そして今回追加された 8XL）から自クラスターに合ったサイズを選ぶことで、トラフィックスパイクにも即座に対応できる状態を事前に整えられます。
| 標準コントロールプレーン | Provisioned Control Plane | |
|---|---|---|
| 容量管理 | AWS が自動管理 | ティアを自分で指定・事前確保 |
| スパイク対応 | スケールに時間がかかる場合あり | 事前確保のため即応可能 |
| SLA | 99.95% | 99.99%（今回のアップデート） |
| 料金（クラスター CP 分） | $0.10 / 時間 | XL〜8XL: $1.65〜$13.90 / 時間 |
| 向いているワークロード | 小〜中規模・負荷が比較的安定している環境 | 大規模・負荷変動が激しい・ミッションクリティカルな環境 |
標準コントロールプレーンは多くのワークロードで十分なパフォーマンスを発揮しつつコストを抑えられる選択肢です。Provisioned Control Plane は追加コストがかかる分、予測不可能な負荷への即応性と 99.99% SLA が必要なミッションクリティカルな環境に向いています。
今回発表された 2 つのアップデート
① SLA が 99.99% に向上
Provisioned Control Plane を利用するクラスターの SLA が、99.95% から 99.99% に引き上げられました。
数字だけ見るとわずかな差に感じるかもしれませんが、許容ダウンタイムに換算すると差は歴然です。
| 99.95%（従来） | 99.99%（今回） | |
|---|---|---|
| 月間許容ダウンタイム | 約 21.6 分 | 約 4.3 分 |
| 年間許容ダウンタイム | 約 263 分（約 4.4 時間） | 約 53 分 |
また、SLA の測定間隔も従来の 5 分間隔から 1 分間隔へと変更されました。短時間の障害も補償対象として捕捉されます。
補足： 執筆時点（2026 年 3 月）では、公式 SLA ドキュメント（amazon.com/eks/sla/）への測定間隔の反映が追いついていない状態です。詳細は What's New の発表内容を合わせてご参照ください。
② 新スケーリングティア「8XL」の追加
これまでの最大ティアだった 4XL に加え、新たに 8XL ティアが追加されました。4XL と比較して Kubernetes API サーバーのリクエスト処理能力が 2 倍となっており、以下のような超大規模ワークロードでの利用が想定されています。
- 数千ノード規模の GPU クラスターを用いた AI / ML 分散トレーニング
- 大量のジョブを並列実行する HPC（高性能コンピューティング）
- 多数の Pod を同時にスケジュールする大規模データ処理基盤
- 数百テナントを単一クラスターでホストするマルチテナント SaaS プラットフォーム
99.99% SLA・8XL ティアともに、EKS Provisioned Control Plane が提供されている全 AWS リージョンで本日より利用可能です。
何が変わったのか
今回のアップデートは「新しい機能が増えた」というだけでなく、EKS を大規模運用する上で現場が抱えていた課題に直接応えるものです。
課題 ① コントロールプレーンの可用性が要件を満たせない
従来の課題
標準コントロールプレーンの SLA は 99.95% であり、一般的なワークロードでは問題になりにくい数字です。しかし以下のような環境では、契約上・運用上のボトルネックになることがありました。
- 金融・決済システム：株式取引やリアルタイム決済では数分のダウンタイムが直接的な損失につながり、社内外で 99.99% 以上の SLA を求められるケースが多い
- 医療・ヘルスケア：患者データの参照や処置記録など、システム停止が業務に直結する環境
- SaaS プロバイダー：顧客との契約で高い稼働率を保証している場合、プラットフォーム側の SLA がボトルネックになる
また、従来の測定間隔は 5 分単位だったため、数分以内に復旧した短時間の障害は SLA の計算上カウントされないという課題もありました。実態としてはユーザーへの影響があっても、補償対象外になるケースが生じていました。
今回の変化
SLA が 99.99% に引き上げられ、測定間隔も 1 分単位に変更されました。これまで「EKS の SLA では要件を満たせない」として採用を見送っていたミッションクリティカルな環境でも、EKS が選択肢に入るようになります。
課題 ② 突発的な負荷でコントロールプレーンがボトルネックになる
従来の課題
標準コントロールプレーンは需要に応じて自動スケールしますが、スケールアップが完了するまでの間に大量のリクエストが集中すると、API サーバーがスロットリングを起こすことがありました。
特に以下のようなシナリオで問題が顕在化していました。
- AI / ML トレーニングジョブの一斉起動：数百〜数千の GPU Pod を短時間で展開する際、スケジューリングや状態更新のリクエストが一気に集中し、API サーバーの応答が遅延・失敗する
- HPC バッチ処理：科学計算やゲノム解析などで数万のジョブを並列実行する場合、Pod の作成・削除リクエストが大量に発生する
- イベント駆動のバーストトラフィック：EC サイトのセール開始やゲームのリリース直後など、予測しにくい急激な負荷増加
こうした状況では、コントロールプレーンのスケールアップを待つ間にジョブが失敗したり、デプロイが遅延したりしていました。
今回の変化
Provisioned Control Plane ではコントロールプレーンの容量を事前に確保しておくため、突発的な負荷増加にも即座に対応できます。さらに新たに追加された 8XL ティアにより、これまでは複数クラスターに分散せざるを得なかった超大規模ワークロードを、単一クラスターで安定して運用できます。
使い方
ここでは Provisioned Control Plane の実際の設定手順を、新規クラスター作成と既存クラスターの移行の 2 パターンに分けて解説します。
前提条件
- EKS バージョン v1.28 以上（Provisioned Control Plane の対応バージョン）
- AWS CLI v2 がインストール済みであること
- 操作に必要な IAM 権限があること
Provisioned Control Plane とスケーリングティアの選び方
設定に入る前に、ティアの選び方の基準を整理しておきます。
各ティアは API リクエスト同時実行数（API request concurrency）・Pod スケジューリングレート（Pod scheduling rate）・クラスターデータベースサイズ（Cluster database size）の 3 つの属性で定義されています。スペックは EKS バージョンによって異なります。
EKS v1.28 / v1.29
| ティア | API 同時実行数（seats） | Pod スケジューリングレート（pods/sec） | DB サイズ（GB） |
|---|---|---|---|
| XL | 1,700 | 100 | 16 |
| 2XL | 3,400 | 100 | 16 |
| 4XL | 6,800 | 100 | 16 |
| 8XL（新登場） | 13,600 | 100 | 16 |
EKS v1.30 以降
| ティア | API 同時実行数（seats） | Pod スケジューリングレート（pods/sec） | DB サイズ（GB） |
|---|---|---|---|
| XL | 1,700 | 167 | 16 |
| 2XL | 3,400 | 283 | 16 |
| 4XL | 6,800 | 400 | 16 |
| 8XL（新登場） | 13,600 | 400 | 16 |
ティア選定のヒント： 公式ドキュメントでは、まず 8XL で負荷テストを実施し、ピーク時の各メトリクスを計測した上で最適なティアを選定する方法が推奨されています。料金は後述のコストと注意点の章を参照してください。
新規クラスターに Provisioned Control Plane を設定する
コンソールから設定する場合
- AWS マネジメントコンソールで Amazon EKS を開く
- 「クラスターの作成」を選択し、設定オプションで「カスタム設定」を選ぶ
- 「コントロールプレーンスケーリング階層」で「スケーリング階層を使用」を有効化
- 使用するティア（XL / 2XL / 4XL / 8XL）を選択
- その他の設定を行い「クラスターの作成」をクリック
AWS CLI から設定する場合
--control-plane-scaling-config オプションでティアを指定します。
aws eks create-cluster \
--name <cluster-name> \
--role-arn arn:aws:iam::<account-id>:role/<role-name> \
--resources-vpc-config subnetIds=<subnet-id>,securityGroupIds=<security-group-id> \
--control-plane-scaling-config tier=<tier> \
--region <region>
ティアの指定値は以下のとおりです。
| ティア | 指定値 |
|---|---|
| XL | tier=tier-xl |
| 2XL | tier=tier-2xl |
| 4XL | tier=tier-4xl |
| 8XL | tier=tier-8xl |
既存クラスターを Provisioned Control Plane に移行する
既存クラスターは update-cluster-config コマンドでティアを変更できます。標準コントロールプレーンから Provisioned Control Plane への移行も同じコマンドで行えます。
# 標準 CP → Provisioned CP へ移行、ティアのアップグレード
aws eks update-cluster-config \
--name <cluster-name> \
--control-plane-scaling-config tier=<tier> \
--region <region>
# Provisioned CP → 標準 CP へ戻す
aws eks update-cluster-config \
--name <cluster-name> \
--control-plane-scaling-config tier=standard \
--region <region>
注意： 標準 CP がサポートする etcd データベースサイズは最大 8 GB です。Provisioned CP 利用中にデータベースサイズが 8 GB を超えた場合、8 GB 未満に削減するまで標準 CP へ戻すことができません。
移行の進捗を確認する
ティア変更は ScalingTierConfigUpdate という更新タイプで管理されます。以下のコマンドで進捗を確認できます。
# クラスターの更新一覧を確認
aws eks list-updates --name <cluster-name> --region <region>
# 特定の更新詳細を確認（update-id は list-updates の結果から取得）
aws eks describe-update \
--name <cluster-name> \
--update-id <update-id> \
--region <region>
ステータスが Updating → Successful に変われば移行完了です。ティア変更中も API サーバーのダウンタイムは発生しません（新しい API サーバーが起動してから旧サーバーが停止する仕組みのため）。
現在のティアを確認する
aws eks describe-cluster \
--name <cluster-name> \
--region <region> \
--query 'cluster.controlPlaneScalingConfig'
コントロールプレーンの利用状況をモニタリングする
Provisioned Control Plane では、以下の CloudWatch メトリクスでティアの使用状況をリアルタイムに監視できます。
| 監視対象 | CloudWatch メトリクス名 |
|---|---|
| API 同時実行数 | apiserver_flowcontrol_current_executing_seats |
| Pod スケジューリングレート |
scheduler_schedule_attempts_totalscheduler_schedule_attempts_SCHEDULEDscheduler_schedule_attempts_UNSCHEDULABLE
|
| DB 使用サイズ | apiserver_storage_size_bytes |
コンソールからは、クラスターの概要ページ → 「オブザーバビリティダッシュボード」 → 「コントロールプレーン監視」タブから視覚的に確認することもできます。これらのメトリクスを CloudWatch アラームと組み合わせることで、ティアの上限に近づいた際に自動通知する仕組みも構築できます。
補足： Provisioned Control Plane はティア間の自動スケーリングを行いません。上記メトリクスを定期的に確認し、必要に応じて手動でティアを変更する運用が必要です。
アーキテクチャとベストプラクティス
コントロールプレーンのアーキテクチャ
Provisioned Control Plane を理解するには、まず EKS のコントロールプレーンがどのように構成されているかを把握しておく必要があります。
標準コントロールプレーン（Standard mode）の構成
EKS のコントロールプレーンは、API サーバー・スケジューラー・コントローラーマネージャーと、クラスターのすべての状態を保存するデータストア（etcd）から構成されています。これらのコンポーネントは AWS 管理のアカウント内で動作しており、ユーザーからは見えません。構成の概要は以下のとおりです。
- API サーバー：最低 2 台が異なる AZ に配置され、NLB（Network Load Balancer）でロードバランシング
- etcd：最低 3 台が 3 つの AZ にまたがって配置（奇数台構成でリーダー選出を保証）
- いずれもプライベートサブネット内で稼働し、NAT Gateway 経由で外部と通信
この構成により、単一 AZ の障害がクラスターの可用性に影響しないマルチ AZ 冗長性が確保されています。標準モードではこれらのコンポーネントが需要に応じて自動スケールしますが、スケールアップには約 10 分かかるため、突発的な負荷に対して即応できないという課題がありました。
Provisioned Control Plane の違い
Provisioned Control Plane は「リアクティブなスケール」から「プロアクティブな事前確保」への設計転換です。選択したティアに対して常に十分な API サーバースループット・スケジューラー/コントローラー容量・データベースサイズが確保されます。
内部的には 3 つの柱で成り立っています。
- 事前確保された容量：ティアで指定した性能が常に利用可能な状態を維持。スケールアップ待ちが発生しない。
- 高度なスロットリング機構：ティアの上限を超えるトラフィックに対してもグレースフルに処理し、システム全体の信頼性を確保。
- 新世代 etcd アーキテクチャ：標準 CP の 8 GB に対し、Provisioned CP では 16 GB の etcd データベースをサポート。より大きなクラスター状態を保持しながら高い耐久性と高速なリカバリを実現。
| 標準 CP | Provisioned CP | |
|---|---|---|
| スケーリング方式 | リアクティブ（負荷増加を検知してからスケール） | プロアクティブ（ティアの容量を事前確保） |
| スケール時間 | 約 10 分 | 即応（常に容量が確保済み） |
| etcd 最大サイズ | 8 GB | 16 GB |
| ゾーン冗長 | あり（マルチ AZ） | あり（マルチ AZ） |
ティア容量と実際のパフォーマンスは別物
スペック表の数字はあくまで上限値です。実際のパフォーマンスはワークロードのパターンによって変わります。
list リクエストは get より重い
Kubernetes の API Priority and Fairness（APF）の仕組みでは、list リクエストは get リクエストよりも多くの「席（seats）」を消費します。4XL ティアの API 同時実行数は 6,800 seats ですが、list リクエストが多いワークロードでは実効的な処理数はこの数字より低くなります。
Pod スケジューリングレートはノードの状態に依存する
スケジューリングレートはスケジューラーの処理能力の上限値です。ノードが準備完了（Ready）状態になるまでの時間が長ければ、スケジューラーがいかに高速でも実際の Pod 配置速度は上がりません。
重要： Provisioned Control Plane はコントロールプレーンのスケーリング遅延を排除しますが、アプリケーション側の設計やノードの状態に起因するボトルネックは解消しません。
API サーバー負荷を減らすベストプラクティス
Provisioned Control Plane を最大限に活かすには、クライアント側からの API 呼び出しを効率化することも重要です。
ポーリングではなくイベント駆動（Watch）で取得する
カスタムコントローラーや自動化ツールで Kubernetes リソースの状態を定期的にポーリングすると、API サーバーへの負荷が継続的に発生します。Kubernetes API の Watch 機能を使えば、リソースの変更があったときだけ通知を受け取るイベント駆動の設計に切り替えられます。使用する言語やツールに関係なく適用できる設計原則です。
# ポーリング（負荷が高い）
while true; do
kubectl get pods -n production
sleep 10
done
# Watch（イベント駆動・低負荷）
kubectl get pods -n production --watch
各言語の Kubernetes クライアントライブラリ（Go の client-go、Python の kubernetes-client、Java の fabric8 など）はいずれも Watch 相当の機能を提供しています。カスタムコントローラーを実装する場合は、ポーリングではなく Watch ベースの設計を選んでください。
labelSelector・namespace でリクエストを絞り込む
フィルタリングなしのクラスター全体への list リクエストは、etcd からすべてのデータを取得してクライアント側でフィルタするため、API サーバーへの負荷が高くなります。labelSelector や namespace を指定することで、API サーバー側での絞り込みが可能です。
# NG: クラスター全体への無フィルタリスト
kubectl get pods --all-namespaces
# OK: namespace と labelSelector で絞り込み
kubectl get pods -n production -l app=my-service
スケールアップ・ダウン時の急激な変化を避ける
大規模なノードの追加や削除を短時間に行うと、コントロールプレーンへの API リクエストが急増します。一度に行う変化量を全体の 10% 以下に抑えることが推奨されています。ノードを削除する際は Pod Disruption Budget（PDB）を設定し、Pod の移動を段階的に行うことで急激な負荷を抑制できます。
「ティアを上げれば解決」ではないケース
Provisioned Control Plane は強力な機能ですが、コントロールプレーン以外がボトルネックになっている場合は効果が限定的です。ティアを上げる前にまず以下の観点で根本原因を確認することをお勧めします。
| ボトルネック | 症状 | 対処 |
|---|---|---|
| Admission Webhook の遅延 | Pod 作成・更新が遅い | Webhook の処理時間を計測・最適化 |
| ノードのコールドスタート | Pod の配置が遅い（スケジューラーは健全） | ノードの起動時間短縮・事前ウォームアップ |
| etcd の肥大化 | 書き込みリクエストが拒否され始める | 不要リソースの削除・設計の見直し |
| 非効率な API 呼び出し | API レイテンシが高いが CPU/メモリは余裕がある | ポーリングを Watch に変更・フィルタを追加 |
コストと注意点
料金体系
Provisioned Control Plane の料金は、すべての EKS クラスターに適用される基本料金に加えて、選択したティアの追加料金が発生する構造です。
基本料金（全クラスター共通）
| Kubernetes バージョンサポート | 料金 |
|---|---|
| 標準サポート（リリースから 14 ヶ月） | $0.10 / クラスター / 時間 |
| 延長サポート（標準サポート終了後 12 ヶ月） | $0.60 / クラスター / 時間 |
Provisioned Control Plane 追加料金
| ティア | 追加料金 |
|---|---|
| XL | $1.65 / クラスター / 時間 |
| 2XL | $3.40 / クラスター / 時間 |
| 4XL | $6.90 / クラスター / 時間 |
| 8XL | $13.90 / クラスター / 時間 |
注意： 上記の追加料金は基本料金とは別に発生します。たとえば XL ティアを標準サポートのクラスターで利用する場合、合計は $0.10 + $1.65 = $1.75 / 時間となります。
月額コスト試算（730 時間 / 月で計算）
| 構成 | 月額概算 |
|---|---|
| 標準 CP（標準サポート） | 約 $73 |
| Provisioned CP XL（標準サポート） | 約 $1,278（$1.75 × 730h） |
| Provisioned CP 2XL（標準サポート） | 約 $2,555（$3.50 × 730h） |
| Provisioned CP 4XL（標準サポート） | 約 $5,110（$7.00 × 730h） |
| Provisioned CP 8XL（標準サポート） | 約 $10,220（$14.00 × 730h） |
活用例（公式より）： EC サイトがホリデーシーズンに備えて月の途中から XL ティアに切り替えた場合、前半 15 日は $36（標準 CP のみ）、後半 15 日は $594（XL 追加料金）+ $36（基本料金）= 月合計 $666 となります。
コスト最適化のポイント
常時起動が前提のコストであることを理解する
Provisioned Control Plane はオンデマンドのスケーリングではなく、指定したティアの容量を常に確保し続ける仕組みです。使用率が低い時間帯でも料金は発生します。
イベント前後だけ一時的にティアを上げる
Provisioned Control Plane はティアをいつでも変更できます（変更には数分かかりますが API サーバーのダウンタイムなし）。セールや大規模デプロイの前にティアを上げ、終了後に標準 CP や下位ティアへ戻すことでコストを最適化できます。
まず非本番環境で使用量を計測する
実際にどのティアが必要かを判断するには、本番環境に近い負荷をかけた上でコントロールプレーンのメトリクスを観察することが推奨されています。まず 8XL で負荷テストを実施し、ピーク時の使用率から最適なティアを見極めるアプローチが効果的です。
注意点・制約事項
明示的なオプトインが必要
既存のクラスターは自動的に Provisioned Control Plane へ移行されません。ティアを指定して明示的にオプトインする必要があります。
etcd サイズ超過時は標準 CP へ戻せない
Provisioned CP 利用中に etcd のデータベースサイズが 8 GB を超えた場合、8 GB 未満に削減するまで標準 CP へ戻すことができません。定期的に apiserver_storage_size_bytes メトリクスを監視し、不要なリソースを削除する運用を推奨します。
ティア間の自動スケーリングは行われない
Provisioned Control Plane はティアを固定します。メトリクスに基づいてティアを自動的に上下させる仕組みは提供されていないため、手動でティアを変更する運用が必要です。メトリクス監視と EKS API を組み合わせることで、独自の自動化スクリプトを構築することは可能です。
対応バージョンとリージョン
| 項目 | 内容 |
|---|---|
| 対応 EKS バージョン | v1.28 以上 |
| 対応リージョン | 全 AWS 商用リージョン・GovCloud・中国リージョン |
まとめ
今回の発表で Amazon EKS に加わった 2 つのアップデートを振り返ります。
① Provisioned Control Plane の SLA が 99.99% に向上
従来の 99.95% から引き上げられ、測定間隔も 5 分から 1 分単位へ変更されました。月間の許容ダウンタイムは約 21.6 分から約 4.3 分へ短縮され、金融・医療・SaaS など高い可用性が求められる環境でも EKS が有力な選択肢になります。
② 新スケーリングティア「8XL」の追加
これまでの最大ティア 4XL の 2 倍となる API サーバー処理能力（13,600 seats）を持つ 8XL が登場しました。数千ノード規模の AI / ML 分散トレーニングや HPC など、これまで単一クラスターでは対応が難しかった超大規模ワークロードの運用が現実的になります。
どちらのアップデートも Provisioned Control Plane を有効にしているクラスターが対象です。まだ試したことがない場合は、まず非本番環境でティアを有効にし、コントロールプレーンのメトリクスを観察するところから始めてみてください。