TTL with Streams for archival in DynamoDB

Introduction

TTL helps automatically remove old data. Streams let you capture changes to save that data somewhere else before it disappears.

You want to keep your database clean by deleting old records automatically.

You need to save deleted data for backup or audit before it is removed.

You want to archive expired data to a cheaper storage for future reference.

You want to track changes in your data over time for analysis.

You want to reduce storage costs by removing data but still keep a copy.

Syntax

DynamoDB

1. Enable TTL on a DynamoDB table by specifying an attribute (e.g., 'expireAt') that holds the expiration timestamp.
2. Enable DynamoDB Streams on the table to capture item removals.
3. Use a Lambda function triggered by the stream to process expired items and archive them (e.g., save to S3).

The TTL attribute must be a number representing epoch time in seconds.

Streams capture events like INSERT, MODIFY, and REMOVE. For TTL, focus on REMOVE events.

Examples

This attribute tells DynamoDB when to delete the item.

DynamoDB

TTL attribute: expireAt
Value example: 1686000000 (epoch seconds)

This event shows an item was deleted due to TTL expiration.

DynamoDB

Stream event example:
{
  "eventName": "REMOVE",
  "dynamodb": {
    "OldImage": {"id": {"S": "123"}, "expireAt": {"N": "1686000000"}}
  }
}

When an item is removed, the Lambda archives it.

DynamoDB

Lambda function pseudocode:
if eventName == 'REMOVE':
  archive(event.Records[0].dynamodb.OldImage)

Sample Program

This Lambda function listens to stream events and archives items removed by TTL.

DynamoDB

-- Step 1: Enable TTL on attribute 'expireAt' in DynamoDB console or CLI
-- Step 2: Enable Streams with NEW_AND_OLD_IMAGES
-- Step 3: Example Lambda function code snippet (Node.js)

const AWS = require('aws-sdk');

exports.handler = async (event) => {
  for (const record of event.Records) {
    if (record.eventName === 'REMOVE') {
      const oldItem = record.dynamodb.OldImage;
      // Convert DynamoDB JSON to normal JSON
      const archivedItem = AWS.DynamoDB.Converter.unmarshall(oldItem);
      // Save archivedItem to S3 or another storage
      console.log('Archiving item:', archivedItem);
      // (Archival code here)
    }
  }
};

Important Notes

TTL deletion is not immediate; it can take up to 48 hours.

Streams help you capture deleted items before they vanish.

Archiving lets you keep data for compliance or analysis.

Summary

TTL automatically deletes expired data to keep your table clean.

DynamoDB Streams capture these deletions as REMOVE events.

Use a Lambda triggered by streams to archive deleted data safely.

Practice

1. What is the main purpose of enabling TTL (Time to Live) on a DynamoDB table?

easy

A. Increase read capacity units for faster queries

B. Encrypt data at rest for security

C. Create backups of the table automatically

D. Automatically delete expired items to keep the table clean

Solution

1. Step 1: Understand TTL function

   TTL marks items with an expiration timestamp so DynamoDB can delete them automatically after expiry.

2. Step 2: Identify TTL's main benefit

   This automatic deletion helps keep the table clean without manual intervention.

3. Final Answer:

   Automatically delete expired items to keep the table clean -> Option D

4. Quick Check:

   TTL = automatic deletion [OK]

Hint: TTL deletes expired data automatically [OK]

Common Mistakes:

• Confusing TTL with encryption
• Thinking TTL creates backups
• Assuming TTL increases capacity

2. Which of the following is the correct way to enable TTL on a DynamoDB table using AWS CLI?

easy

A. aws dynamodb enable-ttl --table MyTable --attribute expiryDate

B. aws dynamodb set-ttl --table-name MyTable --ttl-attribute expiryDate

C. aws dynamodb update-time-to-live --table-name MyTable --time-to-live-specification Enabled=true,AttributeName=expiryDate

D. aws dynamodb activate-ttl --table MyTable --attributeName expiryDate

Solution

1. Step 1: Recall AWS CLI TTL command

   The correct command is 'update-time-to-live' with parameters for table name and TTL specification.

2. Step 2: Match correct syntax

   aws dynamodb update-time-to-live --table-name MyTable --time-to-live-specification Enabled=true,AttributeName=expiryDate uses the exact syntax: --time-to-live-specification Enabled=true,AttributeName=expiryDate.

3. Final Answer:

   aws dynamodb update-time-to-live --table-name MyTable --time-to-live-specification Enabled=true,AttributeName=expiryDate -> Option C

4. Quick Check:

   Correct CLI command = aws dynamodb update-time-to-live --table-name MyTable --time-to-live-specification Enabled=true,AttributeName=expiryDate [OK]

Hint: Use 'update-time-to-live' with Enabled=true [OK]

Common Mistakes:

• Using non-existent commands like enable-ttl
• Wrong parameter names
• Missing 'time-to-live-specification' flag

3. Given a DynamoDB Stream enabled on a table with TTL, what type of event will appear in the stream when an item expires and is deleted?

medium

A. INSERT

B. REMOVE

C. MODIFY

D. UPDATE

Solution

1. Step 1: Understand TTL deletion effect on streams

   When TTL deletes an item, DynamoDB Streams capture this as a REMOVE event because the item is removed.

2. Step 2: Identify correct event type

   INSERT and MODIFY happen on new or updated items, not deletions. REMOVE is the correct event for deletions.

3. Final Answer:

   REMOVE -> Option B

4. Quick Check:

   TTL deletion = REMOVE event [OK]

Hint: TTL deletions trigger REMOVE events in streams [OK]

Common Mistakes:

• Choosing INSERT or MODIFY for deletions
• Confusing UPDATE with MODIFY
• Assuming TTL triggers no stream events

4. You wrote a Lambda function triggered by DynamoDB Streams to archive deleted items. However, the Lambda never receives any events for expired items. What is the most likely cause?

medium

A. The stream is not enabled or not set to capture REMOVE events

B. TTL is not enabled on the table

C. Lambda function has no permissions to read the table

D. The table has no primary key defined

Solution

1. Step 1: Check stream configuration

   If the Lambda never receives events, the stream might be disabled or not configured to capture REMOVE events, which TTL deletions generate.

2. Step 2: Verify other causes

   TTL must be enabled, but if streams are off or missing REMOVE events, Lambda won't get notifications. Permissions or missing primary key would cause other errors.

3. Final Answer:

   The stream is not enabled or not set to capture REMOVE events -> Option A

4. Quick Check:

   Missing REMOVE events in stream = The stream is not enabled or not set to capture REMOVE events [OK]

Hint: Ensure stream captures REMOVE events for TTL deletions [OK]

Common Mistakes:

• Ignoring stream settings
• Assuming permissions cause no events
• Overlooking TTL enablement

5. You want to archive expired DynamoDB items to S3 using a Lambda triggered by Streams. Which approach ensures no data loss and handles possible Lambda failures?

hard

A. Process REMOVE events in Lambda and write directly to S3, retrying on failure

B. Use TTL to delete items, ignore streams, and periodically scan table for expired items

C. Disable TTL and manually delete items after archiving

D. Process INSERT events in Lambda and archive items before expiration

Solution

1. Step 1: Understand archival with TTL and streams

   TTL deletes expired items, streams capture REMOVE events. Lambda triggered by these events can archive data safely.

2. Step 2: Ensure reliability and no data loss

   Processing REMOVE events and writing to S3 with retries ensures data is archived even if Lambda fails temporarily.

3. Step 3: Evaluate other options

   Use TTL to delete items, ignore streams, and periodically scan table for expired items ignores streams and risks missing data. Disable TTL and manually delete items after archiving disables TTL, losing automatic cleanup. Process INSERT events in Lambda and archive items before expiration archives before expiration, which is not TTL-based archival.

4. Final Answer:

   Process REMOVE events in Lambda and write directly to S3, retrying on failure -> Option A

5. Quick Check:

   Reliable archival = Process REMOVE events in Lambda and write directly to S3, retrying on failure [OK]

Hint: Archive REMOVE events with retries for safety [OK]

Common Mistakes:

• Ignoring stream REMOVE events
• Disabling TTL unnecessarily
• Archiving on INSERT instead of REMOVE