Amazon EMR adds a 36-month LTS line, starting with Spark 4.1
Serguey Asael Shinder2 min readAmazon EMR now has a Long Term Support track. The first build on it is emr-spark-8.1.0, carrying Apache Spark 4.1; the notice is dated 22 September 2026.
Nominated builds of the AWS Spark runtime now carry 36 months of support. What lands in that window is limited: security holes and defects rated critical or high, plus anything that corrupts data — and AWS qualifies even that with "subject to availability". There is no extra charge. The stated point is that a production workload can sit on one build for longer and move when its owners choose.
The release itself carries several changes worth separating from the support policy. Apache Iceberg v3 is now fully supported, which brings geospatial types, timestamps at higher precision, and more schema evolution. A Spark SQL query can address a catalog by its name — across accounts, and for Amazon S3 Tables — with the table format worked out on the fly, whether it is Iceberg, Delta Lake or Hudi. The per-catalog entries in the Spark configuration are no longer needed for that. Fine-grained access control now covers more Iceberg operations and the Delta Lake VACUUM operation, so column-level and row-level permissions apply to a wider set of jobs. EMR on EKS clusters support Spark Connect endpoints with token-based authentication.
It is available in all Regions where EMR is available, across EMR on EC2, EMR on EKS and EMR Serverless.
What it means
Three years of patches for a data runtime is a scheduling change more than a technical one, and the scheduling is the expensive part. A Spark upgrade is rarely just a version bump: it moves UDF behaviour, connector versions and occasionally query results, so the work is validation rather than deployment. Being able to choose when to do that, instead of being moved by a support window, is the actual product here.
Read the support wording precisely: critical and high severity security, bug and data-corruption fixes, subject to availability. That is narrower than "maintained" — a performance regression or a moderate-severity issue is not promised, and the qualifier is doing real work.
The catalog-by-name change is the one that will show up in day-to-day code. Removing per-catalog registration from Spark configuration moves a piece of environment-specific setup out of deployment and into the query, which is usually where teams wanted it.