こんにちは、クラウドコストの翔太です。2026年8月21日、AWSからAWS Glue 6.0の一般提供開始がアナウンスされました。目を引くのは30%の価格削減という一文です。

ただ、この手の「値下げ」のアナウンスは、そのまま鵜呑みにして飛びつくと痛い目を見ることがあります。今回も同時にランタイムがApache Spark 4.1、Python 3.13、Scala 2.13へと上がっていて、要するにメジャーバージョンアップを伴う値下げです。この記事では、まず何が発表されたのかを整理したうえで、「じゃあ自分たちはどう判断すればいいのか」という順番で見ていきます。

そもそもAWS Glueの料金はどう決まるのか

先に前提の確認からいきます。ここを押さえておかないと「30%下がる」がどこに効くのかが分からないためです。

AWS Glueは、ETL（データの抽出・変換・ロード）ジョブを動かすためのサーバーレスなデータ統合サービスです。自分でSparkクラスターを立てて管理する代わりに、ジョブを投げれば裏側で必要な分だけ計算リソースが確保されて実行される、という仕組みですね。

課金の考え方はシンプルで、DPU（Data Processing Unit）× 実行時間が基本です。DPUは処理能力の単位で、ジョブに何DPU割り当てるかを設定し、そのジョブが動いていた時間に対して課金されます。つまりコストの構造は次の3つの掛け算になります。

  1. 1DPU・1時間あたりの単価
  2. ジョブに割り当てたDPU数
  3. ジョブの実行時間

自分も最初はGlueのコストを見たとき「ジョブの本数で決まるのかな」と思っていたのですが、実際には本数ではなく上の掛け算です。極端な話、1日1本しか動かしていなくても、そのジョブが重くて長時間回っていれば普通に高くなります。

そして今回下がったのは、この1番目の単価です。ここが効くのは、DPUも実行時間も変えていない既存ジョブに対しても、そのまま単価分だけ請求が下がるという点です。チューニングの手間ゼロで効く値下げというのは、FinOpsの文脈ではかなり珍しい部類に入ります。

（当然ですが、実際にいくら下がるかは各社の利用状況次第です。ご自身の環境での金額を確認する場合は、Cost ExplorerでGlueのコストを実際に見てみるのが確実です。）

6.0で何が変わったのか

AWSの発表で挙げられている主な変更点を整理すると、大きく次のようになります。

1. 30%の価格削減

上で書いたとおりです。単価が下がるので、同じジョブを同じ設定で動かしていれば、その分だけ請求額が下がります。

2. Apache Iceberg v3のフルサポート

Icebergは、S3上のデータをテーブルとして扱うためのオープンなテーブルフォーマットです。v3のサポートに伴い、自動シュレッディング対応のVARIANT型が使えるようになったとアナウンスされています。半構造化データ（JSONのような、スキーマが固定されていないデータ）を扱う場面で効いてくる部分ですね。

3. Hudi・Delta Lakeの新バージョン対応

Iceberg以外のテーブルフォーマットについても、より新しいバージョンがサポートされています。すでにHudiやDelta Lakeを使っている環境では、こちらのほうが直接的に効くかもしれません。

4. ランタイムのメジャーアップグレード

そして、コスト目線でいちばん注意が必要なのがここです。

「30%安いなら即移行」とはならない理由

ここからが本題です。単価が30%下がると聞くと、すぐにでもジョブのバージョンを6.0に上げたくなります。実際、コストだけを見ればそうすべきです。

ただ、Spark 3系から4系へのメジャーバージョンアップというのは、それなりに大きな変更です。メジャーバージョンが上がるということは、互換性のない変更（破壊的変更）が含まれている可能性がある、ということでもあります。Python 3.13、Scala 2.13という組み合わせも同様で、使っているライブラリがそのバージョンに対応しているかを確認する必要があります。

ここでコスト管理の視点から気をつけたいのは、「値下げによる削減額」と「移行にかかる工数」が別々の財布から出るという点です。前者はクラウド費用として毎月の請求書に現れますが、後者はエンジニアの時間として消えていきます。請求書だけを見ていると移行コストが見えないので、「安くなったのに、なぜかチーム全体では何も改善していない」という状態になりかねません。

なので、判断の順番としてはこうなると思っています。

  1. まず削減額の規模を見積もる。 Cost Explorerで直近数か月のGlueの利用額を確認します。月に数百円しか使っていないなら、30%下がっても金額としてはほぼ意味がありません。逆に月あたり数十万円規模で使っているなら、真剣に検討する価値があります。
  2. ジョブを重要度と複雑さで仕分けする。 すべてを一斉に上げる必要はありません。シンプルで壊れても影響が小さいジョブから試すのが定石です。
  3. 本番以外で先に動かす。 開発環境やステージング環境の同等ジョブを6.0で走らせて、結果が変わらないか、実行時間が延びていないかを確認します。
  4. 実行時間の変化まで見る。 ここが見落とされがちです。単価が30%下がっても、Spark 4.1で何らかの理由で実行時間が1.5倍になれば、トータルのコストは上がります。単価だけでなく、DPU数×実行時間まで含めて比較して初めて「安くなった」と言えます。

念のため補足しておくと、Sparkのメジャーバージョンアップで実行時間が必ず延びるという話ではありません。むしろ性能改善が入っていることのほうが多いはずです。ただ「たぶん速くなっているだろう」で済ませずに、自分たちのジョブで実測しましょう、というだけの話です。この「実測してから判断する」という姿勢は、クラウドコストの仕事をしていると本当に何度でも出てきます。

移行しない、という選択も一応ある

現実的な話として、すぐに移行できないケースもあります。既存のジョブが特定のライブラリバージョンに強く依存していたり、そもそも触れる人がいなかったり。

その場合、無理に移行せずに旧バージョンで動かし続けるという判断もあり得ます。ただしその場合は、「30%安くできたはずのコストを、移行しないという判断のために払い続けている」という事実は、チーム内で共有しておいたほうがいいと思います。判断としては妥当でも、それが暗黙のまま放置されると、半年後に誰もその判断の存在を覚えていない、という状態になります。

やらないと決めること自体は問題ではなくて、決めた記録が残っていないことのほうが後で困る、という話ですね。

コスト削減の打ち手は積み上げるもの

今回のような事業者側の値下げは、こちらの努力とは無関係にやってきます。だからこそ、追いかける仕組みを持っているかどうかで差が出ます。リリースノートを毎週見る担当を決めるでも、通知を飛ばすでも、方法は何でも構いません。

そしてもう一つ。こうしたサービス単位の削減施策は、積み上げてこそ効いてきますが、一つひとつの効果には限界があります。請求そのものの構造を変えるアプローチ、たとえばクラウドコストが提供している請求代行を使って、利用状況を一切変えずに請求額そのものに割引を適用するといった手も、サービス単位の最適化とは別レイヤーの打ち手として併用できます。どちらか一方ではなく、両方を並行して回していくのが現実的だと思っています。

まとめ

次回は、Glueに限らずETLジョブ全般のコストをどこから見ていくか、という切り口でも書ければと思います。

参考リンク

よくある質問（FAQ）

AWS Glue 6.0への移行は自動で行われますか？

いいえ、ジョブごとにGlueバージョンを指定する必要があります。既存のジョブは指定したバージョンのまま動き続けるため、値下げの恩恵を受けるには明示的に6.0へ変更する作業が必要です。

30%の値下げはすべてのGlueの利用に適用されますか？

適用範囲の詳細については、AWS公式の発表および料金ページで最新の条件をご確認ください。実際の請求への影響は、Cost Explorerで自社の利用状況を確認したうえで判断されることをおすすめします。

移行の影響を事前に確認する方法はありますか？

本番環境と同等のジョブを開発環境で6.0に設定して実行し、出力結果と実行時間を比較するのが確実です。実行時間が延びると単価の値下げ分を相殺してしまうため、コストの観点では実行時間の比較まで含めて確認することをおすすめします。

Apache Iceberg v3を使っていない場合、6.0に上げるメリットはありますか？

価格削減はテーブルフォーマットの利用有無に関わらず単価に効くため、Icebergを使っていないジョブでもコスト面のメリットはあります。ただしSpark 4.1へのメジャーアップグレードを伴うため、移行の手間と削減額を比較して判断してください。