# Amazon EMR Serverless Application

> EMR Serverless bills per vCPU-second and GB-second that jobs actually consume, but pre-initialized capacity bills while sitting warm, turning a serverless application back into an always-on cluster. ZopNight discovers applications on the 6-hour cycle, stops and starts them on schedule via the EMR Serverless API, releasing warm capacity off-hours.

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

---

EMR Serverless runs Spark and Hive jobs without cluster management, billed per vCPU-second and GB-second consumed, with optional pre-initialized capacity billed while idle. Applications with warm capacity configured behave like always-on clusters cost-wise.

## Consumption pricing with a warm-capacity asterisk

The core meter is honest serverless: workers spin up per job and bill vCPU-seconds and GB-seconds (plus storage-seconds for shuffle disk beyond the free allocation) only while jobs run. The asterisk is pre-initialized capacity: workers kept warm so jobs start in seconds instead of minutes. Warm workers bill their full rates from the moment the application starts until it stops, jobs or no jobs. An application with generous pre-initialized capacity and an overnight gap in its job schedule is a cluster again, just with better marketing.

## Scheduled stops for warm applications

ZopNight discovers EMR Serverless applications automatically on the 6-hour cycle, with per-application cost from Cost Explorer or CUR 2.0. Applications are schedulable: the EMR Serverless API stops them on the configured schedule and starts them before working hours, which releases pre-initialized capacity during off-hours while leaving the application definition intact. A stopped application restarts in place with its configuration untouched. Pre-initialized capacity recommendations handle the rest: applications whose warm worker counts exceed what their job start-latency requirements justify.

## The serverless-in-name-only pattern

The failure mode is incremental: an application starts purely on-demand; a stakeholder complains about job start latency; pre-initialized capacity gets added; the latency complaint dies and so does the scrutiny. From then on the application bills around the clock. Auto-stop settings mitigate this, since applications can stop themselves after idle minutes, but pre-initialized configurations are precisely the ones where teams disable auto-stop to keep workers warm, completing the circle.

## Verifying application posture

The EMR Studio console lists serverless applications with state, pre-initialized capacity configuration, and auto-stop settings. The job runs history against the capacity timeline answers the core question: how many warm hours actually met a job, and how many were pure readiness.