Scheduling Amazon EMR Serverless Application
Can ZopNight schedule 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.
How the stop works
| Field | Value |
|---|---|
| Behaviour | application stopped and started via the EMR Serverless API on schedule, releasing pre-initialized capacity during off-hours. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
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.