I Benchmarked Amazon S3's New Checksum Algorithm on the Latest-Generation Intel/AMD/Graviton4 EC2 Instances

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

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

In this article, we examine how algorithm choice and instance type affect performance, using measured benchmarks on the latest-generation EC2 instances across three architectures (Intel Emerald Rapids / AMD EPYC / AWS Graviton4).

What Changed

Available in 37 Regions. The default remains CRC64NVME as before.

Algorithm Characteristics

Non-cryptographic hashes (fast, suited to integrity checks)

Cryptographic hashes (suited to security and compliance)

If the goal is detecting data corruption in transit, non-cryptographic hashes are sufficient. Protection against tampering with data on S3 is fundamentally ensured not by checksums but by IAM policies and S3 Object Lock.

Measured Benchmarks

Test Environment

We tested three instance types in the Tokyo Region (ap-northeast-1).

The test data (5GB) was placed on tmpfs (a RAM disk) to eliminate storage I/O as a bottleneck. Checksum computation speed was measured single-threaded on in-memory data using Python's xxhash (C extension) and hashlib, and S3 transfer speed was measured with aws s3 cp from AWS CLI 2.34.35. All figures are averages of three runs.

Checksum computation speed (5GB, single-threaded, average of 3 runs)

Variation across the three runs was extremely small (coefficient of variation under 1%), so the results are highly reproducible.

AMD was the fastest for every algorithm. With XXHash3 it reached 36.7 GB/s, 2.5 times Intel and 1.6 times Graviton4. The AVX-512 optimizations in the xxhash library are thought to be taking effect. Graviton4 also significantly outperformed Intel, with 23.4 GB/s for XXHash3 and 18.3 GB/s for XXHash64, showing that the ARM NEON optimizations are working effectively.

S3 transfer speed (5GB, tmpfs → S3, average of 3 runs)

This is the upload throughput of aws s3 cp. A 5GB file is processed internally as a multipart upload, with multiple parts transferred in parallel.

In checksum computation speed, there was up to a 47x difference between algorithms (XXHash3 vs MD5), but in S3 transfer speed all three environments fell within the 350–510 MB/s range, and the differences between algorithms shrank considerably.

Discussion

The impact of algorithm choice on S3 transfers is limited

With network bandwidth secured by 4xlarge instances and storage I/O eliminated by tmpfs, all three environments recorded throughput of around 400–500 MB/s regardless of algorithm. Even though checksum computation speed differs by tens of times, the effect on total S3 transfer throughput is small. This is because network I/O and SDK overhead dominate, and checksum computation is only a small part of the whole.

The differences among the three environments are small

In S3 transfer speed, there was no clear winner among the three architectures. However, differences were seen in run-to-run variation (standard deviation): c8i was the largest (average SD 79.5 MB/s) and c8a the smallest (average SD 41.4 MB/s).

In addition, when we ran the same tests beforehand on .large (2 vCPU) instances, c8i.large (1 physical core / SMT) showed a drop to 141 MB/s for some algorithms. c8a.large / c8g.large (2 physical cores) showed no such drop, and it was also resolved on c8i when changed to 4xlarge, so a ceiling on parallel processing due to a shortage of physical cores is thought to be one factor. On .large class instances, EBS throughput and network bandwidth constraints also overlap, so it cannot be attributed to a single cause, but in environments that make heavy use of multipart uploads, it is important to choose an instance size with ample physical cores.

Architecture differences are pronounced in checksum computation speed

On the other hand, in pure checksum computation speed, AMD (c8a) was overwhelmingly faster. It is expected to be effective for workloads with heavy checksum computation, and for multipart uploads in environments with ample network bandwidth (25 Gbps or more).

Guidelines for Choosing an Architecture

c8g is 15% cheaper than c8i and 26% cheaper than c8a. Given that there is no large difference in S3 transfer speed, c8g (Graviton4) is suitable if cost is the priority, and c8a (AMD) if performance is the priority.

Recommended Algorithms by Use Case

Notes

CLI / SDK versions

Using the new algorithms requires updating the CLI / SDK. We confirmed support 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

The existing algorithms (CRC32, CRC32C, SHA-1, SHA-256) have been supported for some time. CRC64NVME was added in early 2025, so it cannot be used with versions earlier than that.

MD5

It is supported at the S3 API level, but automatic computation via --checksum-algorithm MD5 in the SDK / CLI is not supported. You need to specify a precomputed value with the x-amz-checksum-md5 header. The MD5 of a multipart upload can be computed afterward with Compute checksum in S3 Batch Operations.

Directory buckets

Specifying a checksum algorithm is not supported for directory buckets (S3 Express One Zone).

Summary

With this announcement, S3's checksum algorithms have been expanded from the previous five to ten. The addition of the XXHash family makes integration with existing data pipelines easier, and the addition of SHA-512 and MD5 broadens the options for compliance and legacy compatibility.

For many workloads, simply using the default CRC64NVME provides sufficient speed and integrity. There is no need to deliberately change the algorithm.

On the other hand, this benchmark also confirmed that the combination of CPU architecture and algorithm produces clear differences in checksum computation speed. For workloads where integration with existing data pipelines or faster computation is desired, please try the newly added algorithms.