AWS Services
Amazon DynamoDB
Learn DynamoDB as managed NoSQL key-value and document storage, including keys, indexes, capacity, scaling, security, resilience, and exam signals.
After this, you will understand
DynamoDB becomes much less mysterious when you stop asking how to query everything and start designing for known access patterns.
DynamoDB is a managed NoSQL database for low-latency key-value and document access at large scale.
Learners treat DynamoDB like a relational database and expect ad hoc joins, arbitrary queries, and schema redesign after launch to be free.
Model the access patterns first, then choose partition keys, sort keys, indexes, capacity mode, and global table strategy.
Think before readingWhat should you know before designing a DynamoDB table?
Reading in progress
This page is saved in your local study history so you can continue later.
Concepts Covered
- NoSQL key-value and document model
- Tables, items, and attributes
- Partition keys and sort keys
- Primary keys
- Global secondary indexes
- Local secondary indexes
- On-demand and provisioned capacity
- DynamoDB Streams
- Global tables
- DAX and common exam traps
1. Plain-English Mental Model
Amazon DynamoDB is a fully managed NoSQL database for applications that need predictable low-latency access at scale.
Instead of designing many relational tables and joining them with SQL, you design a table around known access patterns. You decide how the application will look up data, what key it will use, whether items need to be sorted within a partition, and which secondary indexes are required for alternate access paths.
The simple model is:
known access pattern -> key design -> fast item lookup
A DynamoDB table contains items. Items contain attributes. Every item has a primary key. The primary key can be only a partition key or a partition key plus a sort key.
DynamoDB is managed. You do not manage database servers, shards, replication machinery, patching, or storage provisioning in the traditional sense. But you absolutely still design the data model.
2. Why This Service Exists
Relational databases are powerful, but not every workload needs joins, complex transactions, and ad hoc SQL. Some applications mainly need fast lookups by key, huge scale, flexible item shapes, and predictable performance.
Examples include shopping carts, user profiles, session data, IoT device state, game state, metadata lookup, leaderboards, event indexes, and serverless application backends.
DynamoDB exists to make these workloads operationally simple at large scale. AWS handles partitioning, replication within a Region, scaling mechanics, and service operation. The customer focuses on access patterns, capacity mode, indexes, security, and data lifecycle.
For SAA-C03, DynamoDB is often the answer when a question emphasizes fully managed NoSQL, key-value access, serverless scaling, single-digit millisecond latency, unpredictable traffic with on-demand capacity, or multi-Region active-active with global tables.
3. The Naive Approach And Where It Breaks
The naive approach is to design DynamoDB like a relational database.
That usually means one table per entity, then expecting joins or arbitrary queries later:
users table
orders table
products table
payments table
This can work for simple cases, but it breaks when the application needs to fetch data efficiently by access pattern. DynamoDB is not optimized for arbitrary joins. You design for queries you know you need.
Another naive approach is to choose a bad partition key, such as a value that every request shares. That creates a hot partition where too much traffic targets one partition key. The service is managed, but key design still matters.
A healthier DynamoDB design starts with questions:
- How will the application read this data?
- What exact key does each read know?
- Does the result need sorted order?
- Which access patterns need secondary indexes?
- What is the expected read and write rate?
- Can the application tolerate eventual consistency?
4. Core Primitives
A table stores items. An item is like a flexible row. Attributes are fields on the item.
The partition key determines how data is distributed and how items are found. A table with only a partition key can have one item per partition key value. A table with a partition key and sort key can store multiple related items under one partition key and sort them by sort key.
A global secondary index, or GSI, provides an alternate partition key and optional sort key. It supports access patterns that the base table key cannot serve efficiently. A local secondary index, or LSI, uses the same partition key as the base table but a different sort key and must be created with the table.
Capacity can be on-demand or provisioned. On-demand is simple and adapts to traffic. Provisioned capacity can be cheaper for predictable workloads and can use auto scaling.
DynamoDB Streams capture item-level changes for event-driven workflows.
5. Architecture Use Cases
Use DynamoDB for serverless application state, shopping carts, session stores, user preference documents, IoT device metadata, event lookup, API backends, gaming state, and workloads with high request rates and clear key access.
A common serverless design is:
API Gateway -> Lambda -> DynamoDB
The Lambda function reads or writes items by key. IAM controls access. DynamoDB handles storage and scaling. Streams can trigger downstream processing.
A global application might use DynamoDB global tables to replicate data across Regions. This supports low-latency regional reads and writes, but it requires conflict and data model awareness.
For read-heavy hot data, DynamoDB Accelerator, or DAX, can provide an in-memory cache for DynamoDB API-compatible reads. It is not a general cache for every database type.
7. Security Model
DynamoDB access is controlled through IAM. Identity policies can allow specific actions on specific tables or indexes. Fine-grained access control can use conditions for more specific patterns.
Encryption at rest is provided, with AWS-owned, AWS-managed, or customer-managed KMS key options depending on configuration. Encryption in transit uses HTTPS.
Network access to DynamoDB normally goes through public AWS service endpoints, but VPC gateway endpoints can provide private connectivity from a VPC.
Backups, point-in-time recovery, deletion protection, and least privilege all matter. A fully managed database can still lose data through accidental deletes or overly broad permissions if recovery controls are not enabled.
Customer responsibilities include data modeling, access permissions, item-level data protection, backup choices, and application correctness.
8. Reliability And Resilience
DynamoDB is designed as a highly available regional managed service. Data is replicated across multiple Availability Zones within a Region.
Point-in-time recovery can protect against accidental writes or deletes by allowing restoration to a previous point within the configured window. On-demand backups can be retained independently.
Global tables replicate tables across Regions for multi-Region availability and lower-latency local access. This is more advanced than a single-Region table. Applications need to handle replication behavior and possible write conflicts.
DynamoDB Streams can help build recovery, auditing, indexing, and event-driven workflows, but they are not a substitute for backups.
Design resilience around access patterns too. A hot key can create performance and availability symptoms even though the service is managed.
9. Performance And Scaling
DynamoDB performance depends heavily on key design and capacity mode.
Good partition keys spread traffic across many values. Bad partition keys concentrate traffic. A leaderboard where every write uses the same partition key may create a hot partition unless the design spreads writes appropriately.
On-demand capacity is easiest for unpredictable traffic. Provisioned capacity can be tuned for predictable traffic and can use auto scaling. Strongly consistent reads cost more capacity than eventually consistent reads.
Indexes have their own capacity and storage impact. A GSI can make a new query pattern efficient, but it is not free. It also introduces asynchronous propagation from the base table.
DAX can improve read latency for read-heavy workloads that repeatedly fetch the same items. It does not fix poor write design or arbitrary query needs.
10. Cost Model
DynamoDB cost depends on capacity mode, read and write request volume, storage, backups, streams, global tables, data transfer, and optional DAX clusters.
On-demand pricing is easy to operate but may cost more for steady high-volume workloads. Provisioned capacity can be cheaper when traffic is predictable, but under-provisioning causes throttling and over-provisioning wastes money.
Indexes add storage and write cost because writes to the base table may also update indexes. Global tables multiply write and storage costs across replicated Regions.
Backups, point-in-time recovery, and DAX add additional cost. As always, the right answer depends on access pattern, scale, recovery needs, and operational overhead.
12. SAA-C03 Exam Signals
"Fully managed NoSQL database" points to DynamoDB.
"Key-value access with single-digit millisecond latency" points to DynamoDB.
"Unpredictable traffic and minimal capacity planning" points to on-demand capacity.
"Predictable traffic and cost optimization" may point to provisioned capacity with auto scaling.
"Multi-Region active-active NoSQL table" points to DynamoDB global tables.
"React to item changes" points to DynamoDB Streams.
"Cache repeated DynamoDB reads" points to DAX.
13. Common Exam Traps
Do not choose DynamoDB for complex relational joins and ad hoc SQL reporting.
Do not ignore partition key design. Managed does not mean data modeling no longer matters.
Do not use a GSI as if it were free. It adds storage, write propagation, and capacity considerations.
Do not choose DAX for write-heavy workloads or as a generic Redis replacement.
Do not assume global tables remove all conflict and consistency concerns. Multi-Region writes still require application-aware design.
Do not forget point-in-time recovery when the question emphasizes accidental deletion recovery.
15. Related Topics
Compare DynamoDB with Amazon RDS. RDS is relational and SQL-oriented. DynamoDB is access-pattern-oriented and NoSQL.
Review IAM Foundations because DynamoDB access is IAM-driven, especially in serverless applications.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.