DynamoDB Advanced Patterns — Overview
DynamoDB advanced topics appear in 167 questions across DBS-C01 (129) and DAS-C01/DOP-C02. Beyond basic CRUD, the exam tests DynamoDB Streams, Global Tables, TTL, capacity modes, GSI/LSI design, single-table design, and DAX caching patterns.
Trigger Lambda
Cross-region replication
Event-driven patterns
24-hour retention
Eventual consistency cross-region
Conflict resolution (last writer)
Auto-replication
Local reads everywhere
Provisioned + Auto Scaling
Reserved Capacity
Burst (300s saved)
Adaptive capacity
LSI (alternate SK)
Single-table design
Sparse indexes
TTL auto-delete
DynamoDB Streams
| Feature | Details |
|---|---|
| What | Ordered, time-sequenced log of all item-level changes (insert, update, delete) |
| Views | KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES |
| Retention | 24 hours (then deleted). Process with Lambda or Kinesis Data Streams. |
| Consumers | Lambda trigger (most common), KCL application, Kinesis Data Streams adapter |
| Use cases | Trigger Lambda on changes, sync to OpenSearch, aggregate analytics, cross-region replication (Global Tables use this internally) |
Global Tables — Multi-Region
- Active-active: Read AND write in any region. Changes replicate to all other regions (typically <1 second).
- Conflict resolution: Last-writer-wins (based on timestamp). No custom conflict resolution.
- Consistency: Eventually consistent cross-region. Strongly consistent within a single region.
- Requirements: Streams must be enabled, same table name in all regions, On-Demand or provisioned with auto-scaling.
- Exam pattern: “Multi-region low-latency reads AND writes” → DynamoDB Global Tables. “Multi-region reads only” → Global Tables or cross-region read replicas.
Capacity Modes — Decision
| Mode | Pricing | Best For |
|---|---|---|
| On-Demand | Pay per request ($1.25/M writes, $0.25/M reads) | Unknown/unpredictable traffic, spiky workloads, new tables |
| Provisioned | Pay per RCU/WCU provisioned per hour | Predictable traffic, consistent utilization, cost optimization |
| Provisioned + Auto Scaling | Scales within min/max bounds based on target utilization (default 70%) | Variable but predictable patterns (scales up/down) |
- Burst capacity: DynamoDB saves unused capacity for up to 300 seconds. Short spikes use burst before throttling.
- Adaptive capacity: Redistributes throughput across partitions to handle hot partitions (automatic).
- Switch modes: Can switch between On-Demand and Provisioned once per 24 hours.
GSI vs LSI
| Feature | GSI (Global Secondary Index) | LSI (Local Secondary Index) |
|---|---|---|
| Key | Different partition key + optional sort key | Same partition key + different sort key |
| Create | Anytime (add/remove after table creation) | Table creation time only (cannot add later) |
| Capacity | Separate provisioned capacity from table | Shares table’s capacity |
| Consistency | Eventually consistent only | Strongly or eventually consistent |
| Limit | 20 per table | 5 per table |
TTL (Time to Live)
- What: Automatically delete items after a specified timestamp (epoch seconds)
- Cost: Free — no WCU consumed for TTL deletions
- Timing: Items typically deleted within 48 hours of expiration (not instant)
- Streams: TTL deletions appear in DynamoDB Streams (for audit/archival)
- Use cases: Session expiration, temporary data, log retention, GDPR data deletion
- Pattern: Set TTL → item expires → Stream captures deletion → Lambda archives to S3 (audit trail)
Single-Table Design
- Concept: Store multiple entity types in one table using composite keys (PK: USER#123, SK: ORDER#456)
- Why: Reduce table count, enable single-query access patterns that span entities (get user + orders in one query)
- GSI overloading: GSI with generic attribute names (GSI1PK, GSI1SK) used for multiple access patterns
- When NOT to: When entities have vastly different access patterns or RCU/WCU needs (hot partition risk)
Exam Tips
| Exam | Key Points |
|---|---|
| DBS-C01 | “Trigger on item change” → DynamoDB Streams + Lambda. “Multi-region writes” → Global Tables. “Auto-delete expired sessions” → TTL. “Query by non-key attribute” → GSI. “Unpredictable traffic” → On-Demand. “Reduce read latency to microseconds” → DAX. “Hot partition” → better key design or adaptive capacity. “Export to S3” → DynamoDB Export to S3 (PITR-based, no RCU). |
AWS Certification Exam Practice Questions
Question 1:
A company needs their DynamoDB table accessible for reads and writes in 3 regions (us-east-1, eu-west-1, ap-southeast-1) with single-digit millisecond latency for local users. What is the simplest solution?
- DynamoDB Streams + Lambda to replicate items to tables in other regions
- DynamoDB Global Tables — enable replication to all 3 regions for active-active access
- DynamoDB with DAX in each region + cross-region read replicas
- S3 cross-region replication with DynamoDB in each region synced manually
Show Answer
Answer: B — Global Tables provide fully managed, active-active multi-region replication. Write anywhere, read anywhere. Replication typically <1 second. No custom Lambda needed (unlike A). Built-in conflict resolution (last-writer-wins). Enable with a few clicks. DAX (C) is for read caching within a region, not cross-region replication.
Question 2:
A web application stores user sessions in DynamoDB. Sessions should automatically expire after 24 hours without the application explicitly deleting them. The company also needs to know which sessions were cleaned up (for audit). Which features achieve this?
- CloudWatch Events scheduled to scan and delete old items every hour
- TTL attribute set to creation_time + 24 hours. DynamoDB Streams captures TTL deletions → Lambda writes to audit log.
- DynamoDB Auto Scaling to remove old partitions
- Glue job that scans for expired items and deletes them nightly
Show Answer
Answer: B — TTL automatically deletes expired items at no WCU cost. Set a TTL attribute (e.g., expireAt = current_epoch + 86400). DynamoDB Streams captures TTL deletions with the full item image — Lambda processes the stream to write audit records. This is zero-maintenance (no scheduled jobs) and free (no WCU for TTL deletes). Scanning solutions (A, D) consume RCUs and add complexity.
Question 3:
A table’s provisioned capacity is set to 1000 WCU evenly across 4 partitions (250 WCU each). One partition receives 80% of writes (hot partition) and gets throttled. The table has burst capacity available. How does DynamoDB handle this?
- All writes to the hot partition are throttled — must redesign the key
- Adaptive capacity automatically redistributes throughput to the hot partition, using unused capacity from other partitions
- Burst capacity is only table-level, not partition-level
- Auto Scaling increases total capacity until the hot partition is satisfied
Show Answer
Answer: B — Adaptive capacity (enabled by default) redistributes unused throughput from idle partitions to hot partitions. If partitions 2-4 use only 50 WCU each, the remaining 600 WCU can be used by partition 1. This handles moderate imbalances. Extreme hot keys (single item getting all writes) still need key redesign. Adaptive capacity works within total table throughput.
Related Posts
- Three-Tier Web & Caching (DAX)
- RDS & Aurora Performance
- Event-Driven Serverless Architecture
- Multi-Region Active-Active
References
Frequently Asked Questions
On-Demand vs Provisioned — which is cheaper?
On-Demand is cheaper when traffic is unpredictable or very spiky (utilization <18% of would-be provisioned capacity). Provisioned is cheaper for steady-state traffic with predictable patterns. Rule of thumb: if your table consistently uses >18% of peak capacity, provisioned + auto-scaling is cheaper. New tables or uncertain patterns → start On-Demand, analyze, switch later.
When should I use Global Tables vs cross-region read replicas?
Global Tables: When you need writes in multiple regions (active-active). Both regions accept writes, replication is automatic. No native cross-region read replicas in DynamoDB — Global Tables is the only option for multi-region. For read-only multi-region, Global Tables still works (just write to one region, read from any). For relational databases with read-only needs, Aurora Global is the alternative.