本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

quarterly review 看 DynamoDB bill 突然漲 80%、追查發現是 dev team 把所有 table 切 on-demand「省 capacity 管理」。finance 反問「於是省了多少 SRE 工時、又多花多少 cost」、team 答不出來。反向情境：Black Friday 前一週 provisioned table auto-scaling 上限是日常 5 倍、但開賣瞬間流量是 50 倍、auto-scaling 反應週期 5 分鐘、前 10 分鐘大量 throttle。兩個 production 痛點指向同一件事 — capacity mode 選擇不能只看「peak/avg ratio > 5x」單軸閾值。

本文展開 6 軸決策（peak/avg / 讀寫比 trend / surge 性質 / 事件分級 / DBA 工時釋放 / vendor crossover），把單軸決策樹擴成完整判讀框架。

DynamoDB 適用度前置判讀：本篇假設 workload 已通過 DynamoDB 適用度 4 軸（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）— 詳見 single-table-design-pattern 開頭 4 軸前置判讀、本篇不重複展開。Capacity mode 選擇是 已選 DynamoDB 後 的成本決策；若 workload 不適用 DynamoDB、mode 選擇無法救回 vendor 選錯的成本。

核心機制：兩種 mode 的工程差異

Auto-scaling 內部機制：

• CloudWatch alarm 觸發 → scaling activity → 1-5 分鐘調整 capacity
• target utilization 70%（建議值、留 buffer 給 scale latency）
• 連續 spike 仍可能 throttle（auto-scaling 反應週期 > spike 速度）

對應 knowledge card：peak forecast、cost per request、scheduled scaling。

6 軸決策框架

mode 選擇不是單軸 peak/avg ratio。下面 6 軸是 9 個 production case（Zomato / Zoom / Amazon Ads / Disney+ / Tixcraft / Capcom / Lemino / Genesys / PayPay）跨 case 揭露的真實決策維度。

軸 1：peak / average 流量 ratio

最直覺的軸、但是單軸誤判的根源。基本判讀：

• 高 ratio（spiky / flash-sale）傾向 on-demand
• 穩定 ratio（sustained / 平緩）傾向 provisioned + auto-scaling

Scope warning：「peak/avg > 5x → on-demand」、「provisioned base rate × 6-7 = on-demand rate」這些具體閾值是經驗值 / 通用工程估算、9.C5 / 9.C20 case 都沒給具體 ratio 數字。實際 crossover 點隨 region pricing + workload shape 變動、不要照搬本文數字。

軸 1 單獨不夠用、要跟軸 2-6 合成判讀。

軸 2：讀寫比 trend 變化

9.C5 Amazon Ads 揭露的觀測軸：「讀寫比 變化 比讀寫比本身更重要」。

• 絕對讀寫比對容量規劃不是最重要（C5 是 18:1、C27 推估 5:1、絕對值各家不同）
• 業務邏輯改變（新增即時報表 / 新增推播 / 新增分析 query）會讓讀寫比跳一個量級
• 觀測上加 metric：read / write ratio 7-day rolling average、超過 ±30% 偏移觸發 review

把 trend 變化當 capacity mode 重新評估的訊號 — 不是固定週期 review、是 trend 偏移 觸發 review。

軸 3：surge 是 暫時 還是 永久 baseline 上移

9.C18 Zoom COVID 30x DAU surge 揭露的軸：surge 後 baseline 永久上移、不會回去。

• 暫時 surge（單日活動 / 季節高峰）：on-demand 划算、活動結束 mode 不用調
• 永久上移後（Zoom COVID、社會行為改變）：原 on-demand 設計會持續燒錢、要重新算 crossover、考慮切回 provisioned

Tripwire：surge 結束後 4-8 週仍維持 surge 期間 baseline 的 70%+、判定為「永久 baseline 上移」、重評 mode。

Scope warning：「4-8 週 / 70% 閾值」屬通用工程估算、9.C18 Zoom case 揭露「surge 後 baseline 不會回去」概念、未揭露具體閾值。

軸 4：predictable-peak vs flash-sale

9.C27 Disney+ 跟 9.C15 Tixcraft 對比揭露的軸：兩種 event-driven peak 不是同一類。

9.C27 Disney+（Marvel / Star Wars 首日 metadata 流量 3-5 倍、持續時段較長）可以提前 1-2 天 pre-scale、scheduled scaling 合適。9.C15 Tixcraft 6750x in seconds，scheduled scaling 太慢、必須事前 pre-provision baseline 拉到極高、或用 on-demand + composite partition key 雙保險。

兩者都不是「peak/avg > 5x → on-demand」單軸決策能解。

Scope warning：「scheduled scaling 30-60 分鐘前升 capacity」這個具體 lead time 是經驗值、case 未揭露具體時間。pre-scale 的 lead time 依事件性質決定、不是固定 30-60 分鐘。

軸 5：DBA / SRE 工時釋放

9.C19 Capcom 跟 9.C29 Lemino 揭露的成本軸：DynamoDB 真實成本不只看 monthly bill。

• 9.C19 Capcom：30% 成本下降的本質是「工程資源從 DB 運維轉到遊戲品質」、Capcom 是遊戲公司不是 IT 公司、把 DBA 時間從 Postgres patching / replication 設定 / backup 排程釋放到遊戲機制設計
• 9.C29 Lemino：90% 工程工時下降（DBA + connection management + capacity planning 統包）

評估公式：

1總成本 = direct cost (monthly bill)
2       + 工程工時機會成本 (DBA 從 patch/replication/backup 釋放出來做的事)

on-demand 的 6-7x base rate 在 DBA 工時釋放下、實質 ROI 可能仍正向（特別在小團隊 / 非 IT 主業公司）。但要算總成本、不是只看 bill。

軸 6：DynamoDB vs 自管 cluster cost crossover

9.C20 Zomato 警惕段揭露的最上層決策軸：mode 選擇之上還有 vendor 選擇。

• 9.C20 Zomato：「成本降 50% 是 當下流量 的對照」、未來流量繼續成長、DynamoDB cost-per-request 成長率比 TiDB 自管 cluster 高、某流量規模後 crossover、自管 cluster 反而便宜
• 不是只在 on-demand vs provisioned 之間挑、是要算「未來 12-24 個月在預期流量下、DynamoDB（不論 mode）vs 自管 cluster 的成本曲線」

判讀分層：

• 小 / 中流量 startup：DynamoDB on-demand 簡單划算、不用糾結
• 大流量 + 流量可預測 + DBA 團隊已存在：自管 cluster crossover 點可能成立、值得算
• 大流量 + 流量不可預測 + 小團隊：DynamoDB managed 仍划算（軸 5 加成）

本軸是 mode 選擇之上的更上層決策、不是每次都展開、但寫進邊界判讀條件。

操作流程

從 workload profiling 到 mode 切換的 8 步流程。

Step 1：workload profiling

用 CloudWatch 過去 30 天 RCU/WCU、算 p50 / p95 / p99 peak、求 peak/avg ratio（軸 1 輸入）+ read/write ratio rolling avg（軸 2 輸入）。

Step 2：surge 性質判讀

• 是暫時 surge 還是永久 baseline 上移（軸 3）— 看 surge 結束後 4-8 週的 baseline trend
• 是 predictable-peak 還是 flash-sale（軸 4）— 看事件時間跟 auto-scaling 反應週期的比例

Step 3：6 軸合成決策

1軸 1（peak/avg）+ 軸 2（讀寫比 trend）+ 軸 3（surge 性質）
2+ 軸 4（事件分級）+ 軸 5（工時機會成本）+ 軸 6（vendor crossover）
3→ provisioned + auto-scaling / on-demand / scheduled scaling 三選一

不是任一軸獨自決定、是 6 軸合成；軸間衝突時優先序：軸 6（vendor）> 軸 5（工時）> 軸 3（surge 永久 vs 暫時）> 軸 4（事件分級）> 軸 1（peak/avg）> 軸 2（讀寫比 trend）。

Step 4：provisioned 配 auto-scaling

 1BillingMode: PROVISIONED
 2ProvisionedThroughput:
 3  ReadCapacityUnits: 100
 4  WriteCapacityUnits: 50
 5
 6AutoScalingSettings:
 7  TargetTrackingScalingPolicy:
 8    TargetValue: 70.0  # target utilization
 9    ScaleOutCooldown: 60
10    ScaleInCooldown: 60
11  MinCapacity: 50      # baseline
12  MaxCapacity: 1000    # baseline × 預期 surge multiplier

target utilization 70% 留 buffer 給 scale latency；alarm 設 5 分鐘觀察窗。

Step 5：scheduled scaling

已知大事件（黑五、開票、新片發布）前預先提升 min capacity、事件後回原值：

1# 黑五前 24 小時把 min capacity 拉到日常 10 倍
2client.put_scheduled_action(
3    ResourceId="table/orders",
4    ScheduledActionName="black-friday-pre-scale",
5    Schedule="cron(0 0 * * ? *)",  # 時間 lead 依事件性質決定、非固定 30-60 分鐘
6    ScalableTargetAction={"MinCapacity": 5000, "MaxCapacity": 50000}
7)

Step 6：mode switch

1aws dynamodb update-table \
2  --table-name orders \
3  --billing-mode-summary BillingMode=PAY_PER_REQUEST

每張 table 24 小時內只能切一次、要計畫 maintenance window。

Step 7：驗證點

切換後第一週對比 cost + throttle metric、確認方向正確：

• cost 變化方向跟預期一致（on-demand 應該變貴 / provisioned 應該變便宜）
• throttle rate 沒上升
• latency p99 沒退化

Step 8：總成本評估（軸 5 + 軸 6）

直接 cost + 工時機會成本 + 對照自管 cluster 的 cost crossover 曲線。Quarterly review 用這個公式、不是只看 monthly bill。

Rollback boundary：on-demand → provisioned 隨時可切、但 baseline 要先 sized 好；切錯方向第一個月可逆、長期累積 cost 不可逆。

失敗模式

production 觀察到的 6 個典型 anti-pattern：

Case 1：on-demand 後 cost 翻 3 倍

dev team 切 on-demand「不用管 capacity」、但 workload 是 sustained constant、on-demand 6-7x base rate 全付出來。9.C5 Amazon Ads 明示「sustained workload 用 provisioned + auto-scaling」。修法：穩定 workload 用 provisioned + auto-scaling（軸 1 + 軸 2）。

Case 2：auto-scaling 跟不上 spike

流量 1 分鐘內 10x、auto-scaling alarm 5 分鐘才觸發、前 4 分鐘全 throttle。修法：peak/avg 高且 spike 突然 → on-demand、或 scheduled scaling 預先升配（軸 1 + 軸 4）；flash-sale 場景 auto-scaling 不夠快、必須 pre-provision。

Case 3：on-demand hot partition 隱藏

on-demand 不顯示 throttle、latency 從 5ms 變 50ms、application timeout retry 加劇問題。修法：on-demand 仍要看 partition-level metric（Contributor Insights）、不能假設 mode 解決設計問題（跟 partition-key-antipatterns cross-link）；mode × partition 交叉判讀。

Case 4：provisioned target utilization 設太高

target = 90% 看似省、實際每次 spike 都先 throttle 再 scale。修法：70% buffer 給 scale latency、不要為了省 cost 把 utilization 推到極限。

Case 5：頻繁切 mode 撞 24h 限制

team 想「白天 provisioned 晚上 on-demand」省 cost、但 mode 切換 24h 一次、計畫破產。修法：白天 provisioned + 晚上把 capacity 設低、不切 mode；用 scheduled scaling 處理日週期、不用 mode switch。

Case 6：surge 後沒重評 mode、長期燒錢（軸 3 對應）

Zoom 式 30x permanent baseline 上移後、原 on-demand 設計成本爆炸。修法：surge 結束 4-8 週後重評、若 baseline 維持 70%+ 改 provisioned；把「surge 後 mode review」寫進 runbook、不是 ad-hoc 才想到。

Anti-recommendation：流量 < 100 RPS、cost < $50/月的小 table 不用糾結 mode、on-demand 簡單；workload 穩定且 cost 高才值得做 provisioned + auto-scaling 的工程投入。

容量與觀測

CloudWatch metric：

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits：基本用量
• ProvisionedReadCapacityUnits / ProvisionedWriteCapacityUnits：provisioned 預設值
• ThrottledRequests：provisioned mode 直接訊號、on-demand 為零不代表沒問題
• SuccessfulRequestLatency p99：on-demand mode 下 hot partition 訊號

新增的觀測軸（軸 2 / 軸 3 對應）：

• read/write ratio 7-day rolling avg、超過 ±30% 偏移觸發 review
• surge baseline 4-week rolling avg、判斷 surge 是暫時還是永久
• AWS Cost Explorer 按 table + mode 切 cost trend、月對比

Auto-scaling activity log：CloudWatch alarm history + scaling activity，觀察 scaling 是否頻繁但 utilization 仍低（表示 alarm 設太敏感）。

指標口徑紀律：引用 case 數字時明示口徑 — 9.C5 90M reads/sec 是「年度峰值最高一秒、非平均」、9.C20 90% latency 降可能只 p50 不是 p99/p999、9.C18 30x DAU 是「permanent baseline 上移」非單日 peak。讀 vendor case 數字要分「最大瞬時 / 99 百分位 / 常態 / 滾動」四個口徑、不是混用。

Cost gate：每月 finance review 把 DynamoDB cost 對齊 access pattern volume、不只看絕對數字；軸 5 工時釋放跟軸 6 vendor crossover 也納入。

接回 9.6 容量規劃模型、1.10 KV / Document DB 容量規劃。

邊界與整合

Frame 8 event-driven scaling 5 種模式

9.C5 / 9.C15 / 9.C18 / 9.C24 / 9.C27 跨 case 揭露 event-driven scaling 至少 5 種形狀：

• flash-sale spike：拓元 6750x in seconds（軸 4 走 pre-provision + composite PK）
• predictable peak：Disney+ 新片首發（軸 4 走 scheduled scaling）
• sustained growth：Amazon Ads / Capcom（軸 1 + 軸 5 → provisioned + auto-scaling）
• surge baseline permanent shift：Zoom 30x DAU 不會回去（軸 3 → 重評 mode）
• B2B sustained + 高可用：Genesys 99.999%（軸 5 + 軸 6 → managed 工時釋放比 cost 重要）

不是用「peak/avg > 5x」單一閾值決策、是事件型分類 × 軸合成。

Sibling 與 cross-link

• partition-key-antipatterns — capacity mode 不解 hot partition、mode × partition 交叉判讀
• single-table-design-pattern — access pattern 影響 peak/avg ratio 跟 read/write ratio
• gsi-lsi-design — GSI 多時 cost 跟 mode 互動
• global-tables-conflict — 多 region capacity 規劃放大、軸 5 工時釋放在 multi-region 更顯著
• Migration playbook：跨 vendor cost optimization（如 Zomato TiDB → DynamoDB）對應 type C operational hybrid
• 替代路由：cost 極度敏感 + 流量穩定 + DBA 團隊已存在 → 自管 PostgreSQL / MySQL 可能更便宜（軸 6 crossover）、回 PostgreSQL vendor
• 跟 Zoom 9.C18 互引：30x permanent surge 後的 mode 重評（軸 3 主案例）
• 跟 Capcom 9.C19 + Lemino 9.C29 互引：DBA 工時釋放（軸 5 主案例）
• 跟 Aurora read-replica-scaling 共軸 cross-link：本篇從 KV 層 mode 選擇切入、5 模式分類在本篇主寫；Aurora 從 SQL 讀副本視角切入、事件分級表（FanDuel 平日 / playoff / championship / Super Bowl）跟雙 SLO 並行（DraftKings 讀寫雙峰錯位）+ fleet 治理在 Aurora 端主寫、本篇不重複展開

本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

訊息系統的 storage bill 每月穩定上漲、查 table 發現裡面堆了三年份的過期通知、沒人清。team 設了 TTL「自動清理」、結果兩個新問題冒出來：第一、設了 TTL 之後 storage 還是沒馬上降、過了好幾小時才開始掉；第二、有個報表 query 把「已過期但還沒被刪」的 item 也撈進來、算錯數字。兩個痛點揭露 DynamoDB TTL 的真實語意 — 它是 最終會刪除 的背景機制、不是即時刪除、也不是查詢層的過濾器。本文展開 TTL 的 epoch 語意、刪除延遲特性、過期可讀陷阱與 storage 成本判讀。

生命週期前提：先確認 workload 適配 DynamoDB：資料生命週期管理是 已選 DynamoDB 之後才浮現的議題 — TTL 解的是「資料存進來之後怎麼自動退場」、而非「資料該不該存進 DynamoDB」。後者由 4 軸前置判讀決定：PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定、判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。本文承接該前提、聚焦用 TTL 管理資料生命週期與 storage 成本。

核心機制：TTL attribute 與背景刪除

DynamoDB TTL 讓 item 在指定時間後自動被刪除、不消耗寫容量。機制很簡單但語意有三個容易踩的邊界。

設定方式：在 item 上放一個數值 attribute、值是 Unix epoch 秒數（不是毫秒、不是 ISO 字串）、並在 table 啟用 TTL 指向該 attribute：

1import time
2table.put_item(Item={
3    "PK": f"MSG#{msg_id}",
4    "SK": "META",
5    "body": "...",
6    "expireAt": int(time.time()) + 30 * 86400,  # 30 天後過期、epoch 秒
7})

三個關鍵語意：

第二列是報表算錯的根因：TTL 不是查詢過濾器。過期到實際刪除之間有一段窗口、這期間 item 還在、還會被讀到。需要「過期立刻不可見」的、application 必須在讀取後自己比對 expireAt 過濾。

Scope warning：「TTL 通常 48 小時內刪除」屬 AWS vendor 規格描述、AWS 不保證準時、實際延遲視 table 大小與背景負載而定、實作時 cross-verify 官方 doc。9.C26 PayPay case 揭露「TTL 機制可自動清理過期訊息」的 用途、未揭露刪除延遲的具體數字。

對應 knowledge card：ttl、soft-ttl。

刪除延遲與過期可讀：兩個必須處理的窗口

TTL 的「最終刪除」特性製造兩個 application 必須意識的窗口。

窗口一：過期 → 實際刪除（可讀窗口）：

item 的 expireAt 已過、但背景程序還沒刪。這段時間 item：

• 仍會被 Query / Scan / GetItem 撈到
• 仍佔 storage、仍計 storage 費
• 仍會被 secondary index 索引到

application 若依賴「過期就消失」、會在這個窗口讀到 stale 資料。正確做法是 read 後 filter：

1import time
2now = int(time.time())
3items = [it for it in response["Items"] if it.get("expireAt", 1 << 62) > now]

或在 query 加 FilterExpression 排除過期 item（注意 filter 在讀取後套用、仍消耗讀容量）。

窗口二：TTL 刪除 → stream record：

TTL 刪除會在 stream 產生一筆 REMOVE record、且 userIdentity 標記為 DynamoDB 服務本身（principal dynamodb.amazonaws.com）。這讓「過期歸檔」成為可能 — 下游 Lambda 收到 TTL 刪除事件、把 item 寫進冷儲存（S3）再讓它從 hot table 消失：

1def handler(event, context):
2    for record in event["Records"]:
3        if record["eventName"] == "REMOVE":
4            principal = record.get("userIdentity", {}).get("principalId")
5            if principal == "dynamodb.amazonaws.com":  # TTL 刪除、非 application 刪除
6                archive_to_s3(record["dynamodb"]["OldImage"])

區分「TTL 自動刪除」vs「application 主動刪除」靠 userIdentity — 兩者都是 REMOVE record、但只有 TTL 刪除帶服務 principal。對應 streams-lambda-event-driven。

Scope warning：stream record 的 userIdentity 標記屬 vendor 規格、欄位細節 cross-verify 官方 doc；本段機制描述非 production case 揭露。

操作流程

從生命週期需求到上線的 6 步流程。

Step 1：判斷資料是否適合 TTL 管理

適合 TTL 的資料有「自然過期時間」：session、訊息通知、暫存 token、event log、合規保留期到期的資料。不適合的：需要精確即時刪除的、需要刪除前審批的、永久保存的。

Step 2：設計 expireAt 計算

寫入時算好 epoch 秒數的 expireAt；不同資料類型可不同保留期（通知 30 天、session 1 天、audit 依合規要求）。

Step 3：啟用 table TTL

1aws dynamodb update-time-to-live \
2  --table-name messages \
3  --time-to-live-specification "Enabled=true, AttributeName=expireAt"

Step 4：read 路徑加過期過濾

所有面向用戶的讀取、在 application 端比對 expireAt（或加 FilterExpression）；不要假設過期 item 已消失。

Step 5：（可選）接 TTL 刪除歸檔

需要保留過期資料的、接 stream Lambda、用 userIdentity 辨識 TTL 刪除、歸檔到 S3。

Step 6：驗證點

1# 寫一筆短 TTL item、等過期後確認：
2# 1. 過期但未刪窗口內仍可讀到（驗證需要 filter）
3# 2. 數小時後背景刪除生效、storage 下降
4# 3. 若接歸檔、確認 S3 收到對應 OldImage

Rollback boundary：關閉 TTL 即停止自動刪除、已刪除的 item 不可恢復（除非有歸檔）；啟用 TTL 前先確認 expireAt 計算正確、避免誤設過短把活躍資料刪掉。

失敗模式

production 常見的 5 個踩雷：

Case 1：expireAt 用毫秒或 ISO 字串

TTL 只認 Unix epoch 秒；填毫秒（多三位數）會讓過期時間落在遙遠未來、item 永不過期；填字串 TTL 直接不生效。修法：統一用 int(time.time()) + seconds、寫測試驗證 attribute 是秒級數值。

Case 2：以為 TTL 是即時刪除、做即時失效邏輯

用 TTL 當「到點立刻不可用」的開關（如優惠券到期）、實際過期後幾小時還能用。修法：即時失效靠 application 邏輯比對時間、TTL 只負責 清理 storage、兩者分開。

Case 3：報表 / 對帳撈到過期未刪 item

聚合 query 沒過濾過期 item、把可讀窗口內的殘留資料算進去。修法：所有讀取路徑一致地過濾 expireAt；對帳查詢明確排除過期。

Case 4：誤設過短保留期刪掉活躍資料

這個 case 跟前三個的失敗代價層級不同。前面的踩雷多半可回復 — storage 緩漲可回填、過期未刪可在讀取路徑加 filter、index 殘留會隨背景刪除自然消退。誤設過短保留期則是 不可逆 的：expireAt 計算 bug（少乘 86400、用錯時區基準）把保留期算成幾小時、背景程序把仍在使用的活躍資料當成過期 item 刪除、而 TTL 刪除不寫 undo log、刪掉就沒有從 DynamoDB 端救回的途徑、只能靠外部備份（PITR / 另存的 stream archive）回灌、且回灌期間資料缺口已經對線上服務造成影響。

代價的關鍵在於計算錯誤的爆炸半徑：一個錯誤常數會同時套用到所有新寫入 item、刪除是持續發生的背景行為、發現時往往已刪掉大批資料。修法的重心因此放在 上線前驗證 而非事後補救：上線前在 staging 用短週期資料驗證 expireAt 算出的絕對時間點符合預期、TTL 啟用初期把 TimeToLiveDeletedItemCount 跟預估刪除量對照、刪除量明顯偏高就立即停用 TTL 並排查計算、不等 storage 趨勢確認。對保留期敏感的 table 先開 PITR 當不可逆操作的最後防線。

Case 5：過期 item 仍被 GSI 索引、推高 index 成本

過期未刪 item 仍佔 GSI storage；大量過期堆積時 GSI 成本沒因「邏輯過期」下降。修法：理解 GSI 跟著 base item 生命週期、storage 降要等實際刪除；對成本敏感的 sparse index 設計可讓過期 item 不進 GSI（對應 gsi-lsi-design sparse index）。

Anti-recommendation：資料量小、storage 成本可忽略、或刪除需要審批/合規記錄 → 不必用 TTL；手動或排程刪除更可控。TTL 的價值在「大量有自然過期時間的資料、要低成本自動清理」（如 PayPay 式每日上億訊息）。

容量與觀測

CloudWatch metric：

• TimeToLiveDeletedItemCount：TTL 背景刪除的 item 數、確認 TTL 真的在運作
• table ItemCount / storage size：長期趨勢、確認過期清理讓 storage 趨於穩態
• 過期未刪比例：自行用 expireAt < now 的 item 數估算可讀窗口殘留量

判讀：

• TimeToLiveDeletedItemCount 為零但有設過期資料 → TTL 沒生效（attribute 名稱錯 / 值格式錯）
• storage 持續上漲且 TTL 刪除量遠小於寫入量 → 保留期設太長、或寫入遠超過期速度、要重估保留策略
• 大量過期未刪堆積 → 背景刪除跟不上寫入、storage 成本被殘留拉高

Scope warning：9.C26 PayPay 的「3 億/天 × 30 天 = 90 億筆」是 PayPay case 文章（9.C26）的策略段推算、非 PayPay 官方揭露的精確 item 數；引用時當量級壓力 anchor、不當精確數字。

接回 9.6 容量規劃模型、1.10 KV / Document DB 容量規劃。

邊界與整合

TTL vs cache TTL vs 合規保留

「TTL」這個詞在不同層意義不同、不要混用：

• DynamoDB TTL：主資料的生命週期管理、最終刪除、本篇主寫
• cache TTL（如 DAX item / query cache、Redis TTL）：快取副本的新鮮度邊界、過期是「重新回源」不是「刪除主資料」、主寫於 02 快取模組 與 dax-caching-strategy
• 合規保留期：法規要求的最短/最長保存、可用 TTL 實作到期清理、但刪除前的稽核記錄要另外保留（對應 7.7 audit trail）

Sibling 與 cross-link

• streams-lambda-event-driven — TTL 刪除觸發 stream REMOVE record、用 userIdentity 辨識、可做過期歸檔
• single-table-design-pattern — single-table 下不同 entity 用不同 expireAt 保留期
• gsi-lsi-design — 過期未刪 item 仍佔 GSI、sparse index 可讓過期不進 GSI
• on-demand-vs-provisioned — TTL 刪除免 WCU、不影響寫容量規劃、但 storage 成本要靠 TTL 控制
• 替代路由：快取副本新鮮度 → 02 快取模組；合規稽核 → 7.7 audit trail
• 跟 PayPay 9.C26 互引：每日上億訊息用 TTL 自動清理避免 storage 爆炸的 case anchor