# Scheduling Amazon EMR Serverless Application

> Scheduled stops shut the EMR Serverless application down and release its pre-initialized capacity, the warm workers that bill 24/7 from the moment the application starts, jobs or no jobs. A stopped application rejects new job submissions until the scheduled start, and per-job charges were already usage-based.

Source: https://zop.dev/integrations/aws/emr-serverless/schedule
Updated: 2026-08-19

---

## Pre-initialized capacity is the target

EMR Serverless bills per job by the second, which sounds like nothing to schedule.
Pre-initialized capacity is the exception. Warm workers configured for fast job starts bill from the
moment the application is started, around the clock, whether any job runs or not. That standing
charge is what the scheduled stop releases. Applications without pre-initialized capacity have
little to gain from a schedule; applications with a big warm pool gain the whole pool's
overnight cost.

## Stopped means no submissions

A stopped application refuses new jobs. An orchestrator that submits work at 2am (Airflow,
Step Functions, a cron on somebody's laptop) gets an error, not a queued job. Line the
schedule up with the batch calendar, or have the orchestrator start the application itself and
let the schedule handle the evening close.

## The auto-stop interaction

Applications ship with an idle auto-stop, 15 minutes by default. Teams disable it precisely
because they configured warm capacity and want fast starts all day. That is the configuration a
calendar schedule serves best: warm and instant from 7am to 7pm, off and free outside it,
instead of choosing between always-warm and always-cold.

## Starting is quick, warming is the slow part

The application start itself is fast, but the pre-initialized workers take time to provision
after it. The first job of the morning submitted seconds after the start cron may run cold and
pay the setup latency the warm pool exists to remove. Give the start a few minutes of lead
before the first scheduled job.

## Counting the saving

The arithmetic is worker-hours of warm capacity avoided. A pool of 10 warm workers idle from
7pm to 7am is 120 worker-hours a night that currently buy nothing. Job costs do not change;
they were always pay-per-run.

Worker sizing multiplies the effect. Pre-initialized capacity bills for the vCPU, memory and
storage each warm worker is configured with, so trimming an oversized warm pool and scheduling it
compound each other.