DynamoDB TTL

存留時間（TTL）讓 DynamoDB 在你存放於項目上的某個時間戳記過去後，自動刪除該項目。你指定一個持有 Unix 紀元到期時間的屬性，DynamoDB 就會在背景回收到期的項目 — 不需要回收工作，也沒有額外成本。

在稽核記錄的情境中，每位租戶都有一套保留政策：事件保留 90 天、或 1 年、或對合規要求高的租戶保留 7 年。TTL 就是你在不必執行自己的刪除清掃下，落實那套政策的方法。

DynamoDB TTL 是如何運作的？

DynamoDB TTL 會在你存放於指定屬性中的 Unix 紀元（秒）時間戳記過去後，自動刪除項目。你在表格上啟用 TTL 並指定到期屬性，DynamoDB 便會在背景回收到期項目 — 通常在 48 小時內完成，且不消耗寫入容量。已到期的項目在被實際刪除前仍可讀取。

• TTL 是一個持有 Unix 紀元（秒）時間戳記的屬性。 當那個時間過去，該項目就符合刪除資格。
• 刪除是背景且盡力而為的 — 通常在到期後的一兩天內，而非確切的那一秒。AWS 以 48 小時內為目標。
• TTL 刪除是免費的 — 它們不消耗寫入容量。
• 已到期但尚未刪除的項目仍會出現在讀取中，所以若你需要立刻隱藏它們，請對到期屬性進行 filter。

問題：自己讓舊資料到期所費不貲

沒有 TTL，要落實「丟掉超過 90 天的事件」就意味著執行你自己的回收程式：定時掃描（或查詢）尋找舊項目，並對每一個執行 DeleteItem。那次掃描耗用讀取容量、那些刪除耗用寫入容量，而排程、失敗與重試都歸你管。

對於一份高量的稽核記錄，那只是為了丟掉資料而持續、不斷增長的稅。TTL 把整件工作搬進 DynamoDB，而且免費。

TTL 如何運作

你在表格上啟用 TTL，並告訴它哪個屬性持有到期時間。根據 AWS 公告， 你「指定一個包含 Unix 紀元到期時間戳記的項目屬性，DynamoDB 就會在背景自動處理刪除 — 而不影響表格效能」。

有兩項性質對正確性很重要：

• 它是盡力而為，而非精確的。 DynamoDB 會掃描尋找到期的項目並在背景刪除它們；AWS 以到期後 48 小時內刪除為目標。一個項目在它的時間戳記時就符合資格，但可能稍微逗留。
• 到期的項目在被回收前仍可讀取。 一次 Query 可能回傳一個 TTL 已過但尚未被刪除的項目 — 所以若「到期＝立刻不可見」是一項硬性要求，就對到期屬性加上一個 FilterExpression。

而且 TTL 刪除不消耗寫入容量，這正是它嚴格上比自行執行的回收程式便宜的原因。

一個實作範例：依租戶的保留

每個稽核事件都攜帶一個 expiresAt 屬性，在事件被寫入時設定 — 以紀元秒表示的 現在 + 該租戶的保留視窗：

TTL 以 expiresAt 作為 TTL 屬性啟用。當 acme 的 90 天事件越過 1758873600 時，DynamoDB 大約在兩天內自行刪除它。合規租戶的事件攜帶一個遠在未來的 expiresAt，所以它們得以存活 — 同一張表格、同一套機制，每個項目卻有不同的保留。

寫入端只是在你建立事件時加上一個數字。你可以在 DynamoDB 表達式建構器 中組出 SET expiresAt = :ttl 子句，並驗證帶類型的 :ttl 值。

若要立刻把一個已到期但未回收的事件從讀取中隱藏，請對查詢的 FilterExpression 加上 expiresAt > :now — 不過要記得 filter 並不會降低讀取成本（Query 與 Scan 的比較）。

在 DynoTable 中實作

經典的 TTL 錯誤是一個錯誤的 expiresAt：以毫秒而非秒儲存、或存成 ISO 字串，導致該項目要嘛永不到期、要嘛立刻消失。唯一能抓到它的方法，是去看實際儲存的值與它的類型。

DynoTable 會以項目屬性的 DynamoDB 類型顯示每個屬性，所以你可以確認 expiresAt 是一個以紀元秒表示的 Number — 而非字串、也非毫秒 — 再以真實的保留信任 TTL。

陷阱與後續步驟

• 紀元秒，且為 Number。 這是最常見的 TTL 錯誤。一個毫秒值會把到期推到約 50,000 年後；一個 ISO 字串則會被完全忽略。請驗證類型與單位。
• 別仰賴刪除的時機。 到期與刪除之間可能經過最多約 48 小時。若「到期那一刻就消失」很重要，請在讀取時對該屬性進行 filter；別假設那一列已實體消失。
• TTL 刪除會出現在 Streams 中。 一次 TTL 刪除會發出一筆標記為系統產生的 stream 記錄 — 這是在到期事件消失前把它們封存到 S3 的標準掛鉤。請見 DynamoDB Streams。
• TTL 刪除仍會作用於 GSI。 移除一個項目也會把它從它曾所在的任何 secondary index 移除 — 這是預期中的清理，但若某個 index 驅動了某項計數，就值得知道。

TTL 廉價地處理了一個事件生命的終點。下一個問題是你一開始為這些寫入付了什麼 — 隨需與佈建容量。

下載 DynoTable 來檢視你項目的屬性類型，並在你開啟 TTL 之前確認你的 TTL 屬性是一個 Unix 紀元 Number。