Amazon EMR
Managed Spark, Hive, Trino, Flink and HBase on open-source versions you pick. How you run it, on clusters or serverless, decides how you pay.
You bring the job. EMR runs the framework and the cluster under it.
Same frameworks, three ways to deploy.
Clusters you size
Primary, core and task nodes you pick. Task nodes add compute without storing data, so they run on Spot. Managed scaling grows and shrinks the cluster.
No cluster to manage
You create an application and submit jobs. EMR adds and removes workers within your limits and bills the vCPU, memory and storage they use.
On your Kubernetes
Run jobs as pods on an existing EKS cluster, so Spark shares the platform your other workloads already run on.
A few decisions set the bill and the speed.
Which deployment option
EMR on EC2 gives the most control over versions and tuning for long-running or very large jobs. Serverless skips sizing. EKS reuses a cluster you run.
On EC2: node mix and scaling
Core nodes store data and stay On-Demand. Task nodes only compute, so they run on Spot for up to 90% off, with managed scaling adding them on demand.
Release version and table format
The release label fixes your Spark, Hive and Trino versions. Open table formats like Iceberg bring atomic commits and concurrent writes on S3.
Bar values are illustrative, not measured figures. Spot savings vary by instance type and region.
An EMR bill, in one line.
Migration & modernization
To a modern data stack, workload by workload, with agents doing the repetitive part.
Read the approach →The one-page Amazon EMR field guide.
Best practices, cost traps and performance checks, in the order you should run them. Printable, no fluff.