DynamoDB は TTL に対応していますか？

対応しています。DynamoDB は Time to Live (TTL) をサポートします。Unix エポック秒の有効期限タイムスタンプを保持する Number 属性を指定すると、DynamoDB が期限切れのアイテムをバックグラウンドで — 通常は期限から数日以内に — 追加コストなしに、書き込みキャパシティも消費せずに削除します。期限が切れたがまだ削除されていないアイテムは、消えるまで読み取りに現れることがあります。

有効にする方法

テーブルで TTL をオンにし、有効期限を保持する属性の名前を指定します。その属性は Number 型で、Unix エポックのタイムスタンプを秒で保持している必要があります（ミリ秒ではありません）。値が過去になったアイテムが削除の対象になります。

何を期待できるか

無料 — 自動削除は書き込みキャパシティユニットを消費しません。同じ後始末を自分でやると、アイテムあたり 1 書き込みユニットかかります。1 KB のアイテム 1,000 万件なら 1,000 万書き込みユニットで、us-east-1 のオンデマンドで 6.25 ドル、加えてそれらを見つけるための 100 GB のテーブルのフルスキャン 1 回につき約 1.64 ドルです。（例外が 1 つ: グローバルテーブルでは、他の各リージョンにレプリケートされた削除が、そのリージョンでレプリケート書き込みキャパシティを消費します。）
即時ではない — DynamoDB は通常、期限切れのアイテムを期限から数日以内に削除します。
まだ読める — 物理的に削除されるまで、期限切れのアイテムは読み取り、クエリ、スキャンに現れることがあります。正確さが重要ならフィルターで除外してください。

静かにまったく発火しなくなるパターン

DynamoDB は、TTL に指定した属性を検証しません。以下の 2 つの書き込みはどちらも、expiresAt で TTL を有効にしたテーブルに対して HTTP 200 を返しましたが、どちらのアイテムも決して期限切れになりません。

{"pk": {"S": "sess#1"}, "expiresAt": {"S": "1790812800"}}
{"pk": {"S": "sess#2"}, "expiresAt": {"N": "1790812800000"}}

1 つ目はタイムスタンプを String として保存しています。AWS は "items with a TTL attribute that is not a Number type are ignored by the TTL process" と明言していますが、書き込み時にも、有効化の時にも、その後にも、それを教えてくれるものはありません。

2 つ目こそ実際によく起きる方です。型は正しく、値が Date.now() から来ているからです。1790812800000 はミリ秒での 2026 年 10 月 1 日です。TTL が読む唯一の方法である秒として読むと、そのタイムスタンプは西暦 58718 年に着地します。そのアイテムは形式的に正しく、クエリでき、ストレージ料金がかかり、そして 5 万 6 千年後に期限切れになる予定です。

API はどちらの間違いも表面化させないので、チェックは書き込む前に行うしかありません。当サイトの TTL コンバーターが 1e12 を超える値をミリ秒として扱うのはこのためで、その値が解決される日付も表示します。

よくある用途

セッションレコード、検証トークン、自分で片付いてほしいキャッシュ結果 — これが古典的な TTL のユースケースです。削除に反応したいなら DynamoDB Streams と組み合わせましょう。

さらに詳しく

DynamoDB の TTLガイドと DynamoDB Streamsを読んでください。TTL 属性を確認・設定するには DynoTable をダウンロードしてください。

参考資料

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

上の 2 つの書き込みは、2026-07-28 に @aws-sdk/client-dynamodb 3.1095.0 経由で DynamoDB Local 3.3.0 に対して実行し、いずれも HTTP 200 で受理されました。後始末のコストは、同期済みの AWS 料金表の us-east-1 オンデマンド価格から算出しています。