Data Store Management · Topic 4 of 7

DynamoDB and NoSQL Stores

Learn DynamoDB keys, capacity modes, indexes, streams, TTL and S3 exports, and when OpenSearch, Neptune or other purpose built stores fit better.

4 min

In a nutshell

DynamoDB access is fast by key. Prefer Query over Scan.
On demand capacity suits unknown traffic, provisioned suits steady traffic.
A GSI can be added later with its own capacity. An LSI must be created with the table.

What it is

Amazon DynamoDB is a fully managed NoSQL key value and document database. It delivers consistently low latency at almost any scale, because data is spread across partitions by key.

It fits applications and pipelines that read and write items by key, such as session data, device state, order lookups and metadata stores for pipelines.

How it works

Keys and items

A table needs a partition key, and may add a sort key. Together they form the primary key. DynamoDB hashes the partition key to pick a partition, and uses the sort key to order items inside it.

Items are schemaless apart from the key, and one item can be up to 400 KB. Access is fast when you use the key. A Scan reads the whole table and is slow and costly for large tables, while a Query reads one partition key value, optionally with a sort key condition.

Capacity modes

Mode	How it works	Choose it for
On demand	Pay per request, no capacity planning	Unpredictable or new workloads
Provisioned	Set read and write capacity units, optionally with auto scaling	Steady, predictable traffic, often lower cost

A hot partition happens when too many requests hit one partition key value. The fix is a key with high cardinality and even access, not simply more capacity.

Secondary indexes

Index	Key	Notes
Global secondary index (GSI)	Different partition and sort key	Can be added any time, has its own capacity, reads are eventually consistent
Local secondary index (LSI)	Same partition key, different sort key	Must be created with the table

Use an index to support another access pattern, instead of scanning.

Consistency

Reads are eventually consistent by default. A strongly consistent read returns the latest write but is not available on a GSI. DynamoDB also supports transactions across items, for all or nothing writes.

Streams, TTL and change data

DynamoDB Streams records item level changes in order for 24 hours. A Lambda function can read the stream to update another store, send notifications or feed a pipeline. Kinesis Data Streams for DynamoDB is an alternative for longer retention and several consumers.

Time to Live (TTL) deletes expired items automatically based on an attribute holding an epoch timestamp, with no write capacity cost for the deletion. It suits session data and temporary records.

Moving data to analytics

DynamoDB is not built for ad hoc analytics.

Export the table to S3 with the export feature, which uses point in time recovery and does not consume table read capacity. Then query it with Athena or load it into Redshift. Redshift also supports loading directly from DynamoDB with COPY.

Backups come from on demand backups and point in time recovery (PITR), which can restore to any second in the retention window. Global tables replicate data across Regions for multi Region applications.

DAX and caching

DynamoDB Accelerator (DAX) is an in memory cache in front of DynamoDB for read heavy workloads, giving microsecond reads for repeated keys. It suits eventually consistent reads that repeat, not write heavy loads.

When DynamoDB is the wrong store

DynamoDB has no joins and no ad hoc query engine. Full text search belongs in OpenSearch Service, and a graph traversal across many hops is natural in Neptune and painful in DynamoDB.

If an application already speaks the Cassandra or MongoDB API, Amazon Keyspaces or Amazon DocumentDB keep that API. The previous page compares all of these stores side by side.

What to remember for the exam

DynamoDB access is fast by key. Prefer Query over Scan.
On demand capacity suits unknown traffic, provisioned suits steady traffic.
A GSI can be added later with its own capacity. An LSI must be created with the table.
Streams keep change records for 24 hours and feed Lambda.
TTL deletes expired items without consuming write capacity.
Export to S3 for analytics. It uses PITR and does not read from table capacity.
DAX accelerates reads with an in memory cache.
A high cardinality partition key avoids hot partitions.

Exam tip

If the scenario asks for analytics on DynamoDB data, the expected answer is export to S3 and query with Athena, not scanning the table.

Common mistakes

Designing like a relational database. DynamoDB has no joins. Design tables around the access patterns you know.

Choosing a low cardinality partition key. A key like "status" with three values creates hot partitions.

Expecting strong consistency on a GSI. Global secondary indexes are eventually consistent.

Scanning for reports. Scans read the entire table and use a lot of capacity.

Watch out

Streams retain records for only 24 hours, so a consumer that is down longer can miss changes.

Check yourself

Which index type must be created together with the table?
A local secondary index.
What is the best way to run heavy analytics on DynamoDB data?
Export the table to S3 and query it with Athena or Redshift.
What feature removes expired items automatically?
Time to Live (TTL).

Topic 4 of 7 in Data Store Management

Test yourself on Data Store Management

The full AWS DEA-C01 question bank has 845 questions, with timed practice exams and an explanation for every answer.

Subscribe Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.