DynamoDB Design and Data Lifecycles

What it is

Amazon DynamoDB stores items in tables and finds them by primary key. Fast, cheap access comes from choosing keys and indexes that match the questions your code asks.

Data also has a lifecycle. Old sessions, logs and messages should expire or move to cheaper storage on their own, instead of by hand. DynamoDB uses TTL, S3 uses Lifecycle rules, and other services use retention periods.

How it works

Keys and attributes

The primary key is either a partition key alone or a partition key plus a sort key. DynamoDB hashes the partition key to pick the physical partition, and keeps items with the same partition key sorted by the sort key.

• Choose a high cardinality partition key, meaning one with many distinct values and evenly spread traffic, such as customerId. A key like status sends most traffic to one partition and causes throttling on a hot partition.
• Other attributes are schema free, and one item can be up to 400 KB.
• A composite key such as customerId plus orderDate lets one Query return a customer's orders in order.

Query, Scan and writes

A filter expression on a Scan or Query runs after the read, so it shrinks the response but not the capacity used. Each call returns at most 1 MB, and LastEvaluatedKey is your cue to call again with ExclusiveStartKey.

resp = table.query(
    KeyConditionExpression=Key("customerId").eq("c-17")
        & Key("orderDate").begins_with("2026-10"),
    ProjectionExpression="orderId, total",
)

For writes, PutItem replaces an item and UpdateItem changes attributes, including atomic counters. A ConditionExpression makes a write conditional, which supports optimistic locking with a version attribute. BatchGetItem, BatchWriteItem and transactions group operations.

Read consistency and capacity

One write capacity unit writes one item of up to 1 KB per second. In provisioned mode you set capacity, and in on demand mode DynamoDB scales for you. An exceeded limit returns ProvisionedThroughputExceededException, which the SDK retries with backoff.

Indexes

Query an index by passing IndexName. Each index copies the attributes you project into it.

Expiring data with TTL

Enable TTL on a table and name an attribute that holds a Number of Unix epoch seconds. DynamoDB deletes expired items in the background, typically within a few days, and the deletes use no write capacity.

Expired items can still be returned until they are deleted, so filter them out in queries. TTL deletions appear in DynamoDB Streams.

S3 Lifecycle and retention periods

An S3 Lifecycle configuration is a set of rules, each with a filter by prefix, tag or size.

• Transition actions move objects between storage classes, for example Standard to Glacier Flexible Retrieval after 30 days. Objects smaller than 128 KB do not transition by default.
• Expiration actions delete current objects, noncurrent versions or expired delete markers, and can abort incomplete multipart uploads.

{"Rules":[{"ID":"logs","Status":"Enabled","Filter":{"Prefix":"logs/"},
 "Transitions":[{"Days":30,"StorageClass":"GLACIER"}],
 "Expiration":{"Days":365}}]}

Other services use retention periods. SQS keeps messages for 4 days by default, up to 14. Kinesis keeps records for 24 hours by default, up to 365 days. CloudWatch Logs keeps events forever unless you set a retention period on the log group.

How the exam asks about this

• "Session items must disappear after 24 hours without any cleanup code." -> Enable TTL and store an expiry epoch in a Number attribute.
• "Queries by email are needed on a table keyed by userId." -> Add a global secondary index on email.
• "Logs in S3 are rarely read after 30 days and must be deleted after a year." -> A Lifecycle rule with a transition and an expiration.