What's changed: In-scope coverage: added purpose-built stores/storage (DocumentDB/Keyspaces/MemoryDB/S3 Tables/EFS/CloudFront/Backup)
2.3Choosing Purpose-Built Data Stores
Understand choosing purpose-built stores by access pattern (DynamoDB = NoSQL, RDS/Aurora = relational OLTP, Redshift = OLAP), plus catalogs and schema evolution.
AWS favors choosing a purpose-built store best for the access pattern rather than one database for everything. Learn the key examples.
2.3.1Picking purpose-built stores
- DynamoDB: key-value NoSQL for high-throughput, low-latency apps.
- RDS/Aurora: relational (SQL) for transactions and joins (OLTP).
- Redshift: columnar DWH for large aggregations/analytics (OLAP).
- Schema evolution: handle changes like added columns using Parquet + a catalog.
AWS favors picking a purpose-built store best for the access pattern, not "one DB for everything." DynamoDB is key-value/document NoSQL for single-digit-ms, high-throughput, virtually unlimited-scale apps; design starts from keys (partition + sort) and access patterns, with GSIs to broaden queries, DynamoDB Streams for real-time integration, and DAX for ultra-low-latency caching. RDS/Aurora is relational (SQL) for OLTP needing transactions, joins, and consistency. Redshift is a columnar DWH for large aggregation/analytics (OLAP). Others by use case: time-series = Timestream, graph = Neptune, in-memory = ElastiCache/MemoryDB, full-text/log analytics = OpenSearch. Data shape (structured/semi-structured) and schema evolution (added columns) are absorbed on the lake side with Parquet + a catalog and table formats (Iceberg). The axes: "fast app keyed lookups = DynamoDB," "joins/consistency = RDS/Aurora," "aggregation analytics = Redshift."
| Access pattern | Best store |
|---|---|
| High-throughput keyed lookups | DynamoDB |
| Transactions/joins (OLTP) | RDS / Aurora |
| Large aggregation/analytics (OLAP) | Redshift |
| Full-text/log analytics | OpenSearch |
Scenario: design an order app backend plus an analytics platform. Order reads/writes go to DynamoDB (fast keyed access, scalable; changes flow downstream via Streams). Billing/inventory needing consistency uses RDS/Aurora (OLTP). Daily revenue aggregation/BI consolidates in Redshift (OLAP). Log full-text search uses OpenSearch. Split by use case rather than forcing one store.
Q. Fast keyed app? DynamoDB. Q. Transactions/joins? RDS/Aurora. Q. Large analytics? Redshift. Q. Full-text/log analytics? OpenSearch. Q. Query by another key in DynamoDB? GSI. Q. Stream changes downstream? DynamoDB Streams.
Watch the mix-ups: (1) DynamoDB is poor at joins/analytics—route analytics to Redshift/Athena. (2) Redshift is poor at OLTP (many small writes). (3) DynamoDB requires up-front access-pattern design (ad-hoc queries are limited even with GSIs). (4) "Everything relational" is an anti-pattern—choose purpose-built.
2.3.2In-scope purpose-built stores and storage services
Purpose-built stores include options beyond relational/key-value. Amazon DocumentDB is a MongoDB-compatible document DB for nested JSON apps. Amazon Keyspaces is an Apache Cassandra-compatible wide-column store for large-scale, high-throughput writes. Amazon MemoryDB for Redis is a Redis-compatible in-memory DB, but whereas ElastiCache is a cache tier, MemoryDB persists every write to a Multi-AZ transaction log, giving it the durability to serve as a primary DB. For analytics table storage, Amazon S3 Tables stores Apache Iceberg tables in a managed way, optimized via auto-compaction and efficiently queryable from Athena/EMR/Spark. For shared files, Amazon EFS is POSIX-compliant, auto-scaling storage mountable concurrently from many instances; for delivery, Amazon CloudFront (CDN) edge-caches data/content. For data protection, AWS Backup centralizes backups of S3/EBS/EFS/RDS/DynamoDB and more, with cross-region/cross-account copy and Vault Lock (WORM) against accidental deletion and ransomware.
| Use | Service | Key point |
|---|---|---|
| Document DB | Amazon DocumentDB | MongoDB-compatible |
| Wide-column | Amazon Keyspaces | Cassandra-compatible, high throughput |
| Durable in-memory | Amazon MemoryDB for Redis | Redis-compatible, can be primary |
| Analytics tables | Amazon S3 Tables | Managed Iceberg |
| Shared files / delivery / protection | EFS / CloudFront / AWS Backup | Concurrent mount / CDN / centralized backup |
2.3.3Section summary
- Choose DynamoDB (NoSQL) / RDS·Aurora (OLTP) / Redshift (OLAP)
- Pick the optimal store by access pattern
- Purpose-built = DocumentDB/Keyspaces/MemoryDB; analytics tables = S3 Tables; shared/delivery/protection = EFS/CloudFront/Backup
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which best fits a key-value workload needing high throughput and single-digit-ms latency?
Q2. Which best fits relational transactional (OLTP) workloads with joins?
Q3. Which data store best fits fast large-scale aggregation/analytics (OLAP)?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.