DynamoDB TTL does not delete an item at the exact timestamp in its TTL attribute. That timestamp makes the item eligible for asynchronous, best-effort cleanup; until DynamoDB physically deletes it, the item can still appear in reads, queries, and scans. To stop expired data reaching your application, filter it in the read path and guard writes with conditions rather than relying on TTL cleanup as an access-control rule.
Why an expired DynamoDB item is still visible
TTL is background storage cleanup, not a read-time visibility rule. AWS says eligible items are deleted asynchronously on a best-effort basis. Its Developer Guide says deletion is typically within a few days after expiration; the UpdateTimeToLive API reference says typically within two days and notes that workload affects timing. Neither is a deadline or guarantee.
Until deletion, an expired item can be returned by reads, queries, and scans, and it continues to count toward storage and read costs. AWS explains that cleanup is best effort to preserve throughput for other data operations. See Using time to live (TTL) in DynamoDB and Working with expired items and time to live (TTL).
Diagnose the TTL configuration and item data
- Confirm TTL is enabled for the table you are querying. Enabling TTL can take approximately one hour to process across all table partitions. Check the table and its TTL status in the AWS console or through your normal configuration workflow. AWS describes the setup process in its TTL enablement guide.
- Check the configured attribute name against the stored item. The name is case sensitive. If the table is configured to use one spelling or capitalization but items contain another, DynamoDB will not treat that field as the TTL attribute.
- Inspect the attribute’s DynamoDB type and value. It must be a Number containing Unix epoch time in seconds. A string, a millisecond timestamp, or another representation is not the specified format and may be ignored. Also check whether the timestamp is more than five years in the past: those items are not eligible for TTL deletion. See AWS’s TTL computation guidance.
- Check the read path. If configuration and item format are correct, the record may simply be awaiting background deletion. Queries and scans can still return it unless your application filters expired records.
- Review writes to records that may already be expired. A pending item is still present and can be changed unless your write operation has a condition that prevents it. Make the condition reflect the application’s expiration rule.
Filter expired items from reads
When an expired record must not be shown, compare its TTL value with the current Unix epoch time in seconds and return only items whose expiration is later than the current time. AWS’s expired-items guide demonstrates filtering Query and Scan results with a condition against the current time.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall#1 Best Overall
For example, a filter expression should keep items only when the TTL attribute is greater than the current epoch-seconds value. Make sure the comparison uses seconds, not milliseconds, and use the exact configured attribute name. The TTL cleanup process can then continue independently; your application’s read behavior does not have to wait for physical deletion.
A Query or Scan filter controls which matching items your application accepts from that operation; it does not make TTL deletion immediate. Keep the distinction clear in the code: filtering enforces visibility, while TTL eventually removes eligible items from storage.
Prevent writes to expired-but-present items
If an expired record must not be updated or reused, use a condition expression on the write. The condition should test the TTL attribute against the application’s current epoch time in seconds, or otherwise enforce the expiration policy that applies to that record. AWS documents condition expressions as a way to avoid writing to expired items in its expired-items guide.
Choose the write condition deliberately for the cases your schema permits. For example, an item with no TTL attribute may be intended to have no expiration; decide whether the write is allowed in that case rather than assuming every item has an expiry. The important safeguard is that a successful write must not silently violate the application’s definition of an expired record.
Choose the mechanism that matches the requirement
| Need | Mechanism | What it does |
|---|---|---|
| Stop expired items from being returned by the application now | Filter reads using TTL versus current epoch seconds | Controls which returned items the application accepts while cleanup is pending. |
| Stop writes from changing expired items | Use a condition expression on writes | Enforces the application’s expiration rule for a write operation. |
| Eventually remove expired items from the table | Enable and correctly configure DynamoDB TTL | Deletes eligible items asynchronously, without an exact-time deadline. |
If the business rule is that expired data must never be served, enforce that rule in the read and write paths. TTL is useful for eventual cleanup, but its physical deletion timing is not a safe gate for access or correctness.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to know about Streams and Global Tables
DynamoDB Streams
When Streams is enabled, a TTL deletion appears as a service deletion. In the Region where the deletion occurs, AWS documents userIdentity.type as Service and userIdentity.principalId as dynamodb.amazonaws.com. A consumer can use this identity to identify TTL deletions in that Region. See Identifying deleted items in DynamoDB Streams.
Rank #4
Global Tables
For Global Tables version 2019.11.21, TTL deletions replicate to all replica tables. AWS says the initial delete does not consume write capacity in the Region where expiration occurs, while replicated deletes consume replicated write capacity or replicated write units in replica Regions, with applicable charges. In Regions receiving a replicated deletion, the stream event does not have the same TTL service identity marker as the event in the Region where the deletion originated.
For operational or cost planning, check the current billing mode and AWS pricing for your table and replica setup; the capacity and charges depend on the applicable configuration. AWS documents TTL behavior in its TTL guide and regional stream identity in the Streams guide.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
