Amazon EMR
Managed clusters for running open-source big data frameworks like Spark and Hadoop on AWS.
Verified against AWS documentation · 2026-09-09
Key facts
- 01Runs the open-source big data stack — Spark, Hive, Presto/Trino, HBase, Flink — with AWS provisioning and configuring the EC2 fleet
- 02Three node types: primary (coordinates), core (runs tasks and holds HDFS), task (compute only, optional)
- 03Storage: HDFS lives on core nodes and dies with the cluster; EMRFS reads and writes S3 directly, so data outlives the cluster
- 04Transient clusters run one job and self-terminate; long-running clusters stay up for interactive and ad hoc work
- 05Four deployment flavors: EMR on EC2 (the default), EMR Serverless (no cluster), EMR on EKS, EMR on Outposts
Exam triggers
Phrases and scenarios that point here.
- "Hadoop", "Spark", "Hive", "Presto", "HBase", "Flink" named in the question → EMR, almost always
- Migrate an on-premises Hadoop or Spark cluster to AWS without rewriting the jobs
- "Petabyte-scale", "massive log/clickstream processing", "big data analytics" with code that already exists
- Team needs control over the framework and its version → EMR, not a fully abstracted service
Not this service
- Serverless ETL with a built-in data catalog, nothing to size → AWS Glue
- Ad hoc SQL straight against S3, nothing to run or manage → Amazon Athena
- Data warehouse for BI dashboards and reporting → Amazon Redshift
Use cases
- 01Lifting a decade of on-prem Spark and Hive jobs into AWS — same frameworks, someone else's hardware
- 02Nightly data lake ETL: read raw CSV and JSON from S3, write partitioned Parquet back for Athena and Redshift to query
- 03Transient cluster for a monthly billing run — spins up at 2am, chews through the month's usage records, terminates itself before anyone wakes up
- 04Backfills and reprocessing: replaying two years of archived clickstream in an afternoon by throwing 200 Spot task nodes at it
- 05A long-running cluster as a shared analytics sandbox, with EMR Studio notebooks for data scientists poking at the lake in PySpark
How it's charged
- 01EMR on EC2 adds a per-instance EMR fee on top of the EC2 and EBS bill — you pay for the servers plus the management layer
- 02Billed per second with a one-minute minimum, so 10 nodes for 10 hours costs the same as 100 nodes for 1 hour
- 03The meter runs from when the cluster is ready until you shut it down, job or no job — an idle cluster left up over a long weekend is the classic EMR bill shock
- 04EMR Serverless and EMR on EKS bill on vCPU-hours and GB-memory-hours actually consumed instead of whole instances — nothing idle to forget about
- 05Cost levers: Spot for task nodes (up to ~90% off On-Demand), Reserved Instances or Savings Plans for the always-on primary and core, auto-termination for transient clusters