Amazon S3 の新チェックサムアルゴリズムを Intel/AMD/Graviton4 最新世代EC2で性能計測してみた
2026年4月23日、Amazon S3 が新たに5つのチェックサムアルゴリズムをサポートし、合計10種類になりました。
本記事では EC2 の最新世代3アーキテクチャ（Intel Emerald Rapids / AMD EPYC / AWS Graviton4）での実測ベンチマークを通じて、アルゴリズム選択とインスタンスタイプがパフォーマンスに与える影響を検証します。
何が変わったのか
| 分類 | 従来 | 今回追加 |
|---|---|---|
| CRC 系 | CRC32, CRC32C, CRC64NVME | ― |
| XXHash 系 | ― | XXHash3, XXHash64, XXHash128 |
| SHA 系 | SHA-1, SHA-256 | SHA-512 |
| その他 | ― | MD5 |
37リージョンで利用可能。デフォルトは従来通り CRC64NVME です。
アルゴリズムの特性
非暗号学的ハッシュ（高速・整合性チェック向け）
| アルゴリズム | ビット長 | 特徴 |
|---|---|---|
| CRC32 / CRC32C | 32bit | 軽量。ハードウェアアクセラレーション対応 |
| CRC64NVME | 64bit | S3 デフォルト。AWS CRT で高度に最適化 |
| XXHash64 | 64bit | 高速な汎用ハッシュ。データパイプラインで広く利用 |
| XXHash3 | 64bit | XXHash の最新版。SIMD 最適化 |
| XXHash128 | 128bit | XXHash3 の 128bit 版。衝突確率がさらに低い |
暗号学的ハッシュ（セキュリティ・コンプライアンス向け）
| アルゴリズム | ビット長 | 特徴 |
|---|---|---|
| MD5 | 128bit | 衝突攻撃が実証済み。レガシー互換用途 |
| SHA-1 | 160bit | 衝突が実証済み。非推奨 |
| SHA-256 | 256bit | 現時点で安全。広く利用 |
| SHA-512 | 512bit | SHA-256 より長いハッシュ値。64bit CPU で効率的な場合がある |
転送時のデータ破損検出が目的であれば非暗号学的ハッシュで十分です。S3 上のデータ改ざん対策はチェックサムではなく、IAM ポリシーや S3 Object Lock で担保するのが基本です。
実測ベンチマーク
検証環境
東京リージョン（ap-northeast-1）のインスタンス3種で検証しました。
| 項目 | c8i.4xlarge | c8a.4xlarge | c8g.4xlarge |
|---|---|---|---|
| CPU | Intel Xeon 6975P-C (Emerald Rapids) | AMD EPYC 9R45 | AWS Graviton4 |
| アーキテクチャ | x86_64 | x86_64 | aarch64 |
| vCPU / 物理コア | 16 / 8（SMT あり） | 16 / 16（SMT なし） | 16 / 16（SMT なし） |
| メモリ | 32GB DDR5 | 32GB DDR5 | 32GB DDR5 |
| ネットワーク帯域 | 最大 12.5 Gbps | 最大 15 Gbps | 最大 12.5 Gbps |
| オンデマンド価格 | $0.4718/h | $0.5426/h | $0.4003/h |
テストデータ（5GB）は tmpfs（RAMディスク）に配置し、ストレージ I/O のボトルネックを排除しています。チェックサム計算速度は Python の xxhash（C 拡張）および hashlib でメモリ上のデータに対してシングルスレッド測定、S3 転送速度は AWS CLI 2.34.35 の aws s3 cp で測定しています。いずれも3回実行の平均値です。
チェックサム計算速度（5GB、シングルスレッド、3回平均）
| アルゴリズム | c8i (Intel) | c8a (AMD) | c8g (Graviton4) |
|---|---|---|---|
| XXHash3_64 | 14.8 GB/s | 36.7 GB/s | 23.4 GB/s |
| XXHash3_128 | 14.8 GB/s | 36.8 GB/s | 23.3 GB/s |
| XXHash64 | 7.0 GB/s | 22.0 GB/s | 18.3 GB/s |
| SHA-256 | 1.7 GB/s | 2.1 GB/s | 1.7 GB/s |
| CRC32 | 1.3 GB/s | 1.7 GB/s | 1.0 GB/s |
| SHA-512 | 0.8 GB/s | 1.2 GB/s | 1.0 GB/s |
| MD5 | 0.8 GB/s | 0.9 GB/s | 0.6 GB/s |
3回の実行間のばらつきは極めて小さく（変動係数 1% 未満）、再現性の高い結果です。
AMD が全アルゴリズムで最速。XXHash3 では 36.7 GB/s に達し、Intel の 2.5 倍、Graviton4 の 1.6 倍です。xxhash ライブラリの AVX-512 最適化が効いていると考えられます。Graviton4 も XXHash3 で 23.4 GB/s、XXHash64 で 18.3 GB/s と Intel を大きく上回り、ARM NEON 最適化が有効に機能しています。
S3 転送速度（5GB、tmpfs → S3、3回平均）
aws s3 cp によるアップロードのスループットです。5GB のファイルは内部でマルチパートアップロードとして処理され、複数パートが並列転送されます。
| アルゴリズム | c8i (Intel) | c8a (AMD) | c8g (Graviton4) |
|---|---|---|---|
| CRC32C | 507 MB/s | 494 MB/s | 425 MB/s |
| CRC32 | 470 MB/s | 405 MB/s | 413 MB/s |
| XXHASH3 | 461 MB/s | 411 MB/s | 428 MB/s |
| SHA-256 | 458 MB/s | 382 MB/s | 450 MB/s |
| CRC64NVME | 455 MB/s | 421 MB/s | 421 MB/s |
| XXHASH128 | 432 MB/s | 480 MB/s | 443 MB/s |
| XXHASH64 | 423 MB/s | 434 MB/s | 480 MB/s |
| SHA-1 | 403 MB/s | 469 MB/s | 491 MB/s |
| SHA-512 | 373 MB/s | 355 MB/s | 395 MB/s |
チェックサム計算速度ではアルゴリズム間に最大 47 倍の差（XXHash3 vs MD5）がありましたが、S3 転送速度では3環境とも 350〜510 MB/s の範囲に収まり、アルゴリズム間の差は大幅に縮小しています。
考察
S3 転送ではアルゴリズム選択の影響は限定的
4xlarge インスタンスでネットワーク帯域を確保し、tmpfs でストレージ I/O を排除した結果、3環境ともアルゴリズムによらず 400〜500 MB/s 前後のスループットを記録しました。チェックサム計算速度に数十倍の差があっても、S3 転送のトータルスループットへの影響は小さいことがわかります。ネットワーク I/O と SDK のオーバーヘッドが支配的であり、チェックサム計算は全体のごく一部にすぎないためです。
3環境の差は小さい
S3 転送速度では3アーキテクチャ間に明確な優劣はありませんでした。ただし、実行間のばらつき（標準偏差）には差が見られ、c8i が最も大きく（平均 SD 79.5 MB/s）、c8a が最も小さい（平均 SD 41.4 MB/s）結果となりました。
なお、事前に .large（2 vCPU）インスタンスで同様のテストを実施した際、c8i.large（物理 1 コア / SMT）では一部アルゴリズムで 141 MB/s まで落ち込む現象が見られました。c8a.large / c8g.large（物理 2 コア）ではここまでの落ち込みはなく、4xlarge に変更した c8i でも解消されたことから、物理コア不足による並列処理の頭打ちが一因と考えられます。.large クラスでは EBS スループットやネットワーク帯域の制約も重なるため単一の原因には帰結できませんが、マルチパートアップロードを多用する環境では物理コア数に余裕のあるインスタンスサイズを選ぶことが重要です。
チェックサム計算速度ではアーキテクチャの差が顕著
一方、純粋なチェックサム計算速度では AMD（c8a）が圧倒的に高速でした。チェックサム計算量が多いワークロードや、ネットワーク帯域が十分に広い環境（25 Gbps 以上）でのマルチパートアップロードで効果を発揮すると考えられます。
アーキテクチャ選択の指針
| 重視するポイント | おすすめ |
|---|---|
| チェックサム計算速度 | c8a（AMD）が最速 |
| S3 転送速度 | 3環境とも同等（差は小さい） |
| コストパフォーマンス | c8g（Graviton4）が最安 |
c8g は c8i より 15%、c8a より 26% 安価です。S3 転送速度に大きな差がないことを踏まえると、コスト重視なら c8g（Graviton4）、パフォーマンスを重視するなら c8a（AMD）が適しています。
ユースケース別おすすめアルゴリズム
| ユースケース | おすすめ | 理由 |
|---|---|---|
| 一般的な用途 | CRC64NVME（デフォルト） | 変更不要。十分な速度と精度 |
| 既存パイプラインとの統合 | XXHash64 / XXHash3 | Spark、ClickHouse 等との互換性 |
| 大規模データレイク | XXHash128 | 128bit で衝突リスクが極めて低い |
| コンプライアンス要件 | SHA-256 / SHA-512 | FIPS 準拠、金融・医療・政府系 |
| レガシーシステム互換 | MD5 | ヘッダーでの事前計算値指定のみ |
注意点
CLI / SDK のバージョン
新アルゴリズムの利用には CLI / SDK の更新が必要です。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
既存アルゴリズム（CRC32, CRC32C, SHA-1, SHA-256）は以前から対応しています。CRC64NVME は 2025年初頭に追加されたため、それ以前のバージョンでは利用できません。
MD5
S3 API レベルではサポートされていますが、SDK / CLI の --checksum-algorithm MD5 による自動計算には対応していません。事前計算した値を x-amz-checksum-md5 ヘッダーで指定する必要があります。マルチパートアップロードの MD5 は S3 Batch Operations の Compute checksum で後から計算可能です。
ディレクトリバケット
ディレクトリバケット（S3 Express One Zone）ではチェックサムアルゴリズムの指定は非対応です。
まとめ
今回の発表により、S3 のチェックサムアルゴリズムは従来の5種類から10種類に拡充されました。XXHash 系の追加により既存のデータパイプラインとの統合が容易になり、SHA-512 や MD5 の追加によりコンプライアンスやレガシー互換の選択肢も広がっています。
多くのワークロードでは、デフォルトの CRC64NVME をそのまま使えば十分な速度と整合性が得られます。アルゴリズムを意識的に変更する必要はありません。
一方、今回のベンチマークでは CPU アーキテクチャとアルゴリズムの組み合わせによってチェックサム計算速度に明確な差が生じることも確認できました。既存データパイプラインとの統合や計算処理の高速化が望まれるワークロードでは、今回追加されたアルゴリズムをお試しください。
