Lesson 130 · AWS Learning Path

AWS 130: Amazon DynamoDB fundamentals

Anil Jalela · Published Nov 2, 2025 · 12 min read

Why this lesson matters

Model low-latency key-value and document access around known keys, item collections, partitions, and service limits.

DynamoDB is designed around known key-based access patterns and distributed partitions. It removes database-server administration, but it makes key design, request units, item limits, consistency, conditional writes, retries, and hot-key prevention application architecture concerns.

What you will be able to do

By the end, you can:

• explain amazon dynamodb fundamentals in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------+
|  Known access pattern  |
+------------------------+
            |
            v
+--------------------------+
|  Partition and sort key  |
+--------------------------+
             |
             v
+-------------------------------+
|  Distributed table operation  |
+-------------------------------+
               |
               v
+-------------------------------------------------+
|  Latency, throttling, and correctness evidence  |
+-------------------------------------------------+

For Amazon DynamoDB, the important boundary is this: Tables contain items identified by a partition key or composite primary key. DynamoDB distributes data by partition key and exposes table, item, index, stream, backup, and capacity controls. The model answers required queries without scans, spreads traffic, controls item size, selects consistency, protects data, and measures throttling and latency. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

Core resources and vocabulary

DynamoDB supports key-value and document attributes, but it does not provide relational joins. Denormalization and item duplication are deliberate when they make a required query one bounded operation. Every duplicated view needs an authoritative write/reconciliation strategy.

Request path

application role + signed HTTPS API request
          |
          v
IAM / table-resource policy / endpoint policy / KMS authorization
          |
          v
table -> hash partition key -> physical partition -> item/sort-key operation
          |
          +-> optional index update
          +-> optional stream/change-data record
          +-> global-table replication / backup / export
          v
response: item or consumed capacity, consistency result, errors

The service is Regional and replicates table data across multiple AZs. A gateway VPC endpoint can keep supported VPC traffic on AWS paths and adds an endpoint policy; it does not grant table access. Identity policies can restrict table/index ARNs, actions, leading keys, attributes, tags, and request conditions. Fine-grained authorization must be tested against every index/access pattern.

Operations and read behavior

Projection expressions reduce returned bytes but capacity calculation normally depends on item size read, not just attributes returned. Filter expressions reduce response items after DynamoDB reads candidates. Key conditions are what bound a Query efficiently.

Consistency and concurrency

Eventually consistent reads are the default for table and supported index reads and can return stale data. Strongly consistent reads can be requested on tables and local secondary indexes in the same Region but not on global secondary indexes or streams. Strong reads cost more read capacity and do not make a multi-Region global-table operation universally synchronous.

Conditional expressions provide optimistic concurrency and invariants:

• attribute_not_exists(PK) prevents accidental overwrite on create;
• compare a numeric/version attribute before update;
• ensure stock is sufficient before decrement;
• make delete conditional on expected state.

Use transactions when several items must change atomically in one Region and conditions alone are insufficient. Design idempotency for SDK/client retries. A timeout can hide whether the original write succeeded; a unique request token/business key plus conditional state prevents duplicate orders/payments.

Partitions, hot keys, and adaptive capacity

DynamoDB hashes the partition key. High-cardinality values with distributed traffic usually spread well; low-cardinality or one celebrity key can concentrate load. Each physical partition has finite throughput, and current documented maximums include 1,000 write units/second and 3,000 read units/second. Adaptive capacity can isolate/rebalance hot items within table and partition limits but cannot make one key infinitely scalable.

Symptoms include throttled requests below total table capacity, high latency/retries for one tenant/key, and uneven Contributor Insights data. Corrections include write sharding a hot logical key, time-bucketing, caching, distributing counters, changing access model, or isolating tenants. Every shard increases read fan-out and reconciliation complexity.

An LSI constrains an item collection to the documented 10-GB limit because it shares the base partition-key placement. Large unbounded histories under one customer key require time buckets, a GSI, separate archival, or another design.

Capacity and request-unit math

For capacity planning, round each item involved according to DynamoDB's documented unit blocks. Broadly:

• one WCU supports one write per second for an item up to 1 KB; larger writes round up by KB;
• one RCU supports one strongly consistent read per second up to 4 KB, or two eventually consistent reads; larger items round up by 4 KB;
• transactional reads/writes consume higher units than standard operations;
• indexes consume additional write capacity/storage for projected entries.

Example: an eventually consistent read of a 6-KB item rounds to two 4-KB blocks and consumes one RCU for one read/second; a strong read consumes two RCUs. A 1.2-KB write rounds to 2 WCUs. Verify exact current formulas for transactions and on-demand request units.

On-demand mode charges per request unit and scales based on current/warm throughput and prior traffic; it can scale to zero request throughput cost but storage/features remain. Provisioned mode sets RCU/WCU and can use auto scaling/Reserved Capacity. Both can throttle due to hot partitions, account/table maximums, or sudden traffic beyond warm capacity. AWS now exposes warm throughput and configurable on-demand maximum throughput, so old “on-demand can never throttle” teaching is false.

Data lifecycle and protection

• Time to Live asynchronously deletes expired items without a precise deletion-time SLA. Applications must treat expired data as invalid before physical removal where required.
• DynamoDB Streams retain an ordered per-item change sequence for a limited window and feed Lambda/consumers; delivery processing must handle retries/duplicates.
• Point-in-time recovery continuously protects a rolling window and restore creates a new table.
• On-demand backups persist until deletion; export to S3 supports analytics/recovery workflows but is not an in-place restore.
• Encryption at rest is integrated; customer-managed KMS keys add policy/state/cost dependencies.
• Global tables add multi-Region replicas and conflict/consistency choices, covered in AWS 133.

Single-table design example

For orders:

PK=CUSTOMER#42  SK=PROFILE                 customer item
PK=CUSTOMER#42  SK=ORDER#2026-09-14#991   order summary
PK=ORDER#991     SK=LINE#001               line item
PK=ORDER#991     SK=LINE#002               line item
PK=ORDER#991     SK=STATUS#2026-09-14T...  status event

This supports customer order history and order detail by Query. A GSI might invert status/date for “all pending orders.” The write transaction can put order summary and conditional inventory/idempotency record. Do not claim one-table design is always superior: separate tables can simplify capacity, permissions, backup, lifecycle, and team ownership.

Required tests

1. Put one item conditionally, then repeat and prove ConditionalCheckFailedException protects it.
2. Query one item collection with key condition and compare consumed capacity against a filtered Scan.
3. Run eventual and strong reads in a controlled update test and explain where strong reads are unsupported.
4. Generate a bounded hot-key workload, observe throttling/retries/Contributor Insights, shard it, and measure the tradeoff.
5. Force an unprocessed batch response in supplied evidence and implement exponential backoff for only unprocessed items.
6. Restore PITR/backup to a new table, validate marker items and permissions, then remove owned resources.
7. Calculate table, every index, streams/CDC, backups/exports, global replicas, DAX, KMS, transfer, and monitoring cost.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Open DynamoDB Tables and inspect an approved table or supplied design.
2. Read General information, Items, Indexes, Capacity, Exports and streams, Backups, and Metrics.
3. Use Explore table items only with approved data and do not run an unbounded scan.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws dynamodb list-tables --output table
aws dynamodb describe-table --table-name replace-with-table-name --query 'Table.{Name:TableName,Status:TableStatus,Keys:KeySchema,Billing:BillingModeSummary.BillingMode,Items:ItemCount,Bytes:TableSizeBytes}' --output json
aws dynamodb describe-continuous-backups --table-name replace-with-table-name --output json

Expected interpretation

DescribeTable reports configuration and approximate counts. It does not prove access-pattern fit, even traffic distribution, item correctness, or application latency.

Practical work

Model orders, customer history, and order-status lookups in one table design. List each access pattern first, then write the keys and one example item per pattern.

Diagnose this topic from its own evidence

Start with the operation's HTTP status, exception, consumed capacity and CloudWatch metrics. ResourceNotFoundException usually means the wrong table name, Region or lifecycle state; AccessDeniedException is an IAM/resource-policy or KMS boundary; ConditionalCheckFailedException can be an expected concurrency outcome; throttling requires its returned throttling reason plus partition/capacity evidence. A successful write followed by a missing eventually consistent read is not proof of data loss - repeat with ConsistentRead=true where supported and inspect the exact key. Never “fix” a hot key merely by raising table capacity; first prove key distribution.

Negative test: repeat a conditional create with the same primary key. The second request must fail without overwriting the item. Then read the item, inspect consumed capacity and explain why this protects an invariant better than read-then-write logic.

Cost and cleanup

Read and write capacity or on-demand requests, storage, backups, streams, change data capture, global replication, DAX, transfer, and export can charge.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Model low-latency key-value and document access around known keys, item collections, partitions, and service limits.

1. Which scope or ownership boundary must be proved first?

Expected direction: Tables contain items identified by a partition key or composite primary key. DynamoDB distributes data by partition key and exposes table, item, index, stream, backup, and capacity controls.

1. What evidence is strong enough to accept the result?

Expected direction: The model answers required queries without scans, spreads traffic, controls item size, selects consistency, protects data, and measures throttling and latency.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid beginning with a normalized relational schema, depending on table scans, or using a hot low-cardinality partition key.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Read and write capacity or on-demand requests, storage, backups, streams, change data capture, global replication, DAX, transfer, and export can charge.

Lesson acceptance

Pass when the learner can derive a complete primary key from access patterns, calculate request units for stated item sizes, distinguish eventual and strong reads, use a condition expression safely, explain item/transaction limits and partition risk, and prove encryption, PITR/backup, TTL and Streams choices from evidence. The design must include retry behavior with jitter, idempotency, monitoring, cost dimensions and cleanup. Fail if it relies on scans as the normal path, uses a low-cardinality hot partition key, treats TTL as an exact scheduler or assumes a successful HTTP response proves a business invariant.

Official sources

• DynamoDB introduction
• DynamoDB core components
• AWS databases
• Database decision guide