AWS Glue 6.0: turn a forgotten line item into 30% savings

Your Glue job list may contain definitions that never name a runtime. If a job does not specify a Glue runtime, it defaults to 5.1 and continues at the previous pricing. AWS Glue 6.0 reached general availability on Aug. 21, 2026, and it carries a 30% price reduction.

The audit is a version check, not a feature tour. You need the jobs that can move, the meters that actually drop, and the compatibility traps that can turn a savings into a failed pipeline.

Most teams have a mix of jobs created before the current runtime and jobs added after. The older jobs are the ones most likely to lack an explicit runtime, so sample them first when the list is long. A short list can be checked end to end; a long one needs a sample that still represents your production load.

The default runtime keeps the old bill

AWS Glue's pricing model separates hourly, second-billed charges for crawlers and ETL jobs from a simplified monthly charge for Data Catalog storage and access. In US East (N. Virginia), the reported DPU-hour rate for the applicable workload is $0.308, compared with $0.44 previously. Use that rate when you re-bill the estimate, and keep the non-workload lines separate.

For jobs in another region, pull the regional DPU-hour rate for the same workload and do the same math. If the regional rate is not obvious, use the same workload type and the same billing period before you compare the invoice. That keeps the estimate tied to the workload that changed price. Compare like with like, and let the invoice show which lines actually moved.

The rate change is the compatibility test

The runtime stack is Apache Spark 4.1, Python 3.13, and Scala 2.13. Test the Spark part before you change the version, using a job that touches your most important tables rather than a trivial script.

When the job reads Iceberg tables, check the cross-engine path before you declare the migration safe. Iceberg tables created in AWS Glue 6.0 cannot be read by Athena SQL, so cross-engine compatibility requires Iceberg v2.

Tables can work in the job that wrote them and still fail in the query engine that reads them later. That constraint is easy to miss when the savings look clean, so the test should be boring: pick a job that already runs in production, run it on the new runtime, and compare the output. The comparison should be close enough to trust, not perfect enough to delay the audit forever.

If the output matches, you have evidence. If it does not, you have a reason to wait. A failed migration is worse than a missed discount, because a failed pipeline costs time, and that time usually lands on the person who owns the data.

The checklist makes the cut real

Each item is a quick check. The four steps move from the job list to the invoice to the production test.

• Check the job list for definitions that do not name a runtime.
• Recalculate a month of DPU-hours at the 6.0 US East (N. Virginia) rate.
• Mark the discounted Spark meter separately from the catalog and crawler meters.
• Check a job for Spark 4.1 and Iceberg compatibility before flipping the version.

Inventory saves the audit by catching jobs that lack an explicit runtime. Re-billing turns the headline into a number you can defend: count the workload hours, apply the new rate, and see whether the savings survive your actual mix.

The meter check keeps you from overclaiming. Catalog and crawler lines stay separate in the estimate, so the invoice may improve without matching the headline. This keeps the number defensible in a budget review.

Compatibility is the brake. A job can save money on paper and still fail because the runtime changed underneath it.

Keep the list next to the job definitions. When a new job is created, make the runtime explicit from the start. That prevents the next audit from becoming archaeology.

Do the audit before you flip the version, not after the bill arrives. Leave jobs without an explicit runtime on the old runtime until you have a reason to move them.