All cheat sheets
Databasescheat sheet

AWS Glue Flex Execution

Flex Execution is economy shipping for Glue jobs: same code, same engine, ~34% less per DPU-hour, in exchange for the job starting when AWS has spare capacity — usually within minutes. One setting, no refactor, ideal for batch ETL.

Last reviewed: July 14, 2026

TL;DR: Flex Execution (late 2022) runs the exact same Glue job on lower-priority capacity for ~34% less per DPU-hour. The only thing you give up is a guaranteed-instant start — Flex jobs queue behind standard jobs and typically begin within a few minutes. For the batch-ETL majority of Glue spend (overnight, weekly, backfill, reconciliation), where the output is consumed hours later, that scheduler precision is a phantom requirement and Flex is effectively free money.

The numbers

  • Standard ~$0.44/DPU-hour → Flex ~$0.29/DPU-hour (us-east-1) — the ~34% cut. A DPU is a bundle of CPU + memory + I/O, billed per second.
  • Observed start delay: seconds to a few minutes typically; 3–10 min common; occasionally 10–20 min at AWS peak; rarely longer during region-wide crunches.
  • Worked example: 10 DPUs × 2 hrs/day = 600 DPU-hours/mo → standard $264/mo vs Flex $174/mo ($90/mo, ~$1,080/yr on one job). A team with $5,000/mo of Glue spend converting half its jobs saves ≈ $5,000 × 50% × 34% = $850/mo.
  • Field examples: nightly fintech log processing saved ~$1,200/mo (never missed the 6 AM dashboard); a weekly warehouse rebuild saved >$3,000/mo; monthly HIPAA reports on a 48-hour window saved ~$800–900/run.

Do this

  1. List Glue jobs sorted by monthly DPU-hours and flip the top spenders first — the 34% scales linearly with what each job costs today.
  2. For each, ask when the output is actually consumed — if there's >30 min of slack between "could start" and "must finish," it's a Flex candidate.
  3. Turn it on — one setting, no code change: Job details → Advanced properties → Execution class → Flex, or CLI --execution-class FLEX.
  4. Test on one job for two weeks — graph submitted-vs-started timestamps (submission time in CloudWatch Logs, actual start in the job run record); most teams find the delay smaller than feared.
  5. Alarm on the delta if a sustained queue wait would ever break a downstream SLA, then flip the rest of the easy wins.

Gotchas

  • Only the start is delayed — once a Flex job begins it's identical to a standard job: same engine, same retries, same failure modes. There's no lower-tier "Flex hardware."
  • The deadline test is "when must it finish," not "when must it start" — most "urgent" jobs are merely scheduled at a habitual time.
  • Bursty peak-hour delays (10–20 min) are the realistic worst case for eligible jobs — size your slack against the 95th-percentile wait, not the median.

Skip this if

  • The pipeline is real-time or near-real-time (fraud detection, streaming joins, live dashboards), sits in a tight Step Functions chain with per-step SLAs, or feeds freshness-critical/user-facing data.
  • You want to compound the savings on the same jobs — pair with Glue Auto Scaling (right-size DPU count) and AWS Glue Job Bookmarks (skip already-processed data on incremental runs); the three stack roughly additively.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Glue jobs for Flex Execution savings.
Use the AWS CLI with READ-ONLY credentials. Do not create, modify, or
delete anything — report findings and recommended (unapplied) fixes only.

1. Inventory: aws glue get-jobs — capture each job's ExecutionClass
   (STANDARD vs FLEX), WorkerType/NumberOfWorkers (DPU footprint), and
   any trigger/schedule.
2. Spend ranking: aws glue get-job-runs per job — sum DPU-hours over 30
   days (ExecutionTime × MaxCapacity/DPUs). Rank by monthly DPU-hours;
   standard rate ~$0.44/DPU-hr vs Flex ~$0.29/DPU-hr (~34% off).
3. Flex eligibility: for each high-spend STANDARD job, determine the slack
   between "could start" and "must finish" — when is the OUTPUT actually
   consumed? >~30 min of slack = Flex candidate (overnight batch, weekly
   aggregations, backfills, monthly reconciliation).
4. Disqualify: real-time/near-real-time pipelines, tight Step Functions
   chains with per-step SLAs, freshness-critical/user-facing jobs.

Report a table: job | execution class | DPU-hrs/mo | current $/mo | est.
Flex $/mo | downstream slack | Flex candidate? Recommend testing
submitted-vs-started timestamps on one job for a week. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The AWS Glue Flex Execution walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough