TL;DR. EMR on EKS pricing in US East is now $0.007084 per vCPU-hour and $0.000777875 per GB-hour of requested pod resources, after AWS cut both rates by 30% on October 23, 2026. On a fully requested
r5.2xlarge, that moves the EMR charge from $0.1521 to $0.1065 a node-hour, below the $0.126 EMR on EC2 charges for the same instance. It was above it before. The cut is about 7% of a full node-hour bill, it leaves EMR on EC2 cheaper on Graviton, and because the charge follows pod requests, what your executors request still matters more than the rate.
AWS announced the cut on October 23: "Amazon EMR announces a reduction of 30 percent in the EMR charge added to EKS when running EMR on EKS", applied automatically in every region. This post prices one node-hour and one month under the old and new rates, compares them with EMR on EC2, and shows where the remaining money sits.
The EMR on EKS bill has three lines, and the cut touches one
AWS's EMR pricing page splits the bill into three parts:
- The EMR charge. Per vCPU-hour and per GB-hour, "based on requested vCPU and memory resources for the Task or Pod", billed from the start of the EMR image download until the pod terminates, rounded up to the nearest second.
- The capacity under the pods. EC2 instances and EBS volumes for your worker nodes, or Fargate vCPU and memory.
- The EKS cluster. $0.10 an hour per cluster, shared by every job on it. EKS pricing puts it at $0.60 an hour on a Kubernetes version in extended support.
The cut applies to the first line only. In AWS's words, "the underlying Amazon EKS charges remain unchanged".
The rates, from the AWS Price List API for US East (N. Virginia), comparing the September 2026 version with the current one:
| EMR on EKS rate, US East | Before the cut | After the cut |
|---|---|---|
| Per vCPU-hour | $0.01012 | $0.007084 |
| Per GB-hour | $0.00111125 | $0.000777875 |
The same rates apply on EC2-backed and Fargate-backed EKS. EMR Serverless, at $0.052624 per vCPU-hour and $0.0057785 per GB-hour on the same page, is a different product that bundles the capacity; EMR Serverless pricing prices the same kind of job on it, with the break-even against EMR on EC2.
Per node, the cut moves EMR on EKS below EMR on EC2 on Intel instances
On EMR on EC2, AWS says "the Amazon EMR price is added to the Amazon EC2 price": a flat EMR price per instance-hour. EMR on EKS charges per requested vCPU and GB, whatever instance runs the pod. The fair comparison is one node-hour with pods requesting the whole node.
Price list values for US East, read October 28, 2026: EMR on EC2 prices from the EMR price list, EC2 on-demand prices from AWS's EC2 price data.
| Instance | EC2 on-demand | EMR on EC2 charge | EMR on EKS charge, before | EMR on EKS charge, after |
|---|---|---|---|---|
| r5.2xlarge (8 vCPU, 64 GB) | $0.504 | $0.126 | $0.1521 | $0.1065 |
| r6g.2xlarge (8 vCPU, 64 GB, Graviton) | $0.4032 | $0.1008 | $0.1521 | $0.1065 |
| m5.xlarge (4 vCPU, 16 GB) | $0.192 | $0.048 | $0.0583 | $0.0408 |
| m6g.xlarge (4 vCPU, 16 GB, Graviton) | $0.154 | $0.039 | $0.0583 | $0.0408 |
The EKS figure is 8 × $0.007084 + 64 × $0.000777875 for the 8 vCPU nodes, and the same formula with the old rates for the "before" column. EC2 lists memory in GiB; like AWS's own EMR on EKS example on the pricing page, this post prices the node's 64 at the per-GB rate.
Before October 23, a fully requested EKS node paid a higher EMR charge than the same instance on EMR on EC2. Now it pays 15.5% less on r5.2xlarge and 15% less on m5.xlarge.
On Graviton, EMR on EC2 keeps the lower charge. The EMR on EC2 price is set per instance type, and it is lower for these Graviton instances; the EMR on EKS rate is the same for every instance family. On an r6g.2xlarge, EMR on EC2 charges $0.1008 against $0.1065 on EKS.
The cut is about 7% of a full node-hour bill
The headline is 30%, but the EMR charge is the smaller part of the hour. On a fully requested r5.2xlarge with on-demand EC2:
| Before | After | |
|---|---|---|
| EC2 instance | $0.504 | $0.504 |
| EMR on EKS charge | $0.1521 | $0.1065 |
| Node-hour total | $0.6561 | $0.6105 |
| EMR share of the hour | 23% | 17% |
The node-hour drops 6.95%. On Graviton nodes, where the instance is cheaper, the same arithmetic gives 8.2%.
Consider a hypothetical team whose Spark jobs keep the equivalent of 40 fully requested r5.2xlarge nodes busy 12 hours a day for 30 days: 14,400 node-hours, on one EKS cluster running all month (730 hours at $0.10).
| Month, US East list prices | EMR on EKS, before | EMR on EKS, after | EMR on EC2, same node-hours |
|---|---|---|---|
| EC2 instances | $7,257.60 | $7,257.60 | $7,257.60 |
| EMR charge | $2,189.95 | $1,532.97 | $1,814.40 |
| EKS cluster | $73.00 | $73.00 | n/a |
| Total | $9,520.55 | $8,863.57 | $9,072.00 |
The cut saves this team $656.98 a month, 6.9% of the bill, and moves EMR on EKS from $448.55 above the EMR on EC2 equivalent to $208.43 below it. Take the saving; it needs no action. It does not change which half of the bill is larger.
The rate you pay matters less than what your pods request
EMR on EKS bills what each pod requests, so the request is the number to manage. For a Spark executor on Kubernetes, the Spark docs say "the memory request and limit are set by summing the values of spark.{driver,executor}.memory and spark.{driver,executor}.memoryOverhead". The overhead defaults to 10% of executor memory with a minimum of 384 MiB for JVM jobs, and to 40% for non-JVM jobs such as PySpark on Kubernetes, per the Spark configuration reference.
Memory is 47% of the EMR charge on a fully requested r5.2xlarge: $0.0498 of the $0.1065. Executors sized "to be safe" pay that charge on memory they never touch, every second the pod is alive.
Three places the charge accrues without work:
- Oversized executor memory. A 4-core JVM executor with
spark.executor.memory=28grequests about 30.8 GB with overhead. At 14g it requests about 15.4 GB, and its EMR charge falls from $0.0523 to $0.0403 an hour, 23% less, before counting the EC2 capacity it frees. - Executors that sit idle. The charge runs until the pod terminates. With dynamic allocation, Spark removes an executor that has been idle for
spark.dynamicAllocation.executorIdleTimeout, 60 seconds by default per the configuration reference. A job that holds a fixed executor count through a long single-threaded stage pays for all of them. - Image pulls. Billing starts when the EMR application image starts downloading, so a slow pull of a large custom image is billed time on every new pod.
None of these is fixed by a price cut, and each also shrinks the EC2 half, because smaller requests pack more pods per node.
Attribute the bill per job before you change anything
The two halves of an EMR on EKS bill arrive in different shapes. The EMR charge carries the job: in AWS's own cost monitoring walkthrough, the Cost and Usage Report line items for the EMR Containers product family hold the virtual cluster and job run IDs in line_item_resource_id. The EC2 nodes carry no job at all. The same walkthrough gets node cost per job from Kubecost, aggregating by pod and by the emr-containers.amazonaws.com/job.id label.
Join the two or the cheaper half looks like the whole bill. On the hypothetical month above, the EMR charge across all jobs after the cut is $1,532.97 out of $8,863.57 in total. A per-job view that reads only the EMR line misses the $7,257.60 of EC2 underneath. The same split shows up on Databricks classic compute, where the instance costs about twice the DBUs on Jobs Compute, and across a whole estate in the cost per pipeline.
The case for moving to EMR on EKS now, and where it stops
The strongest objection to this post: for an x86 fleet the cut makes EMR on EKS the cheaper EMR, per node, on top of the packing a shared Kubernetes cluster already gives. Teams that run many short Spark jobs side by side on EMR on EC2 pay the per-instance charge for every hour a cluster is up, idle or not; on EKS the EMR charge stops when the pods do. For them, the cut tips a case that was already close.
That holds, with three limits. On Graviton the EMR on EC2 charge is still lower per node. The saving is about $0.046 per fully requested r5.2xlarge node-hour, so a move pays back only if the engineering work behind it, which this post does not price, costs less than the yearly saving. And the bigger lever, request sizing, is open on either deployment.
Under Spot or discounted EC2 the cut matters more, since the EMR charge becomes a larger share of the hour. As a hypothetical, at half the on-demand EC2 price the same r5.2xlarge node-hour drops from $0.4041 to $0.3585, 11.3%.
The limits of this post: US East list prices read October 28, 2026; other regions and negotiated rates differ. The node-hour figures assume pods request a whole node, which is an upper bound: nodes also run system daemons, and the kubelet's Node Allocatable feature exists to set capacity aside for them. We did not run Spark jobs for this post; every figure is computed from AWS's published prices.
Where Datapace fits
EMR on EKS spreads one job's cost across an EMR line that knows the job and an EC2 line that does not, and the same split repeats across the warehouses, databases and pipelines around it. Datapace is building one map of your data estate with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. For the method applied to every pipeline in the estate, read data pipeline cost: how to get the cost per pipeline.
Sources
- AWS, Amazon EMR on EKS reduces EMR charge by 30 percent, October 23, 2026.
- AWS, Amazon EMR pricing (EMR on EKS billing basis, EKS cluster fee, EMR Serverless rates, pricing examples) and Amazon EKS pricing.
- AWS Price List API, Amazon EMR offer for US East: current version and September 2026 version, read October 28, 2026.
- AWS, EC2 on-demand price data for US East Linux, read October 28, 2026.
- AWS Big Data Blog, Cost monitoring for Amazon EMR on Amazon EKS, June 9, 2023.
- Apache Spark, Running Spark on Kubernetes and Spark configuration.
- Kubernetes, Reserve compute resources for system daemons.
