「5TBの壁」との長い付き合い
Amazon S3を使っている方なら、「1オブジェクトあたり最大5TB」という制限を意識したことがあるかもしれません。
普通のWebアプリケーションなら、正直この制限に当たることはほぼありません。でも、AI/ML基盤を構築していたり、ゲノム解析や4K/8K映像アーカイブを扱っていたりすると、話が違ってきます。
5TBを超える単一ファイルは、これまで分割して保存→取り出し時に結合というワークフローが必要でした。これがアプリケーションの複雑性を増やし、特にバルク処理のパフォーマンスボトルネックになることもあったんですよね。僕がクライアント支援で関わったあるAI系スタートアップでも、学習データの管理でこの問題に直面して、結構な工数をかけて回避策を実装したことがあります。
re:Invent 2025で、ついにこの制限が10倍の50TBに拡張されました。同時に発表されたS3 Batch Operationsの10倍高速化と合わせて、何が変わるのかを見ていきましょう。
50TB時代の技術仕様を整理してみる
今回のアップデートで変わった点と変わらなかった点を整理してみます。最大オブジェクトサイズは5TBから50TBへ10倍に。マルチパートアップロードのパート数は最大10,000のまま変更なし。パートサイズは5GBから50GBへ拡張。そしてBatch Operationsの処理速度は10倍に高速化されています。
ポイントは、パート数は据え置きでパートサイズを10倍にしたという設計です。これにより、既存のマルチパートアップロードのコードロジックはほぼ変更なしで50TBに対応できます。後方互換性を維持しながら制限を緩和するという、AWSらしいアプローチだと思います。
AWS Common Runtime（CRT）との連携
大容量ファイルの高速転送には、AWS CRTベースのTransfer Managerの利用が推奨されています。CRTはC言語で書かれた高性能なAWS SDKランタイムで、マルチパートアップロードの並列処理を最適化し、ネットワーク障害時の自動リトライも備えています。AWS公式ブログによると、従来のJava SDK比でスループット最大6倍の実績があるとのこと。
Java SDK 2.x、Python boto3、.NET SDKなど主要SDKでCRT統合が進んでいるので、50TB時代の大容量転送ではCRTベースのTransfer Managerを使うのがベストプラクティスになりそうです。
S3 Batch Operations 10倍高速化の意味
S3 Batch Operationsは、数十億規模のオブジェクトに対してオブジェクトのコピー、タグの付け替え、ACLの設定、Lambda関数の呼び出し、S3 Object Lockの設定などを一括実行できる機能です。
re:Invent 2025で発表された10倍高速化により、特に恩恵が大きいと僕が考えているユースケースがいくつかあります。まずAI/MLのデータセット準備。数十TBの学習データをS3 Glacierから復元し、訓練用バケットにコピーするような処理が、従来の1/10の時間で終わる。次にコンプライアンス対応。保持期間ポリシーの一括適用が高速になることで、監査対応の負荷が軽減される。そしてストレージクラス最適化。大量オブジェクトのIntelligent-Tieringへの移行が現実的な時間で完了するようになる。
従来1日かかっていたジョブが2〜3時間で終わる計算になるわけで、これは結構なオペレーション効率化になりますよね。特にペタバイト規模のデータレイクを運用しているお客さんにとっては、インパクトが大きいと思います。
実務で気をつけるべき3つのポイント
実際に50TBオブジェクトを扱う際に、僕が気をつけてほしいと思っているポイントを3つお伝えします。
まずコストシミュレーションは必須です。50TBオブジェクトを扱うなら、ストレージコスト（標準クラスで約$1,150/月/50TB）、PUT/GETリクエストコスト（マルチパートだとパート数分のリクエスト課金）、データ転送コスト（リージョン外への転送は$0.09/GB〜）を事前に計算しておくべきです。うっかりすると「思ったよりコストがかかった」ということになりかねないので、必ず事前に試算しましょう。
次にチェックサムの有効化。大容量ファイルでは、データ整合性の担保が特に重要です。S3は追加のチェックサムオプション（SHA-256、CRC-64NVME）をサポートしています。50TB規模のファイルでは、アップロード時・ダウンロード時の両方でチェックサム検証を有効化することを強くおすすめします。途中でデータが壊れていたことに後から気づくと、やり直しのコストが半端ないですからね。
最後にマルチパート戦略の見直し。パートサイズが50GBまで拡張されたことで、パートサイズの選択肢が広がりました。従来はパート数上限（10,000）に近づくと強制的に大きなパートサイズにせざるを得ませんでしたが、今は余裕があります。一般的な指針としては、100GB〜1TBのファイルなら50MB〜100MB/パート、1TB〜10TBなら500MB〜1GB/パート、10TB超なら5GB〜10GB/パートでCRTベースのTransfer Manager推奨、という感じで考えています。
データレイクとしてのS3がさらに強固に
今回のアップデートは、「S3をAI/MLのデータレイク基盤として使う」流れを加速させると見ています。50TBオブジェクト対応により、大規模MLモデルのチェックポイント保存が単一オブジェクトで可能になる。Batch Operations 10倍高速化により、データパイプラインのスループットが向上する。そして既存のS3機能（バージョニング、ライフサイクル、Glacier統合）との組み合わせで、運用の一貫性も維持できる。
僕自身、クライアント企業のDX支援でデータ基盤設計に関わることが多いのですが、「どこにデータを集約するか」の答えとしてS3の存在感はますます大きくなっていると実感します。特に生成AI時代に入って、学習データや推論結果の管理ニーズが爆発的に増えている中で、今回のアップデートはタイムリーだと思います。
まとめ
S3の最大オブジェクトサイズが5TBから50TBに拡張され、マルチパートアップロードのパートサイズも5GBから50GBに拡大。S3 Batch Operationsも10倍高速化され、ペタバイト規模の運用がより現実的になりました。CRTベースのTransfer ManagerとチェックサムTは有効化がベストプラクティスです。
大規模データを扱う案件に携わっている方は、ぜひこの機会にS3周りのアーキテクチャを見直してみてください。特にAI/ML基盤やデータレイクを構築中のチームにとっては、設計の選択肢が広がる良いタイミングだと思います。
