DynamoDB 支援 TTL 嗎？

支援。DynamoDB 支援 Time to Live（TTL）。你指定一個以秒為單位、存放 Unix epoch 到期時間戳記的 Number 屬性；DynamoDB 之後就會在背景移除過期項目 — 通常在到期後幾天內 — 不額外收費，也不消耗寫入容量。已過期但尚未被刪除的項目，在被移除之前仍可能出現在讀取結果中。

如何啟用

替表格開啟 TTL，並指定存放到期時間的那個屬性。該屬性必須是 Number，存放以秒為單位的 Unix epoch 時間戳記（不是毫秒）。值落在過去的項目就會成為可刪除的對象。

該預期什麼

免費 — 自動刪除不消耗寫入容量單位。自己做同樣的清理，每個項目要花一個寫入單位：一千萬個過期的 1 KB 項目就是一千萬個寫入單位，在 us-east-1 隨需模式下是 6.25 美元，再加上每次掃過一張 100 GB 表格去找出它們的約 1.64 美元。（一個例外：在 global table 上，複寫到其他每個區域的那次刪除，會在該地消耗複寫寫入容量。）
不是即時的 — DynamoDB 通常在到期後幾天內移除過期項目。
仍然讀得到 — 在被實際刪除之前，過期項目可能出現在讀取、查詢與掃描結果中，所以若精確性要緊，請把它們過濾掉。

它悄悄從不觸發的那種方式

DynamoDB 不會驗證你把 TTL 指向的那個屬性。在一張已對 expiresAt 啟用 TTL 的表格上，以下兩次寫入都回傳 HTTP 200，而這兩個項目永遠不會過期：

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

第一個把時間戳記存成 String。AWS 明確表示 "items with a TTL attribute that is not a Number type are ignored by the TTL process"，而不論在寫入當下、啟用當下或事後，都沒有任何東西會告訴你。

第二個才是真正常常發生的那一種，因為型別是對的，而值是從 Date.now() 來的。1790812800000 是 2026 年 10 月 1 日的毫秒數。把它當成秒來讀 — 而那是 TTL 唯一的讀法 — 那個時間戳記會落在西元 58718 年。這個項目格式正確、查得到、要付儲存費，並且排定在五萬六千年後過期。

API 裡沒有任何東西會讓這兩種錯誤浮上檯面，所以檢查必須在你寫入之前發生。我們的 TTL 轉換器正是因此把任何大於 1e12 的值視為毫秒，並顯示那個值解析出來的日期。

常見用途

工作階段記錄、驗證 token，以及應該自己清乾淨的快取結果 — 都是經典的 TTL 使用情境。搭配 DynamoDB Streams 即可對刪除做出反應。

深入了解

閱讀 DynamoDB TTL 指南與 DynamoDB Streams。下載 DynoTable 即可檢視與設定 TTL 屬性。

參考資料

最後驗證於 2026-07-13，對照上方連結的官方 AWS 文件；TTL.html 已於 2026-07-28 重新查核。

上面那兩次寫入是於 2026-07-28 透過 @aws-sdk/client-dynamodb 3.1095.0 對照 DynamoDB Local 3.3.0 執行的，皆以 HTTP 200 被接受。清理成本是依我們同步下來的 AWS 定價表中 us-east-1 的隨需費率計算而得。