Automatically Expire DynamoDB Items with TTL (2026)

DynamoDB’s Time To Live (TTL) feature is often misunderstood as just a simple expiration mechanism, but its real power lies in how it interacts with your provisioned throughput and can dramatically reduce costs by allowing you to operate with lower capacity.

Let’s see TTL in action. Imagine you have a table storing session data.

{
  "session_id": "user123_session_abc",
  "user_data": {
    "login_time": 1678886400,
    "last_activity": 1678887000
  },
  "ttl_timestamp": 1678890000  // Unix epoch time for expiration
}

Here, ttl_timestamp is a Number type attribute. When this timestamp falls in the past, DynamoDB marks the item for deletion. You don’t need to do anything special; DynamoDB handles the background deletion process.

The primary problem TTL solves is the manual cleanup of stale data. Without it, your tables would grow indefinitely, leading to increased storage costs and slower query performance as you scan through old, irrelevant items. TTL automates this, keeping your data lean and efficient.

Internally, when an item’s TTL attribute indicates it’s expired, DynamoDB flags it. A background process then periodically scans for these expired items and deletes them. This deletion process consumes write capacity, but it’s a crucial part of the TTL mechanism. DynamoDB doesn’t charge for the TTL delete operations themselves; you only pay for the write capacity consumed by the deletion process.

The key lever you control is the ttl_timestamp attribute itself. You define this attribute in your table schema and configure DynamoDB to use it.

Here’s how you set it up:

1. Choose a TTL Attribute: Decide on an attribute in your item that will hold the expiration timestamp. This must be of the Number data type and store the expiration time as a Unix epoch timestamp (seconds since January 1, 1970, UTC). For example, if you want an item to expire 24 hours from now, and the current Unix epoch time is 1678886400, your ttl_timestamp would be 1678886400 + (24 * 60 * 60) = 1678972800.

2. Enable TTL on the Table: You do this via the AWS CLI or SDK. For example, using the AWS CLI:

   aws dynamodb update-time-to-live --table-name your-table-name --time-to-live-specification "Enabled=true,AttributeName=ttl_timestamp"
   

   Replace your-table-name with your actual table name and ttl_timestamp with the name of your chosen TTL attribute.

Once enabled, DynamoDB starts evaluating the ttl_timestamp for each item. Items with a ttl_timestamp value less than the current time are marked for deletion. The deletion process itself is eventually consistent, meaning it might take some time for an item to be fully removed after its TTL has passed.

The real magic of TTL, especially concerning costs, is its ability to let you provision less write capacity. If you know that 80% of your items will expire within a day, you can provision write capacity anticipating that the TTL process will consume a portion of it. This means you might only need to provision for the net writes (new writes + updates - expired writes), rather than the gross writes. For instance, if you expect 1000 writes per second and know TTL will delete 800 items per second, you might only need to provision for 200 write capacity units (WCUs) plus a buffer for the TTL deletions themselves, effectively amortizing the deletion cost across your active data.

Many people assume that the TTL deletion process consumes additional write capacity on top of what they’ve provisioned. In reality, the TTL deletion operations are performed by DynamoDB using the write capacity that is already available within your provisioned throughput. If your provisioned write capacity is saturated by regular write operations, the TTL deletions might be throttled, leading to a backlog of expired items that are not immediately removed. This is why it’s crucial to monitor your write capacity utilization and ensure you have enough headroom to accommodate both your application’s writes and the background TTL deletions. If you consistently see high write throttling and have TTL enabled, you might need to increase your provisioned write capacity.

The next step is understanding how to monitor the effectiveness of your TTL configuration and its impact on performance.