What Is Amazon EMR? EC2 vs Serverless vs EKS Explained

Simple explanation

Think of Amazon EMR like a temporary factory floor you rent by the hour. You have five billion records to sort. You hire the factory (the cluster), hand over your instructions (the Spark job), and the factory splits the work across hundreds of machines running in parallel. When the job finishes, you return the keys and stop paying.

The raw materials — your data — live in Amazon S3, not on the factory floor. The factory just processes them. This separation of compute and storage is the core design idea behind EMR. You can shut the factory down tonight and your data is still intact in S3. Spin up a new one tomorrow.

The frameworks EMR runs, primarily Apache Spark, are open-source distributed processing engines that split a large computation across many machines in parallel. EMR’s job is to provision those machines, install the software, wire them together, and manage the cluster lifecycle for you.

How Amazon EMR works

When you submit a job to EMR, here is what happens in order:

1. You create a cluster (or application, for Serverless) and specify the frameworks to install, instance types, and cluster size.
2. EMR provisions the EC2 instances, installs Spark (or Hive, Presto, etc.), configures YARN and networking, and brings the cluster online.
3. You submit a job: a Spark script stored on S3, passed as a step or job run.
4. The Spark driver splits the input data into partitions. Executors on the worker nodes process those partitions in parallel across all machines.
5. Results are written back to S3. The cluster terminates or stays running, depending on your configuration.

Your raw data, scripts, and output all live in S3. The cluster is purely compute: it reads from S3, processes in memory, and writes back to S3. This is what makes data lake architectures practical — the data lake sits in S3 and EMR is one of several tools that can process it, alongside Glue and Athena.

AWS manages: cluster provisioning, software installation, YARN configuration, auto-scaling, and fault recovery.
You manage: your job code, Spark configuration tuning, instance type selection, and cost controls.

EMR deployment options

Amazon EMR offers three deployment models. They share the same underlying frameworks but differ significantly in how much infrastructure you manage.

Node types in an EMR on EC2 cluster

An EMR on EC2 cluster works like a construction crew with three roles: one site manager, a crew of builders, and optional day labourers you bring in for heavy lifting.

• Primary node (the site manager): One instance that coordinates the cluster. Runs YARN and the Spark driver. If it fails, the cluster is lost. Always use a larger, On-Demand instance here.

• Core nodes (the builders): The main workers. Run Spark executors and store HDFS data if you use it. Avoid removing core nodes mid-job as it can cause data loss. Most workloads need 4 to 20 core nodes.

• Task nodes (the day labourers): Optional extra workers that run executors but store no HDFS data. Safe to add or remove mid-job. Use these for Spot Instances. If a task node is reclaimed, the job slows but does not fail.

When to use Amazon EMR

EMR is the right choice when the job is too large, too custom, or too performance-sensitive for simpler tools. Here are concrete scenarios:

• Large Spark ETL pipelines. You have 500 GB to multiple TB of raw data that needs to be cleaned, joined, and transformed daily. Glue can handle this, but you need fine-grained Spark configuration (executor memory, shuffle partitions, dynamic allocation) to hit your SLA. EMR gives you that control. See the Running Spark on AWS guide for job submission details.

• ML data preprocessing at scale. Training a large model requires feature engineering across hundreds of millions of rows. EMR Spark can distribute this across a large cluster in minutes. The output lands in S3 and feeds directly into a training pipeline.

• Repeated large-scale aggregations. You run an aggregation job every hour that joins three tables, each hundreds of GB. The job is predictable and runs frequently enough that a warm EMR on EC2 cluster is cheaper than Glue DPU billing or EMR Serverless cold-starts.

• Multi-framework workloads. Your pipeline uses Spark for transformation, Hive for SQL queries over HDFS tables, and HBase for random lookups. Only EMR gives you all three on one cluster. Glue is Spark-only.

• Workloads that have outgrown Glue. AWS Glue has maximum DPU limits and less flexibility in Spark version management. When a Glue job consistently hits DPU caps or fails due to configuration constraints, migrating to EMR is the natural next step.

When NOT to use Amazon EMR

EMR is more complex and more expensive than simpler alternatives for jobs that do not need it. Be honest about when to avoid it.

• Standard ETL that fits within Glue. If your job reads from S3, transforms, and writes to Redshift or S3, and you are not hitting Glue’s DPU limits, use AWS Glue. It is serverless, integrates with the Glue Data Catalog, and requires far less setup.

• Ad-hoc SQL queries on S3 data. If you are exploring a dataset or running one-off analytical queries, Athena is the right tool. It charges per byte scanned, requires no cluster, and results appear in seconds to minutes.

• Simple event-driven row processing. Transforming individual records as they arrive belongs in AWS Lambda, not a distributed cluster. Lambda handles this in milliseconds with no cluster overhead.

• Teams new to distributed systems. EMR requires understanding Spark configuration, cluster sizing, and job tuning. If your team is new to distributed processing, the time investment in Glue is almost always worth it first.

• Interactive dashboards and BI queries. EMR is a batch processing tool, not a sub-second query engine. Use Amazon Redshift for warehouse workloads, or Athena for serverless SQL.

EMR vs Glue vs Athena

All three services can process large amounts of data stored in S3. The difference is in what they abstract away and what they expose.

The typical progression on a data team: start with Athena for exploration, move to Glue for repeatable ETL, and bring in EMR when Glue jobs hit performance limits or you need framework flexibility.

EMR Serverless vs AWS Glue: the closest comparison

EMR Serverless and AWS Glue are the most directly comparable options. Both are serverless, both run Spark, and both charge for compute consumed rather than idle time. The practical differences:

• Glue uses the Glue Data Catalog natively, includes a visual job builder (Glue Studio), and handles IAM and logging boilerplate for you. It abstracts more of the plumbing.
• EMR Serverless gives you a vanilla Spark runtime you configure directly. You get more Spark version choices, tighter performance control, and higher capacity for very large jobs. You also set up IAM roles and monitoring yourself.
• For a team already invested in Glue’s catalog and workflows, staying in Glue is the right call. For teams that need raw Spark capability without cluster management, EMR Serverless closes that gap.

How EMR fits into a data platform

A common pattern in an AWS data lake:

1. Raw data lands in S3. Application logs, database exports, event streams. All arrive in a raw S3 prefix, untouched.
2. EMR processes it. A daily Spark job reads the raw data, cleans it, joins it with reference data, and writes the output as Parquet to a processed S3 prefix.
3. Output goes back to S3. The processed data is partitioned by date and registered in the Glue Data Catalog so downstream tools can find it.
4. Downstream tools query or consume it. Athena runs SQL on the processed files. Redshift Spectrum joins them with warehouse tables. A BI tool reads the curated aggregations. See the data pipeline design guide for how these pieces connect end to end.

For workloads where processed data goes to Redshift, the ETL vs ELT distinction matters. EMR performs the transformation before loading (ETL). Redshift Spectrum or dbt can transform after loading (ELT). Neither is universally better: the right choice depends on your compute budget and where your team’s skills are stronger.

Pricing and cost traps

EMR has two concurrent charges on every EC2 cluster:

1. EC2 instance cost: the normal EC2 price for the instances in your cluster (On-Demand, Reserved, or Spot).
2. EMR service fee: an additional per-instance-hour charge on top of EC2 costs, roughly 25 to 30 percent of the On-Demand EC2 price depending on instance type.

For EMR Serverless, you pay for vCPU-hours and GB-hours of memory consumed during execution only. There is no idle cost between jobs.

Where cost surprises happen

• On-Demand task nodes. Task nodes hold no HDFS data, so they are safe to run on Spot Instances, which are typically 70 to 90 percent cheaper than On-Demand. If a Spot task node is reclaimed, the job slows but does not fail. Run primary and core nodes On-Demand; use Spot for task nodes.

• Oversized clusters. More nodes does not always mean faster jobs. Spark jobs are often bottlenecked by shuffle or data skew, not raw CPU. Profile with Spark UI before scaling up. See the EC2 cost optimisation guide for rightsizing guidance.

• EMR Serverless cold-starts for frequent jobs. Each EMR Serverless job run takes 1 to 3 minutes to provision compute. For jobs running every 10 to 15 minutes, this overhead adds up quickly. A warm EMR on EC2 cluster is cheaper in that pattern.

Creating a cluster and submitting a job

# Create an EMR on EC2 cluster with Spark
aws emr create-cluster \
  --name "my-spark-cluster" \
  --release-label emr-7.0.0 \
  --applications Name=Spark \
  --ec2-attributes KeyName=my-key-pair \
  --instance-type m5.xlarge \
  --instance-count 3 \
  --use-default-roles \
  --log-uri s3://my-emr-logs/

# Submit a Spark step (job) to the cluster
aws emr add-steps \
  --cluster-id j-XXXXXXXXXXXX \
  --steps '[{
    "Name": "Process Orders",
    "ActionOnFailure": "CONTINUE",
    "HadoopJarStep": {
      "Jar": "command-runner.jar",
      "Args": [
        "spark-submit",
        "--deploy-mode", "cluster",
        "s3://my-scripts/process_orders.py"
      ]
    }
  }]'

For EMR Serverless, you create an application once and submit individual job runs to it:

# Create an EMR Serverless application (one-time setup)
aws emr-serverless create-application \
  --name my-spark-app \
  --type SPARK \
  --release-label emr-7.0.0

# Submit a job run
aws emr-serverless start-job-run \
  --application-id 00faaaaaaaaaaaaaa \
  --execution-role-arn arn:aws:iam::123456789012:role/EMRServerlessRole \
  --job-driver '{
    "sparkSubmit": {
      "entryPoint": "s3://my-scripts/process_orders.py",
      "sparkSubmitParameters": "--conf spark.executor.cores=4"
    }
  }'

For a full walkthrough including PySpark scripts, S3 read/write patterns, and job monitoring, see Running Apache Spark on AWS with EMR.