AWS DynamoDB Tutorial (2025): Architecture, Best Practices, Pricing & Real-World Examples

Last Updated: January 2025
Reading Time: 18 minutes
Author: Srikanth Ch, Senior DevOps Engineer

Imagine a database that scales to millions of requests per second without you provisioning a single server — that’s Amazon DynamoDB.

I remember the first time I had to handle a flash sale for an eCommerce client. Our PostgreSQL instance was sweating bullets at 10,000 concurrent users. We scrambled, scaled vertically, threw money at bigger instances, and still faced timeouts. That experience taught me something valuable: not every workload belongs in a relational database.

When I finally migrated that same workload to DynamoDB, the results were eye-opening. Single-digit millisecond latency at any scale. No more 3 AM pages about database connections maxing out. No more capacity planning nightmares before Black Friday.

This AWS DynamoDB Tutorial walks you through everything I’ve learned about DynamoDB over years of production experience — from fundamental architecture to advanced patterns that’ll help you ace your AWS certifications and build genuinely scalable systems.

What is Amazon DynamoDB?

DynamoDB is AWS’s fully managed NoSQL database service designed for applications requiring consistent, single-digit millisecond performance at any scale.

Unlike traditional databases where you worry about servers, storage provisioning, replication, and failover — DynamoDB handles all of that behind the scenes. You create a table, define your keys, and start writing data. AWS manages everything else across multiple Availability Zones automatically.

Why do modern cloud-native applications love DynamoDB?

Three reasons stand out from my experience:

First, true serverless architecture. There are no instances to manage, no patches to apply, no storage to provision. Your ops team can focus on building features instead of babysitting database servers.

Second, predictable performance at scale. Whether you’re handling 10 requests or 10 million requests per second, DynamoDB maintains consistent latency. This predictability is gold when building user-facing applications.

Third, native AWS integration. DynamoDB plays beautifully with Lambda, API Gateway, Step Functions, and EventBridge. Building event-driven architectures becomes almost trivial.

Real-World DevOps Use Cases:

• Serverless backends: Lambda functions storing user sessions, preferences, and application state
• IoT data ingestion: Handling millions of sensor readings per second from connected devices
• Microservices state storage: Each service owning its data without shared database bottlenecks
• Gaming leaderboards: Real-time score updates with global rankings
• Shopping carts: Session-based storage with automatic expiration using TTL

DynamoDB vs RDS vs MongoDB: When to Use What

One of the most common questions I get from engineers: “Should I use DynamoDB, stick with RDS, or go with MongoDB?”
There’s no universal answer — each database excels in different scenarios. Here’s the comparison table I wish I had when making these decisions:

My Decision Framework:

Choose DynamoDB when:

You need guaranteed single-digit millisecond latency at any scale
Your access patterns are known and key-based
You’re building serverless-first architectures
You want zero database administration
High write throughput is critical

Choose RDS when:

You need complex queries with joins and aggregations
Your data is highly relational with integrity constraints
Your team has strong SQL expertise
You need full ACID transactions across multiple tables
Reporting and ad-hoc queries are frequent

Choose MongoDB when:

You need flexible schemas that evolve rapidly
Your queries are complex but don’t require joins
You want document-based storage with rich query capabilities
You’re migrating from an existing MongoDB deployment
You need the aggregation pipeline for analytics

🎯 Real Talk: I’ve seen teams choose DynamoDB because it’s “serverless and modern,” then struggle for months because their access patterns needed joins. I’ve also seen teams stick with RDS out of comfort, then hit scaling walls during growth spurts.
The key insight: DynamoDB requires you to know your access patterns upfront. If you’re still discovering how users interact with your data, RDS or MongoDB’s query flexibility might save you from costly redesigns.

DynamoDB Architecture Overview

Understanding DynamoDB’s architecture changed how I approach NoSQL design. Let me break down the core components.

Tables are the primary containers for your data — similar to tables in relational databases, but without a fixed schema beyond your key attributes.

Items are individual records within a table. Think of them as rows, except each item can have different attributes. One item might have 5 attributes while another has 50 — DynamoDB doesn’t care.

Attributes are the name-value pairs that make up an item. These can be scalar types (string, number, binary), document types (list, map), or set types (string set, number set).

Partitions are where things get interesting. DynamoDB automatically divides your table into partitions based on your partition key. Each partition can handle approximately 3,000 RCUs or 1,000 WCUs and store up to 10 GB of data.

Here’s what many engineers miss: DynamoDB’s performance depends heavily on how evenly your data distributes across partitions. Poor key design leads to “hot partitions” — and that’s where performance problems begin.

DynamoDB Streams capture a time-ordered sequence of item-level modifications. Every insert, update, or delete can trigger downstream processing — enabling event-driven architectures without polling.

Architecture Mental Model: Think of DynamoDB as a distributed serverless NoSQL brain. Your data automatically spreads across partitions, replicates across Availability Zones, and scales horizontally without any intervention from you.

DynamoDB Tables & Keys

Key design is the single most important decision you’ll make with DynamoDB. Get it wrong, and you’ll fight performance issues forever. Get it right, and the database almost disappears — it just works.

Partition Key (Simple Primary Key)

A partition key is a single attribute that DynamoDB uses to distribute data across partitions. Every item must have a unique partition key value.

Table: Users
Partition Key: user_id

user_id: "u-12345" → Partition A
user_id: "u-67890" → Partition B

Use simple partition keys when you always access items by a single unique identifier.

Composite Key (Partition Key + Sort Key)

A composite key combines a partition key with a sort key. Items with the same partition key are stored together and sorted by the sort key.

Table: Orders
Partition Key: customer_id
Sort Key: order_date

customer_id: "c-100", order_date: "2025-01-15" → Item 1
customer_id: "c-100", order_date: "2025-01-16" → Item 2

This design lets you query all orders for a customer and sort them by date — a pattern impossible with a simple partition key.

Secondary Indexes

Sometimes you need to query data by attributes other than your primary key. That’s where secondary indexes come in.

Global Secondary Index (GSI): Creates an entirely new partition key and optional sort key. Data is projected (copied) to the index. You can create GSIs anytime.

Local Secondary Index (LSI): Uses the same partition key as your table but a different sort key. Must be created when you create the table. Limited to 10 GB per partition key value.

⚠️ Senior Engineer Warning on LSIs: Avoid Local Secondary Indexes unless you have an absolute requirement for strongly consistent reads on an alternate sort key. Here’s why I’ve learned this the hard way:

LSIs are permanent. Once created, you cannot remove an LSI without deleting and recreating the entire table. That GSI you regret? Delete it. That LSI you regret? Migrate your entire dataset.

The 10GB partition limit is a ticking time bomb. LSIs enforce a 10GB limit per partition key value. When you hit that limit, DynamoDB starts rejecting writes for that partition key — not throttling, rejecting. I’ve seen production systems fail because a single high-volume customer exceeded this invisible ceiling.

My recommendation: Default to GSIs. Accept eventual consistency. Only use LSIs when strongly consistent alternate queries are genuinely business-critical, and you’ve done the math on your partition key’s maximum data volume.

Key Design Example:

For a social media application tracking posts and comments:

Table: SocialContent
Partition Key: user_id
Sort Key: content_id (format: POST#timestamp or COMMENT#post_id#timestamp)

GSI1: content_type-created_at-index
Partition Key: content_type
Sort Key: created_at

This design supports queries like “get all posts by user,” “get recent posts globally,” and “get comments on a specific post.”

💡 Reflection Prompt: Can you identify when a composite key gives you better query flexibility than a simple key? Think about an application you’ve built — what queries would benefit from sort key ordering?

Read & Write Capacity Modes

DynamoDB offers two capacity modes, and choosing the right one affects both performance and cost.

Provisioned Capacity Mode

You specify exactly how many Read Capacity Units (RCUs) and Write Capacity Units (WCUs) your table needs.

• 1 RCU = One strongly consistent read per second for items up to 4 KB
• 1 RCU = Two eventually consistent reads per second for items up to 4 KB
• 1 WCU = One write per second for items up to 1 KB

If your item is 8 KB, a strongly consistent read consumes 2 RCUs. Math matters here.

Auto Scaling adjusts provisioned capacity based on utilization. You set minimum, maximum, and target utilization (typically 70%), and DynamoDB scales within those bounds.

On-Demand Mode

DynamoDB automatically handles capacity. You pay per request — no provisioning, no capacity planning. Pricing is higher per request but eliminates waste from over-provisioning.

Burst Capacity

DynamoDB reserves a portion of unused capacity for bursts. If your table is provisioned for 100 WCUs but only using 50, you’re building burst capacity that can handle temporary spikes.

When to Use Each Mode:

Real-World Scenario:

I once consulted for a startup with wildly unpredictable traffic — viral content could spike reads 100x in minutes. Provisioned capacity with Auto Scaling couldn’t react fast enough. Switching to On-Demand eliminated throttling completely. Yes, the per-request cost was higher, but they stopped losing users during traffic spikes.

DynamoDB Data Modeling

This is where DynamoDB differs most dramatically from relational databases. Forget normalization. Embrace denormalization.

Single-Table Design

The most powerful (and initially confusing) DynamoDB pattern stores multiple entity types in one table. Instead of separate tables for Users, Orders, and Products, everything lives together with carefully designed keys.

Why? Because DynamoDB charges per request and excels at retrieving related items in a single query. Multiple tables mean multiple queries mean higher latency and cost.

Access Patterns First

In relational design, you model your data, then figure out queries. In DynamoDB, you flip this completely:

1. List every access pattern your application needs
2. Design keys and indexes to support those patterns
3. Then model your data

If you can’t query it efficiently, redesign your keys — not your application.

Denormalization

Store redundant data to avoid joins. If an order needs customer name, store it directly in the order item. Yes, you might update multiple items when a customer changes their name, but reads become blazingly fast.

Managing Relationships:

• One-to-One: Store both entities in the same item, or use the same partition key
• One-to-Many: Use composite keys where the “one” side is the partition key
• Many-to-Many: Use adjacency lists or inverted indexes with GSIs

Practical Example: eCommerce Order System

Access patterns needed:

• Get customer by ID
• Get all orders for a customer
• Get order by order ID
• Get all items in an order

Table: EcommerceData

| PK            | SK                  | Data                           |
|---------------|---------------------|--------------------------------|
| CUSTOMER#123  | PROFILE             | {name, email, address}         |
| CUSTOMER#123  | ORDER#2025-001      | {total, status, date}          |
| CUSTOMER#123  | ORDER#2025-002      | {total, status, date}          |
| ORDER#2025-001| ITEM#SKU-A          | {quantity, price, product}     |
| ORDER#2025-001| ITEM#SKU-B          | {quantity, price, product}     |

With this design, one query retrieves a customer profile. Another retrieves all their orders. A third retrieves all items in a specific order. No joins. No multiple round trips.

DynamoDB Streams & Integrations

Streams transformed how I build event-driven systems. Every change to your table becomes an event you can process.

Change Data Capture (CDC)

DynamoDB Streams captures item-level changes with four view types:

• KEYS_ONLY: Just the key attributes
• NEW_IMAGE: The entire item after modification
• OLD_IMAGE: The entire item before modification
• NEW_AND_OLD_IMAGES: Both before and after states

Stream records are stored for 24 hours and processed in order within each partition key.

Integration Patterns:

Lambda Triggers: The most common pattern. A Lambda function automatically invokes for each stream record batch, enabling real-time processing without polling.

DynamoDB Table → Stream → Lambda → (SNS, SQS, another DynamoDB table, etc.)

Kinesis Data Streams: For high-volume scenarios where you need longer retention (up to 365 days) or want to fan out to multiple consumers.

EventBridge Pipes: Connect streams directly to EventBridge for routing to 20+ AWS services without custom code.

OpenSearch Integration: Automatically sync DynamoDB items to OpenSearch for full-text search capabilities.

S3 Export: Periodic exports to S3 for analytics, data lakes, or long-term archival.

💡 Reflection Prompt: How would you use Streams to build an event-driven microservices pipeline? Consider a scenario where an order creation should trigger inventory updates, email notifications, and analytics events.

DynamoDB Security Best Practices

Security in DynamoDB is straightforward if you follow AWS best practices — and catastrophic if you don’t.

IAM Policies

Never use root credentials. Never embed access keys in code. Always use IAM roles with least-privilege permissions.

A properly scoped policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "dynamodb:GetItem",
      "dynamodb:Query"
    ],
    "Resource": "arn:aws:dynamodb:us-east-1:123456789:table/Orders",
    "Condition": {
      "ForAllValues:StringEquals": {
        "dynamodb:LeadingKeys": ["${aws:userid}"]
      }
    }
  }]
}

This policy allows users to query only their own data — powerful for multi-tenant applications.

Encryption

DynamoDB encrypts all data at rest by default using AWS-owned keys. For compliance requirements, use customer-managed KMS keys (CMKs) with automatic rotation.

Data in transit is encrypted via HTTPS — all DynamoDB API calls require TLS.

Fine-Grained Access Control

Use IAM condition keys to restrict access to specific items or attributes:

• dynamodb:LeadingKeys — Restrict to specific partition key values
• dynamodb:Attributes — Limit which attributes users can access

VPC Endpoints

Keep DynamoDB traffic within the AWS network using Gateway VPC Endpoints. This improves security and can reduce data transfer costs.

🚀 Security Tip: Always use IAM roles for applications accessing DynamoDB. EC2 instances, Lambda functions, and ECS tasks should never have hardcoded credentials. Roles provide automatic credential rotation and eliminate secrets management complexity.

Performance Optimization

After years of DynamoDB troubleshooting, these are the patterns that cause the most production issues — and how to avoid them.

Hot Partitions

When too many requests target the same partition key, that partition becomes “hot” and gets throttled while other partitions sit idle.

Solution: Design partition keys with high cardinality. Add random suffixes if necessary. Use write sharding for high-throughput scenarios.

📅 2025 Context on Hot Partitions: If you learned DynamoDB before 2019, you might have PTSD about hot partitions. The good news: AWS has significantly improved Adaptive Capacity over the years.

Modern DynamoDB automatically isolates hot partitions and borrows unused capacity from cooler partitions much more effectively than it used to. A moderately hot partition that would have caused cascading throttling in 2018 often handles fine today.

However, don’t use this as an excuse for lazy key design. Adaptive Capacity is a safety net, not a design strategy. Extreme hotspots still cause throttling. The fundamentals still apply: distribute writes evenly, use high-cardinality keys, and monitor your partition heat distribution with Contributor Insights.

Think of it this way: Adaptive Capacity means your slightly imperfect key design probably won’t wake you up at 3 AM. But a fundamentally flawed key design (like using status as a partition key where 90% of items are “active”) will still fail.

Large Item Anti-Patterns

DynamoDB charges based on item size. A 400 KB item (the maximum) consumes 100 WCUs for a single write. Worse, large items reduce the effective throughput of your partitions.

Solution: Store large attributes in S3 and keep only the reference in DynamoDB. Compress data when possible.

GSI Overuse

Every GSI duplicates data and consumes additional capacity. Five GSIs mean you’re potentially paying 5x for writes.

Solution: Use single-table design with composite keys to reduce GSI needs. Consider sparse indexes where only items with specific attributes are projected.

Adaptive Capacity

DynamoDB automatically redistributes capacity to hot partitions. As of 2025, this feature has matured significantly — it now kicks in faster and handles moderate hotspots much more gracefully than early implementations. However, design your keys to avoid hotspots rather than relying on adaptive capacity as a crutch. It’s a resilience feature, not an architecture strategy.

DAX (DynamoDB Accelerator)

DAX is an in-memory cache that sits in front of DynamoDB. It’s fully managed, highly available, and reduces response times from milliseconds to microseconds.

Use DAX when:

• Your application has read-heavy workloads
• You can tolerate eventual consistency
• The same items are read repeatedly
• You’re already running within a VPC

Don’t use DAX when:

• Writes dominate your workload
• You require strongly consistent reads
• Your access patterns don’t benefit from caching

💰 Senior Cost Reality Check: Before spinning up DAX, ask yourself: Do I actually need microsecond latency?

DAX sounds appealing, but here’s what the marketing doesn’t emphasize:

DAX requires VPC infrastructure. Your Lambda functions need VPC configuration, which adds cold start latency and NAT Gateway costs. For many serverless architectures, you’re trading one performance gain for another performance penalty.

DAX clusters aren’t cheap. Even the smallest t3.small nodes run ~$30/month per node, and you need at least 3 nodes for production HA. That’s $90/month before you’ve cached a single item.

DynamoDB is already fast. Single-digit millisecond latency is the baseline. For most user-facing applications, the difference between 5ms and 0.5ms is imperceptible.

My honest recommendation: For simple serverless apps, skip DAX entirely. Standard DynamoDB latency is fast enough. Consider DAX only when you have genuine microsecond requirements (high-frequency trading, real-time gaming) or when your read patterns create measurable cost savings from reduced RCU consumption.

If you just need simple caching, consider application-level caching with ElastiCache or even in-Lambda caching for hot data — far simpler than managing a DAX cluster.

🧠 Quiz: What happens if your partition key receives too many write requests?

A) DynamoDB automatically creates more partitions
B) Writes get throttled even if total table capacity isn’t exhausted
C) The partition key value is rejected
D) DynamoDB switches to On-Demand mode

Answer: B — Hot partitions cause throttling at the partition level, regardless of your table’s total provisioned capacity.

DynamoDB Global Tables

For applications serving users worldwide, Global Tables provide multi-region, fully replicated tables with active-active configuration.

How It Works:

You designate replica tables in multiple AWS regions. DynamoDB automatically replicates writes to all regions, typically within one second. Users read and write to their nearest region.

Conflict Resolution:

Global Tables use “last writer wins” based on timestamps. For most applications, this works fine. If you need custom conflict resolution, implement it in your application logic.

Use Case: Global User Sessions

A gaming company I worked with had users in North America, Europe, and Asia. Before Global Tables, users connecting to distant regions experienced 200ms+ latency for session reads.

After enabling Global Tables with replicas in us-east-1, eu-west-1, and ap-northeast-1, every user got sub-10ms session access. The implementation took less than a day.

Important Considerations:

• All replicas must have the same table name
• GSIs must be identical across replicas
• Streams must be enabled
• Cost includes replication write capacity

DynamoDB Monitoring & Troubleshooting

Production issues at 2 AM are much less painful when you have proper monitoring.

CloudWatch Metrics to Watch:

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits — Actual usage
• ThrottledRequests — The most critical metric; should be zero
• ReadThrottleEvents / WriteThrottleEvents — Per-partition throttling
• SystemErrors — DynamoDB-side issues (rare but important)
• UserErrors — Client-side issues like validation errors

CloudTrail Logging

CloudTrail captures all DynamoDB API calls for security auditing. Enable it for compliance and troubleshooting access issues.

Contributor Insights

This feature identifies your most accessed partition keys and items. Essential for finding hot partitions before they cause throttling.

Enable it temporarily during load testing or when investigating performance issues — it has additional cost.

PartiQL Debugging

PartiQL lets you query DynamoDB using SQL-like syntax. Great for ad-hoc exploration:

SELECT * FROM Orders WHERE customer_id = 'c-123'

Use it in the console for quick debugging, but stick to the native API for production code.

💡 Reflection Prompt: How often do you review DynamoDB throttling metrics in production? Set up a CloudWatch alarm for ThrottledRequests > 0 if you haven’t already — throttling often indicates design issues that compound over time.

DynamoDB Pricing

Understanding DynamoDB pricing prevents budget surprises. Here’s the breakdown:

Read/Write Capacity:

• On-Demand: $1.25 per million write requests, $0.25 per million read requests (us-east-1)
• Provisioned: ~$0.00065 per WCU-hour, ~$0.00013 per RCU-hour

Storage:

$0.25 per GB-month for standard table class.

Streams:

Reading from streams is free. You pay for Lambda invocations or Kinesis if you use those integrations.

Backups:

• On-demand backups: $0.10 per GB-month
• Point-in-time recovery: $0.20 per GB-month
• Restore: $0.15 per GB

DAX:

Priced per node-hour. A t3.small node runs about $0.04/hour.

Global Tables:

You pay for replicated write capacity in each region — essentially multiplying write costs by the number of replicas.

Example Pricing Calculation:

Application with:

• 100 writes/second average
• 500 reads/second average (eventually consistent)
• 50 GB storage
• 3 regions (Global Tables)

Provisioned mode (monthly):

• Writes: 100 WCU × $0.00065 × 730 hours × 3 regions = ~$143
• Reads: 250 RCU (eventually consistent) × $0.00013 × 730 hours = ~$24
• Storage: 50 GB × $0.25 × 3 regions = ~$38
• Total: ~$205/month

On-Demand mode (monthly):

• Writes: 100 × 3600 × 730 × 3 regions × $0.00000125 = ~$985
• Reads: 500 × 3600 × 730 × $0.00000025 = ~$329
• Storage: ~$38
• Total: ~$1,352/month

For predictable workloads, provisioned capacity with reserved pricing offers significant savings.

Visual Architecture Reference

[Image Placeholder: DynamoDB Architecture Diagram]

Caption: DynamoDB Architecture — Partitions, Keys, and Global Tables powering scalable cloud workloads.

Style: Minimalist design with dark navy (#0C1A2B) background. Partition nodes in cyan (#00D9F5). Data flow arrows in royal blue (#2A65F5). Global Table connections spanning multiple region boxes.

Key elements to illustrate:

• Multiple partitions within a single table
• Primary key routing items to specific partitions
• Streams flowing to Lambda and other services
• Global Table replication between regions
• DAX cache layer in front of the table

Conclusion: Master DynamoDB, Master Cloud-Native Design

DynamoDB represents a fundamental shift in how we think about databases. It’s not just a faster version of what came before — it’s a different paradigm entirely.

The engineers who thrive with DynamoDB are those who:

• Design for access patterns, not entity relationships
• Embrace denormalization instead of fighting it
• Understand that partition key design determines everything
• Use single-table design for related entities
• Monitor proactively rather than reactively

Whether you’re building serverless APIs, processing IoT streams, or preparing for AWS certifications, DynamoDB skills are increasingly non-negotiable for modern DevOps engineers.

Start with a simple project. Model a few access patterns. Experience the satisfaction of sub-millisecond latency at scale. Once you do, you’ll understand why DynamoDB powers some of the world’s largest applications.

Frequently Asked Questions

Srikanth Ch is a Senior DevOps Engineer with extensive experience building scalable AWS architectures. Follow thedevopstooling.com for practical DevOps tutorials, AWS certification prep, and hands-on labs.