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

  1. 01Runs the open-source big data stack — Spark, Hive, Presto/Trino, HBase, Flink — with AWS provisioning and configuring the EC2 fleet
  2. 02Three node types: primary (coordinates), core (runs tasks and holds HDFS), task (compute only, optional)
  3. 03Storage: HDFS lives on core nodes and dies with the cluster; EMRFS reads and writes S3 directly, so data outlives the cluster
  4. 04Transient clusters run one job and self-terminate; long-running clusters stay up for interactive and ad hoc work
  5. 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

  1. 01Lifting a decade of on-prem Spark and Hive jobs into AWS — same frameworks, someone else's hardware
  2. 02Nightly data lake ETL: read raw CSV and JSON from S3, write partitioned Parquet back for Athena and Redshift to query
  3. 03Transient cluster for a monthly billing run — spins up at 2am, chews through the month's usage records, terminates itself before anyone wakes up
  4. 04Backfills and reprocessing: replaying two years of archived clickstream in an afternoon by throwing 200 Spot task nodes at it
  5. 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

  1. 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
  2. 02Billed per second with a one-minute minimum, so 10 nodes for 10 hours costs the same as 100 nodes for 1 hour
  3. 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
  4. 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
  5. 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

Commonly confused with

References