Learn
AWS
Databases
DynamoDB

AWSGCP laterAzure later

DynamoDBAmazon DynamoDB

DatabasesCore service · full depthFree while we build the libraryChecked against AWS docs · 15 Sept 2026

A serverless key-value and document database with single-digit millisecond responses at any scale, and DAX, its in-memory cache, for microseconds.

In the examsSolutions Architect – AssociateHIGHSolutions Architect – ProfessionalHIGHDeveloper – AssociateHIGHSysOps Administrator – AssociateMEDData Engineer – AssociateMED

Where DynamoDB takes you6 steps, all open

I know the problem it solves
I can picture it
I know how it scales
I know when to choose it
I can use it in a design
I can answer an exam question

What & why

Items by key, at any scale

DynamoDB is a serverless NoSQL database. It stores items in tables, finds them by key in single-digit milliseconds however large the table grows, and has no servers to size, patch or run. Every table is kept in three Availability Zones.

No joins, but transactions. It holds key-value and document items and answers by key rather than by SQL joins, while still offering ACID transactions across items. DAX, its in-memory cache, brings repeated reads down to microseconds.

Reach for it when

the application fetches items by key, at any scale
traffic is unpredictable and nobody should plan capacity
a serverless stack of API Gateway and Lambda needs a database
several Regions must all accept writes

It is the wrong tool when

queries join many tables, or ask new questions every week: that is RDS
each record is several megabytes: keep it in S3 and store its key

Mental model

A cloakroom with numbered tickets

A cloakroom. Hand over your ticket and the attendant brings your coat at once, however long the queue, because each coat hangs where its number says. Ask for every blue coat and there is no quick answer, unless someone keeps a second list by colour.

The ticket numberthe key that says where an item livesPartition key

A coat on its hookone record, at most 400 KBItem

The second list, by colouranother way to find itemsGlobal secondary index

Counters at the doorthe reads and writes a second you pay forCapacity units

The attendant's notebook of popular coatsan in-memory cache in frontDAX

Cloakrooms in other citiescopies in other Regions that all take writesGlobal tables

How it works

Keys, capacity, indexes, reads

Choose the keysA partition key, and optionally a sort key, decide where each item lives and how you can ask for it.
Pick a capacity modeOn-demand, the default and AWS's recommendation, charges per request; provisioned sets the reads and writes a second.
Add indexes for other questionsA global secondary index can use any keys and be added at any time; a local one only when the table is made.
Read and write by keyReads are eventually consistent unless you ask for strongly consistent ones.

Latency: Single-digit msat any scale
Item size: 400 KBat most
Availability: 99.99%99.999% with global tables
Read unit: 4 KB a secondone strong or two eventual reads
Write unit: 1 KB a secondone write
DAX: Microsecondsfor repeated reads

The call
DAX answers GetItem, BatchGetItem, Query and Scan. Calls that manage tables, such as CreateTable, it does not recognise.
Consistency
An eventually consistent read, the default, can be answered from the cache. A strongly consistent one is passed to DynamoDB.
The cache
Is there a copy in the item cache, or for a Query or Scan in the query cache, still inside its TTL of 5 minutes by default?

Pick a case to follow the read through each check.

Architecture

A serverless API with nothing to size

The API invokes functions that read and write the table; each change flows to a worker, and global tables copy the table to another Region.

Nothing to size. No part of the path has a server to choose, and the table in on-demand mode takes whatever arrives.

Changes start work. A stream records every change to an item, in order for that item, keeps it for 24 hours, and can invoke a Lambda function.

Writes in two Regions. Global tables copy the table between Regions, every replica accepts writes, and when two writes clash the last writer wins.

Scaling

A budget a second, or none at all

Provisioned capacity is a budget a second. One write capacity unit is one write a second of an item up to 1 KB. One read capacity unit is one strongly consistent read a second, or two eventually consistent ones, of up to 4 KB. Go over the budget and requests are throttled.

Writes a second, 1 KB each 600

Write capacity units 500

Capacity: 1 writes a second, 1 KB each for each.

100 writes a second, 1 KB each more than 500 write capacity units can take. Add 100 more, or shed the load.

Auto scaling moves the budget. It raises and lowers provisioned capacity to keep use near a target utilisation; 70 percent is the recommendation.

On-demand has no budget. It serves what arrives and charges per request. A table can switch from provisioned to on-demand up to four times in 24 hours, and back at any time.

Bigger items take more units. A 3 KB write uses 3 write units, and an 8 KB strongly consistent read uses 2 read units.

DAX helps reads that repeat. Writes, strongly consistent reads and items read only once gain little from it.

Security

Encrypted by default, no passwords

Encrypted at rest, always, with a key AWS owns, an AWS managed key, or a customer managed key of your own.

IAM instead of passwords. Every request is signed and allowed by IAM policies; there are no database users or passwords to manage.

Point-in-time recovery restores a table to any second in up to the last 35 days, into a new table.

DAX runs inside your VPC, reached through its security groups.

Cost

How you are charged, not what it costs today

On-demand charges per read and write request unit; provisioned charges per capacity unit per hour, whether it is used or not.

Storage per GB-month, lower on the Standard-IA table class for tables that are rarely read.

The extras: backups, point-in-time recovery, writes replicated by global tables, and streams.

DAX by the node-hour, for as long as the cluster runs.

Expiring items is free. Time to Live deletes them without using any write throughput.

Prices change, so none are printed here. Check the DynamoDB pricing page on aws.amazon.com.

Comparison

Which database, which index, which cache

Database	Model	Grows by	Choose it when
DynamoDB	Key-value and document, no joins	Itself, with no servers	Lookups by key at any scale
RDS and Aurora	Relational, SQL with joins	A larger instance, replicas for reads	Joins and transactions across tables
ElastiCache	Keys and data structures in memory	More nodes or shards	A cache in front of any database

Index	Keys	Created	Reads	Per table
Global secondary	Any partition and sort key	At any time	Eventually consistent only	20
Local secondary	The table's partition key, another sort key	With the table only	Strong or eventual	5

Cache	Fronts	Code changes
DAX	DynamoDB only	Few: it speaks the DynamoDB API
ElastiCache	Anything the application puts in it	The application reads and fills it itself

SAA traps

The phrase in the question, and what it means

microsecond reads for a DynamoDB table with minimal code changesDAX

It speaks the DynamoDB API and answers repeated reads from memory.

strongly consistent reads, made faster with DAXDAX does not help them

It passes strongly consistent reads to DynamoDB and caches nothing from them.

query on another attribute, on a table that already existsA global secondary index

A local secondary index can only be created with the table.

strongly consistent reads from an indexA local secondary index

Global secondary indexes are eventually consistent only.

unpredictable traffic, and no capacity planningOn-demand mode

It serves what arrives and charges per request, and it is the default.

run code whenever an item changesDynamoDB Streams with a Lambda trigger

Each change is recorded, in order for its item, and kept for 24 hours.

a multi-Region, multi-active tableGlobal tables

Every replica accepts writes, and a clash goes to the last writer.

remove expired sessions without paying for the deletesTime to Live

Expired items are deleted within a few days, using no write throughput.

store a 2 MB document in each itemS3 for the document, its key in DynamoDB

An item can be no larger than 400 KB.

undo a bad batch job that ran an hour agoPoint-in-time recovery

It restores to any second in up to 35 days, into a new table.

Scenario

Exam style, marked when you answer

A gaming company keeps player profiles in a DynamoDB table. The same few thousand profiles are read constantly with eventually consistent reads, and read latency must fall from milliseconds to microseconds with as little change to the code as possible. What should a solutions architect do?

Practice

Fill the gap, the way the challenges work

A mobile app's API runs on API Gateway and Lambda. Orders are stored and fetched by their order ID, traffic swings from nothing to thousands of requests a second, and the database must have no servers to run and no capacity to plan. What do the functions write to?

API Gateway (REST)· REST APILambda· Order handlersPick a service below

Quick revision

The night before the exam

What: Serverless key-value and document store, single-digit ms.
Capacity: On-demand by default; provisioned for steady, known load.
Units: Read unit: 4 KB, one strong or two eventual. Write unit: 1 KB.
Indexes: GSI: any keys, any time, eventual. LSI: at creation, strong allowed.
Items: At most 400 KB; bigger objects go to S3.
Streams: Changes kept 24 hours; a Lambda trigger acts on them.
Global tables: Several Regions, every replica writes, last writer wins.
DAX: Microseconds, same API; strong reads skip the cache.

This whole page is free right now.The AWS library is still being written, so every page of it is open to everyone while that lasts. It becomes a paid bundle later; what you read today costs you nothing.

Checked against

Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.