DynamoDB TTL deletion timing guarantees and cost impact of expired items

Answer to the Core Question

In production, the longest observed TTL deletion latency on tables with many partitions (e.g., >1 000 partitions) is in the range of 3–5 days. AWS documentation cites a typical 48‑hour window, but real‑world tests show that the sweeper can be delayed when partitions are unevenly populated or when the table is very large. There is no SLA or API to shorten this window.

Impact on Storage and Read Capacity

Expired items remain fully readable and continue to consume:

• Storage bytes (charged per GB‑month)
• Provisioned RCUs (or on‑demand read request units) for any Scan/Query that touches them

Because a filter expression is applied only after the read, RCUs are still consumed for the full item size unless the query is structured to avoid reading those items entirely.

Modeling Cost Projections

Teams typically adopt a 2–3 day buffer when projecting storage growth:

ProjectedStorageBytes = CurrentStorageBytes + (AvgItemSize * ExpiredItemCount * 3)

For RCU planning, add the same buffer to the number of items you expect to scan:

ProjectedRCU = (BaseQueryItems + ExpiredItemCount * 3) * RCUPerItem

When using an on‑demand table, the same multiplier applies to read‑request‑unit cost. If you can filter out expired items in the query (e.g., attribute_not_exists(ttl) OR ttl > :now), the cost penalty is only the FilterExpression overhead, not the full read of each expired item.

Detecting Physical Deletion via Streams

The only reliable signal that an item has been physically removed is a DELETE record in DynamoDB Streams. The record’s userIdentity.type is Service and OldImage is null. You can use this to trigger downstream cleanup (e.g., delete an associated S3 object or update a search index).

Pattern:

• Enable Streams with NEW_AND_OLD_IMAGES.
• When a DELETE arrives, check record.eventSourceARN and record.eventID to confirm it is TTL‑driven.
• Invoke your cleanup Lambda or event‑driven function.

Practical Verification Steps

1. Create a test item with ttl = currentTime + 300.
2. Record the wall‑clock time when the item is written.
3. Poll Streams for the corresponding DELETE record and note the timestamp.
4. Repeat across multiple partition keys to capture variance.
5. Use CloudWatch metrics (ConsumedReadCapacityUnits) to quantify RCU waste during a full‑table Scan with and without the TTL filter.

Key Takeaways

• There is no guaranteed upper bound; 3–5 days is a realistic worst‑case for heavily partitioned tables.
• Always include a 2–3 day buffer in storage and RCU cost models for expired items.
• Leverage Streams DELETE events for downstream cleanup; do not rely on TTL timestamps alone.
• Design queries to avoid reading expired items when possible, or use a GSI with a TTL‑based sort key to sidestep the issue entirely.

Missing Diagnostic Detail?

Do you use provisioned or on‑demand capacity? That choice changes how RCU waste is billed and may affect the optimal filter strategy.