AWS Benchmarks S3 Express One Zone for Spark on EMR, Cutting Query Latency and Costs

AWS released benchmark findings evaluating Apache Spark performance on Amazon EMR using the Amazon S3 Express One Zone storage class. Testing standard TPC-DS benchmarks across an 8-node AWS Graviton4 cluster running Amazon EMR 7.13, AWS demonstrated that S3 Express One Zone reduced total execution runtimes by 31% at the 3 TB scale and by 47% at the 10 TB scale compared to Amazon S3 Standard. Across 105 individual benchmark queries, 103 executed faster, driven by an average read request latency reduction from 121 ms down to 7 ms. As enterprise data estates expand into tens and hundreds of terabytes, query execution increasingly hits I/O bottlenecks rather than compute constraints. Data engineering teams frequently overprovision expensive compute clusters simply to wait on object storage round-trip latency. Achieving a 31% to 47% reduction in runtime directly shrinks the compute billing window for scheduled ETL jobs and ad-hoc analytics. Moreover, the benchmark recorded an overall cost reduction of 36% per run due to shorter active compute hours combined with lower request pricing for directory buckets, enabling significant operational efficiency gains for high-frequency Spark pipelines. Cloud object storage architecture has steadily shifted from passive data lakes toward high-throughput, low-latency execution layers designed for AI and big data analytics. The tension between the durability of distributed multi-AZ object stores and the raw input/output throughput required by modern compute engines has driven major cloud providers to introduce specialized high-speed tiers. S3 Express One Zone directory buckets bridge the gap between traditional S3 object storage and ephemeral block or local scratch storage, and these benchmark results validate how tight storage-compute co-locality addresses analytical throughput demands. For platform teams looking to adopt S3 Express One Zone for Apache Spark, the migration requires zero SQL or application codebase refactoring, but infrastructure architects must account for specific configuration rules. First, compute clusters must be explicitly co-located within the identical Availability Zone as the target directory bucket to avoid cross-AZ latency and data transfer surcharges. Second, engineers must explicitly set spark.sql.sources.fastS3PartitionDiscovery.enabled=false, as directory buckets do not support legacy S3 List API parameters utilized by Spark's default partition discovery. Finally, teams should evaluate their workload characteristics: while read-heavy and I/O-intensive jobs see massive performance and cost improvements, workloads that are primarily compute-bound or require multi-AZ redundancy should maintain their existing standard or lifecycle-managed topologies.