Performance Measurement of Amazon S3's New Checksum Algorithm on the Latest Generation of Intel/AMD/Graviton4 EC2

On April 23, 2026, Amazon S3 added support for 5 new checksum algorithms, bringing the total to 10.

https://aws.amazon.com/jp/about-aws/whats-new/2026/04/s3-five-additional-checksum-algorithms/

This article examines how algorithm selection and instance type affect performance through benchmarks on the latest generation of three EC2 architectures (Intel Emerald Rapids / AMD EPYC / AWS Graviton4).

What has changed

Available in 37 regions. The default remains CRC64NVME.

Algorithm Characteristics

Non-cryptographic Hashes (Fast, for integrity checks)

Cryptographic Hashes (For security and compliance)

Non-cryptographic hashes are sufficient for detecting data corruption during transfers. For protecting against data tampering on S3, IAM policies and S3 Object Lock are more appropriate than checksums.

Benchmarks

Test Environment

Testing was conducted on three instance types in the Tokyo region (ap-northeast-1).

Test data (5GB) was placed on tmpfs (RAM disk) to eliminate storage I/O bottlenecks. Checksum calculation speeds were measured using Python's xxhash (C extension) and hashlib on in-memory data with single-thread processing. S3 transfer speeds were measured using aws s3 cp with AWS CLI 2.34.35. All results are averages of three runs.

Checksum Calculation Speed (5GB, Single-thread, Average of 3 runs)

Variation between runs was extremely small (coefficient of variation under 1%), indicating highly reproducible results.

AMD was fastest across all algorithms. XXHash3 reached 36.7 GB/s, 2.5 times faster than Intel and 1.6 times faster than Graviton4. This is likely due to the AVX-512 optimizations in the xxhash library. Graviton4 also significantly outperformed Intel, achieving 23.4 GB/s with XXHash3 and 18.3 GB/s with XXHash64, demonstrating effective ARM NEON optimizations.

S3 Transfer Speed (5GB, tmpfs → S3, Average of 3 runs)

Upload throughput using aws s3 cp. The 5GB file is processed as a multipart upload with parts transferred in parallel.

While checksum calculation speeds showed up to a 47x difference between algorithms (XXHash3 vs MD5), S3 transfer speeds across all three environments fell within a much narrower range of 350-510 MB/s, significantly reducing the differences between algorithms.

Analysis

Algorithm choice has limited impact on S3 transfers

Using 4xlarge instances with sufficient network bandwidth and tmpfs to eliminate storage I/O bottlenecks, all three environments achieved throughputs around 400-500 MB/s regardless of algorithm. Even with tens of times difference in checksum calculation speed, the impact on overall S3 transfer throughput was minimal. This is because network I/O and SDK overhead dominate, with checksum calculation representing only a small portion of the overall process.

Small differences between the three environments

There was no clear advantage among the three architectures in S3 transfer speeds. However, there were differences in run-to-run variation (standard deviation), with c8i showing the largest (average SD 79.5 MB/s) and c8a showing the smallest (average SD 41.4 MB/s).

In preliminary tests using .large (2 vCPU) instances, c8i.large (1 physical core with SMT) showed throughput drops to as low as 141 MB/s with some algorithms. This was not observed with c8a.large/c8g.large (2 physical cores) and was resolved when switching to 4xlarge for c8i, suggesting that limited physical cores can bottleneck parallel processing. For .large class instances, EBS throughput and network bandwidth constraints also contribute, making it difficult to identify a single cause. For environments heavily using multipart uploads, choosing instance sizes with sufficient physical cores is important.

Architecture differences are pronounced in checksum calculation speed

For pure checksum calculation speed, AMD (c8a) was significantly faster. This would be beneficial for workloads with high checksum calculation requirements or environments with very high network bandwidth (25 Gbps or higher) for multipart uploads.

Architecture Selection Guidelines

c8g is 15% cheaper than c8i and 26% cheaper than c8a. Given the minimal differences in S3 transfer speeds, c8g (Graviton4) is suitable for cost-conscious workloads, while c8a (AMD) is better for performance-focused needs.

Recommended Algorithms by Use Case

Important Notes

CLI / SDK Versions

Using the new algorithms requires updated CLI/SDK. Support confirmed with CLI 2.34.35.

aws --version
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install --update

Existing algorithms (CRC32, CRC32C, SHA-1, SHA-256) have been supported previously. CRC64NVME was added in early 2025, so earlier versions cannot use it.

MD5

While supported at the S3 API level, automatic calculation using SDK/CLI's --checksum-algorithm MD5 is not supported. Pre-calculated values must be specified using the x-amz-checksum-md5 header. MD5 for multipart uploads can be calculated afterward using S3 Batch Operations' Compute checksum.

Directory Buckets

Directory buckets (S3 Express One Zone) do not support specifying checksum algorithms.

Conclusion

With this announcement, S3's checksum algorithm options have expanded from 5 to 10. The addition of XXHash algorithms simplifies integration with existing data pipelines, while SHA-512 and MD5 provide more options for compliance and legacy compatibility.

For most workloads, the default CRC64NVME provides sufficient speed and integrity. There's no need to deliberately change algorithms.

However, our benchmarks confirmed clear differences in checksum calculation speeds depending on CPU architecture and algorithm combinations. The newly added algorithms are worth trying for workloads that require integration with existing data pipelines or faster computation processing.