DynamoDB は BLOB を保存できますか？

条件付きで可能です。DynamoDB はバイナリラージオブジェクト（BLOB）を Binary (B) 属性に保存します。転送時は base64 エンコードされ、アイテム全体が 400 KB 未満に収まっている限り問題ありません。それより大きいもの — 動画、音声、高解像度画像 — については、AWS は BLOB を Amazon S3 に保存し、DynamoDB には参照とメタデータだけを持たせることを推奨しています。

BLOB を直接保存する

バイトを Binary 属性に入れます。アプリケーションはバイナリ値を送る前に base64 エンコードしますが、DynamoDB が 400 KB のアイテムサイズに数えるのは生のバイト長です。小さな BLOB（署名、コンパクトなペイロード）なら余裕で収まります。

実際に何バイト入るのか

400 KB はアイテムであって、BLOB ではありません。境界を二分探索すると、正確な上限が出ます。1 文字のパーティションキーと 1 つの Binary 属性しか持たないアイテムに入る BLOB は 409,594 バイト です。あと 1 バイトで書き込みは失敗します。

ValidationException: Item size has exceeded the maximum allowed size

現実的なメタデータ属性を 6 つ（コンテンツタイプ、寸法、アップロード者、タイムスタンプ）並べると 94 バイトかかり、上限は 409,500 に下がります。

base64 エンコードは転送上の詳細にすぎません。その 409,594 バイトの put はリクエストボディに 546,128 バイトの base64 を送りますが、DynamoDB はそれを受け付けます。したがって「base64 が予算の 3 分の 1 を食う」という広く繰り返されている話は間違いです。実際に代償を払うのはスループットです。フルサイズの BLOB は put 1 回あたり 400 書き込みユニット、強整合読み取り 1 回あたり 100 読み取りユニットで、小さなアイテムの 1 と 0.5 に対する数字です。

ラージオブジェクトのパターン

BLOB が 400 KB を超えるときは、こうします。

オブジェクトを Amazon S3 に保存する。
S3 のキーとメタデータ（名前、サイズ、所有者、タイムスタンプ）を DynamoDB に置く。

これは DynamoDB の高速なインデックス検索と、S3 の安価で上限のないオブジェクトストレージを組み合わせます。上限をわずかに超える程度のデータについては、AWS は大きな属性の圧縮（GZIP や LZO の出力を Binary 属性に格納）や、複数アイテムへの分割も提案しています。

圧縮が救うのはテキストであって、メディアではない

その圧縮のアドバイスが効くのは、たった 1 種類の BLOB に対してだけです。614,499 バイトの YAML ロックファイルに gzip -9 をかけると 164,302 バイトになり、73% の削減で「不可能」から「余裕」に変わります。同じコマンドを 794,311 バイトの PNG にかけると 785,175 バイトになり、削減はわずか 1.2% です。その形式がすでに自分自身を圧縮しているからです。つまり圧縮は、ログや JSON のペイロードやテキストには余地を買ってくれますが、上限に突き当たる通常の原因であるメディアファイルには何も買ってくれません。

注意点

DynamoDB と S3 の間にサービスをまたぐトランザクションはないので、部分的な失敗と孤立したオブジェクトは、アプリケーション自身が扱わなければなりません。

さらに詳しく

サイズはアイテムサイズ計算ツールで確認し、アイテムサイズの上限ガイドを読んでください。バイナリデータを閲覧するには DynoTable をダウンロードしてください。

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

2026-07-28 に @aws-sdk/client-dynamodb 3.1095.0 経由で DynamoDB Local 3.3.0 に対して測定しました。2 つのバイト上限はいずれも計算で導いたのではなく二分探索で見つけたもので、gzip の数値は説明した 2 つのファイルに gzip -9 を実行した結果です。AWS の実稼働エンジンは拒否の文言が異なる場合があります。