EMR on EKS で Spark を動かすチーム向けに、30%の値下げが請求のどこに効くかを整理する。下がるのは vCPU 時間と GB 時間の EMR 料金で、EKS の料金は変わらない。適用は自動で手続きは要らない。
30% EMR on EKS の EMR 料金の値下げ幅 vCPU 時間・GB 時間の両方の EMR 料金が対象。Amazon EKS の料金は変わらない（2026年10月23日の AWS 告知）
EMR on EKS で Spark を動かしているなら、2026年10月23日付の AWS の告知で安くなったのは、請求のうち EMR の料金 の部分だけだ。EKS の上に EMR が加算している料金が 30% 下がり、その下にある Amazon EKS の料金は変わらない。告知によれば新しい価格は EMR on EKS のワークロードに自動で適用され、利用者の側で追加の操作は要らない。
値下げは vCPU 時間あたりの料金と GB 時間あたりの料金の両方にかかる。片方だけではないので、CPU を多く確保するジョブでも、メモリを多く確保するジョブでも、EMR の料金の部分には同じ 30% が効く。
告知は EMR on EKS の料金を「EKS に加算される EMR の料金」と「その下の Amazon EKS の料金」に分けて書いている。今回動いたのは前者だけで、構造を並べると次のようになる。
EMR on EKS で払う料金
├─ EMR の料金（EKS に加算される分）
│ ├─ vCPU 時間あたり … 30% 減
│ └─ GB 時間あたり … 30% 減
└─ Amazon EKS の料金 … 変更なしこのため、Spark ジョブにかかる費用の合計が 30% 下がるわけではない。合計に占める EMR の料金の割合が大きいほど、合計の下げ幅は 30% に近づく。EKS 側の料金の割合が大きければ、合計で見た下げ幅はそのぶん小さくなる。自分のチームでどれだけ効くかは、現在の請求で EMR の料金と EKS 側の料金がどういう比率になっているかで決まる。
告知が「変わらない」と名指ししているのは Amazon EKS の料金だ。クラスタを構成するそれ以外の費用については、告知は何も述べていない。値下げの対象はあくまで EMR の vCPU 時間と GB 時間の料金と読むのが、告知の文面に沿った範囲になる。
対象の範囲は広い。告知は、EKS のデプロイオプションで動いているすべての EMR ワークロードがこの変更の恩恵を受けると書いている。例として挙がっているのは Apache Spark のワークロードだが、Spark に限った値下げとは書かれていない。
地域についても、EMR on EKS が提供されているすべての AWS リージョンで 30% の値下げが有効だとしている。特定のリージョンだけを先行させる書き方ではない。ただし告知にリージョンの一覧はないので、自分が使っている地域が対象かどうかは「そこで EMR on EKS が提供されているか」で判断することになる。
EKS 上で動かす形態についての告知なので、EMR を別のデプロイ形態で使っている場合の料金は、この告知からは読み取れない。EMR on EKS への切り替えを費用面で比べている途中なら、比較表の EMR on EKS 側の数字だけを更新し、他の形態の数字は動かさないでおくのが安全だ。
やることは基本的にない。設定、申請、ジョブ定義の書き換えは告知上いずれも不要で、新しい価格は自動で適用される。
影響を確認するなら、EMR on EKS の vCPU 時間と GB 時間 に対応する EMR 料金の単価を、利用明細や最新料金表示で従来の水準と比較したい。料金が切り替わった時点が明記されていないため、暦月の請求額だけを比較して値下げ率を断定しない。EKS 側の行の単価は動いていないはずなので、もしそちらが変わっていれば今回の値下げとは別の要因を疑うことになる。今回の料金変更はクラスターの運用設定や実行ジョブの定義を変更するよう求めるものではない。
告知には値下げ後の具体的な単価も、どの時点の利用分から新価格になるかも書かれていない。月の途中で切り替わった場合の請求の見え方を細かく確かめたいチームは、単価と適用開始時点を AWS 側の料金表示で突き合わせてから社内のコスト試算を更新したい。