DynamoDB TTL deletion timing guarantees and cost impact of expired items

Background

DynamoDB Time To Live (TTL) automatically removes expired items using a background process, but AWS provides no service-level agreement for when deletion occurs after the TTL timestamp expires. Documentation indicates deletions typically complete within 48 hours, though they can take longer depending on table size and partition distribution.

Constraint

Expired items remain readable and continue to consume storage capacity and read capacity units until the background process physically removes them. This behavior affects both cost forecasting and data freshness guarantees for applications that scan or query tables with TTL-enabled attributes.

Goal

Determine how to model application logic and cost projections when TTL expiration timing is non-deterministic and no API exists to query the TTL processing backlog or force immediate deletion.

What is the observed upper bound for TTL deletion latency in production workloads with high partition counts? How do teams account for expired-but-not-deleted items in storage cost models and read-capacity planning? Are there documented patterns for detecting TTL-driven removals via DynamoDB Streams to trigger downstream cleanup without relying on the deletion timestamp?